Enclosure Control System Specifications...SPEC-0082, Revision B Page ii REVISION SUMMARY: 1. Date: 05 October 2008 Revision: DRAFT Changes: Created. 2. Date: 24 April 2009 Revision:

Project Documentation Document SPEC-0082

Revision B

Advanced Technology Solar Telescope 950 N. Cherry Avenue Tucson, AZ 85719 Phone 520-318-8102 [email protected] http://atst.nso.edu Fax 520-318-8500

Enclosure Control System Specifications

Bret Goodrich Software Group

25 August 2010

Name Signature Date

Prepared By: Bret Goodrich

Sr. Software Engineer B. Goodrich 25 Aug 2010

Approved By : Heather Marshall

Enclosure Engineer H. Marshall 25 Aug 2010

Approved By: Rob Hubbard

Systems Engineer R. Hubbard 26 Aug 2010

Approved By: Thomas Rimmele

Project Scientist T. Rimmele 27 Aug 2010

Released By: Jeremy Wagner

Project Manager J. Wagner 30 Aug 2010


SPEC-0082, Revision B Page ii

REVISION SUMMARY:

1. Date: 05 October 2008

Revision: DRAFT

Changes: Created.

2. Date: 24 April 2009

Revision: Rev Draft 1

Changes: Response to SDR committee comments.

3. Date: 05 January 2010

Revision: Rev A

Changes: Removed thermal control.

4. Date: 17 August 2010

Revision: Rev B

Changes: Revise for Contracting; Initial formal release.

WAIVERS: The following waivers are applicable to this specification.

1. RFW-0041: ECS High Speed Status


SPEC-0082, Revision B Page iii

Table of Contents

1. INTRODUCTION ................................................................................................... 1

1.1 DOCUMENT SCOPE ................................................................................................. 1 1.2 CONTROLLING DOCUMENTS ..................................................................................... 1 1.3 REFERENCE DOCUMENTS ........................................................................................ 1 1.4 VERIFICATION METHODS .......................................................................................... 1 2. OVERVIEW ........................................................................................................... 3

2.1 SYSTEMS ............................................................................................................... 3 2.1.1 Telescope Control System ................................................................................... 3 2.1.2 Enclosure Control System .................................................................................... 3 2.1.3 Enclosure Mechanical Control System ................................................................. 3 2.1.4 Common Services Framework ............................................................................. 3

2.2 OPERATIONAL PHILOSOPHY ..................................................................................... 3

2.2.1 Commands and Configurations ............................................................................ 4 2.2.2 Events .................................................................................................................. 4

2.2.3 Global Interlocks ................................................................................................... 4 3. FUNCTIONAL AND PERFORMANCE REQUIREMENTS .................................... 6 3.1 OVERVIEW .............................................................................................................. 6

3.2 ENCLOSURE MECHANICAL REQUIREMENTS ............................................................... 9 3.3 SERVO SYSTEMS REQUIREMENTS .......................................................................... 12

3.4 ANCILLARY MECHANICAL SYSTEMS REQUIREMENTS ................................................ 13 3.5 PERFORMANCE REQUIREMENTS ............................................................................. 14 3.5.1 General Requirements ....................................................................................... 14

3.6 OPERATIONAL AND INTERFACE REQUIREMENTS ....................................................... 15 3.7 OTHER REQUIREMENTS ......................................................................................... 17

3.7.1 Acceptance Testing Requirements ..................................................................... 17 3.7.2 Documentation Requirements ............................................................................ 17

3.7.3 Safety Requirements .......................................................................................... 18


SPEC-0082, Revision B Page 1 of 18

1. INTRODUCTION

This document defines the design specifications of the Enclosure Control System (ECS) for the

Advanced Technology Solar Telescope (ATST). The ECS is one of the Telescope Control

System (TCS) subsystems and is responsible for the operation of the enclosure mechanical

assemblies.

1.1 DOCUMENT SCOPE

This document (herein referred to as the Specifications) includes all specifications necessary to

design and construct the ECS, its subsystems and assemblies. This document may refer to other

ATST project documents for further clarification or explanation only.

1.2 CONTROLLING DOCUMENTS

The Enclosure Control System shall comply with interfaces and applicable requirements

described in the following documents:

SPEC-0010, Enclosure Specifications

SPEC-0022-1, Common Services Framework User’s Manual

SPEC-0022-2, Common Services Framework Reference Guide

ICD-4.4/5.6, Telescope Control System to Enclosure Control System Interface

ICD-5.0/5.6, Enclosure to Enclosure Control System Interface

1.3 REFERENCE DOCUMENTS

The ATST Project has produced a number of documents that the Design Contractor may find

informative and/or useful during the course of performing the Work. They are provided as

reference only and shall not be construed as directive in nature.

SPEC-0001, Science Requirements

SPEC-0005, Software Design Requirements

SPEC-0012, ATST Acronym List and Glossary

SPEC-0013, Software Concepts Definitions

SPEC-0036, Operational Concepts Definitions

TN-0003, Alt-Az Zenith Blind Spot and the ATST

TN-0045: Reference Design Studies and Analysis (RDSA) Document for the ATST

Enclosure

1.4 VERIFICATION METHODS

Included in each major numbered specification listed herein is a requirement verification

method. These verification methods specify the minimum standards of verification required by

AURA to ensure that the individual requirements and specifications are met.

All verification activities are the responsibility of the Contractor; i.e., the Contractor shall be

solely responsible for providing any and all test equipment, analyses, inspections, and other

means necessary to verify that the specifications and requirements have been met.



Examples of verification methods include:

Design Review. Verification by design review shall mean that the Contractor

demonstrates to AURA during the appropriate design review that the equipment shall

meet the specification by way of its intrinsic layout and configuration.

Analysis. Verification by analysis shall mean that Contractor analytically demonstrates

that the design meets the specification. Such analyses may include finite element

methods, computation fluid analyses, closed form analyses, etc. All analyses shall be

provided to AURA in written report form, in both electronic (e.g., MS Word) and paper

copy format.

Test. Verification by test and/or measurement shall mean that Contractor empirically

demonstrates that the as-built equipment meets the specification. Testing may be required

in the factory during factory acceptance testing and/or at the Site during Site acceptance

testing.

Inspection. Verification by inspection shall mean that the Contractor visually

demonstrates to AURA personnel that the specification has been achieved on the as-built

equipment during factory preassembly and/or during Site assembly.

At a minimum, the specification compliance matrix provided by Contractor as part of the Work

shall be based on the verification method requirements.

All analyses, test results (with calibration records) and other verification reports shall be

provided to AURA in written report form, in both electronic (e.g., MS Word or Excel) and paper

copy format.



2. OVERVIEW

The Enclosure Control System (ECS) is the subassembly of the ATST Enclosure responsible for

the motion control of the Enclosure, its subassemblies, and all automated components. Its

principal purpose is to control, on behalf of the Telescope Control System (TCS), the position of

the enclosure’s azimuth and altitude, The ECS may also control or monitor other activities within

the enclosure as specified or required by this document or normal operational procedures.

2.1 SYSTEMS

2.1.1 Telescope Control System

In the ATST software architecture, the activities of the Enclosure are controlled by the Telescope

Control System. The ATST TCS is one of the four principal systems of the ATST software

architecture, along with the Observatory Control System (OCS), Data Handling System (DHS),

and Instrument Control System. Each one of these principal systems controls a major functional

process within the operation of the observatory. For the TCS, this functional process is the

configuration of the telescope light feed, from its entrance through the enclosure shutter through

the telescope optics and on to the final instrumental focal plane. The TCS controls all aspects of

the configuration and conditioning of this light feed during normal operations.

Configuring the light feed through the enclosure is a two-part operation: positioning and

tracking. The enclosure positioning and tracking should have no impact on the allowed error

budget of the delivered light feed.

2.1.2 Enclosure Control System

The Enclosure Control System (ECS) operates the ATST Enclosure Mechanical Control System

(EMCS). The ECS is a part of the TCS, and as such, receives current position and rate demands

from the TCS and applies them to the EMCS.

2.1.3 Enclosure Mechanical Control System

The EMCS controls the enclosure carousel (azimuth) and shutter (altitude) drives, the entrance

cover, and entrance aperture plate.

2.1.4 Common Services Framework

The Common Services Framework (CSF) is the software communications and control

framework that all ATST control systems use for commands and events. Software systems are

developed within the CSF and use the various available services and support facilities. The CSF

is described in SPEC-0022, “The Common Services Reference Design.”

2.2 OPERATIONAL PHILOSOPHY

The ECS operates upon configurations passed to it from the TCS. Configurations are passed

within commands defined by the principal systems interface (SPEC-0013), and are themselves

defined by the TCS-to-ECS interface (ICD 4.4/5.6). Configurations and commands inside the

ECS are described here.



2.2.1 Commands and Configurations

The list of available ECS commands is quite short. Briefly, the ECS can be commanded to come

online, go offline, start or resume an action, stop or pause an ongoing action, set or get an

attribute. The information specific to each of these commands is delivered in the command

argument, a configuration. The configuration is a list of attribute-value pairs, where the attributes

have been defined by the ECS. Commands are expected to have a short life on the ECS; they do

not block further commands from being executed. Commands cause actions to occur, and the

actions operate in a separate process thread from the command executor thread. This necessity is

shown by the example of aborting a running command. If a command did not return until the

action was completed, a subsequent command to abort the command could not use the same

command channel. It must either block, waiting for the first command to complete, or use a

second, or-out-of-band channel to get its message to the ECS. This is not a desired system

behavior.

There are several important configuration attributes. First is the configuration identifier, a unique

string that identifies the ongoing experiment and observation. This identifier is required in every

configuration, every event, and every log message; by making this requirement the state of a

particular observation can be determined at any time. The ECS uses the configuration identifier

when it receives trajectories or sends commands to its subsystems.

Also required in the ECS configuration is an attribute or attributes that define the action to be

performed. For the start command, required attributes are the observational mode, position of the

target object, the coordinate system, and the time of command execution. Additional attributes

may further define the action, such as a non-default track rate, a scan pattern, or a particular

adaptive/active optics configuration.

2.2.2 Events

Events are the mechanism that actions use to both broadcast their state and deliver information.

The state of an action moves between offline, idle, busy, paused, and error depending upon the

command executed and the results of the ongoing action. These states are broadcast as events.

Listeners subscribe to the event and upon receiving an event learn the current state and the

configuration that caused the event.

Other information delivered by events include current positions and times, asynchronous alarms

or warnings, trajectory streams, wavefront data, and logging or debugging data. Event

subscribers may include the OCS (in the form of the log system, the operator’s displays, and the

experiment controller), the DHS (headers), and the TCS (status information, command

completion).

The ECS is also a subscriber to events. The subsystems generate state events when actions

commanded by the ECS are completed or when asynchronous alarms occur. The ECS also

subscribes to the position trajectory stream from the TCS.

2.2.3 Global Interlocks

The ECS and its subsystems are required to interface to the Global Interlock System (GIS). The

primary purpose of the GIS is to provide an independent mechanism for personnel and



equipment safety. All mechanisms that singly or in concert may constitute a hazard are required

to both listen for an interlock signal and be placed into a “safe” configuration upon reception of

an interlock signal. Some mechanisms may also generate signals for the GIS, where the signal

may indicate a possible interlock situation. For instance, all doors and hatches have switches that

indicate they are open and possibly interfering with the operation of the telescope or enclosure.

Limit switches on the telescope mount, cable wraps, and rotators also provide a signal indicating

they have reached the end of travel without proper software or electronic response. Mechanisms

such as the mount and rotator obey an interlock condition caused by these switches by powering

off the drives and enabling the brakes. Other mechanisms have similar responses.

The ECS is required to notice that an interlock condition exists on either itself or one of its

subsystems. The response of the ECS to an interlock condition is to place itself and its subsystem

into a suitably safe configuration. Upon the release of the interlock condition the ECS and its

subsystems should be able to return to a normally operating condition, either automatically or

through an operator’s command. Neither the ECS nor the subsystems should need to be rebooted

or restarted.

The ECS monitors the GIS to determine its own state. If the ECS does not realize an interlock

condition exists, it may assume a subsystem has failed or gone offline and try to recover that

system erroneously. Knowing about the interlock condition allows the ECS to both prevent

wrongly changing the state of the observation and to provide additional safety control by

disabling mechanisms and halting trajectory streams.



3. FUNCTIONAL AND PERFORMANCE REQUIREMENTS

3.1 OVERVIEW

5.6-0010 Scope

The ECS shall comprise the software, firmware, and control systems required to operate the

enclosure motion control systems (EMCS). It shall include all computing hardware necessary to

perform the required operations.

Verification: Design Review and Inspection

Requirement Origin: Engineering, Operational Requirements

5.6-0020 Basic Requirements

The ECS shall provide the control system necessary to operate the Enclosure mechanical systems

to meet requirements as described in SPEC-0010, ATST Enclosure Design Requirements

Document. In particular, the ECS provides motion control capabilities to accurately point, move,

track, and offset the Enclosure as required by the science operations. It also provides status

information on the state and performance of the Enclosure.

The ECS shall be an integral part of the Enclosure, and shall control the Carousel and Shutter

drive systems, the entrance aperture cover assembly, the Carousel entrance aperture plate, and

the operation of all Enclosure sensors. It shall be able to perform all controlled operations of the

Enclosure.

The ECS shall provide the control and communications interface with the TCS, the Enclosure

engineering user interface and the ATST software framework. The ECS shall generate all

software messages, alarms, events, logging, and archiving as part of the operational requirements

for ATST software systems.

The ECS shall be connected to and interact with the ATST Global Interlock System (GIS) to

perform safety operations as required by the specifications.

Verification: Design Review and Inspection


5.6-0030 Best Software Practices

The ECS shall conform to the ATST software requirements. Under these requirements the ECS

shall:

Use the ATST Common Services Framework for all communications, commands, events,

logging, archiving, and database functions.

Use the ATST Common Services Framework to build Controllers for, at a minimum, the

top-level ECS controller, carousel controller, shutter controller, entrance aperture

controller, and entrance aperture cover controller. A controller is defined within the

ATST Common Services Framework description in SPEC-0022. Each of these



controllers shall implement the functionality of the referenced system, e.g., the carousel

controller shall implement all necessary functionality to meet the specifications for the

carousel drive system.

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

Deliver documented source code, compiled object code, associated libraries, build and

release code development environments, test software and fixtures, and any other

materials necessary to edit, build, compile, link, load, run, test, and debug the ECS.

Deliver a user’s manual for the ECS.

Use a source code repository for all developed ECS software, and make the repository

available to AURA during construction.

Description: General software requirements are defined in SPEC-0005 along with other general

specifications for ATST Systems and Assemblies. These place uniform requirements upon all

Assemblies to promote conformity and ease of operations and maintenance. The software

standards defined in this document fall into two areas: functional requirements of the ATST

software infrastructure and implementation requirements of the System. For the former, the

requirements define how a System should interface and interact with the ATST infrastructure

and other ATST software Systems. For the latter, the requirements define standards for source

code, documentation, maintenance, and interfaces.

Verification: Design Review, Inspection, and Test


5.6-0040 Control

The ECS shall control all subcomponents associated with the system assembly, including any

motors, actuators, sensors, and other mechanical, optical, and electronic components. Control of

the system shall be through the approved system interface.

Verification by: Design Review

Requirement Origin: SPEC-0005, SPEC-0013

5.6- 0050 Default State

The ECS shall have a defined default state for all enclosure hardware and equipment that it

controls. Unless approved otherwise by AURA, the default state of any equipment shall be an

inert, non-moving, non-powered condition. Equipment shall take this state on an interlock

condition, initialization, shutdown, or when demanded through the software interface.

Verification by: Design Review and Test;

Requirement Origin: Safety, Operational Requirements



5.6- 0060 Restart

The ECS shall perform all requests sent through its interface without need of reboot or re-

initialization, unless the request demands such an operation.



5.6- 0070 Health

The ECS shall be able to determine whether the current state of the Enclosure is within

operational specifications. The ECS shall report this current state as its health, which should be

identified as “good,” “warning,” “bad,” or “unknown.” The ECS shall report the health of all

Enclosure subsystems. The ECS shall determine and report the health at least every three

seconds.



5.6- 0080 Logging

The ECS shall log pertinent data to the ATST facility log mechanism. Pertinent data shall

include state changes, configuration changes, errors, alarms and warnings, and any other

information that may assist in reconstructing the operation of the ECS and Enclosure. The ECS

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

definitions of logging levels.


Requirement Origin: Engineering, Operational Requirement

5.6- 0090 Availability

The ECS shall always be available to accept or reject commands. The ECS shall not block any

command request while processing another command request.

Description: This requirement prevents the ECS from processing a command in only one thread,

essentially blocking subsequent commands until the first one is completed. This behavior is

necessary to effect commands such as “Stop” and “Pause” after an initial start command;

otherwise it would be difficult to stop an ongoing operation.


Requirement Origin: SPEC-0005

5.6- 0095 Persistence of Data

Static information required by the ECS 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 Common Services

Framework mechanism for default configuration storage.

Verification by: Design Review, Factory Test, & Site Test;

Requirement Origin: SPEC-0005, SPEC-0013

3.2 ENCLOSURE MECHANICAL REQUIREMENTS

5.6- 0100 Range of Travel

The ECS shall control the Enclosure through its full range of travel in Carousel azimuth and

shutter altitude. Excursions beyond the allowable range of travel shall be prohibited by the ECS,

unless expressly allowed through a manual override. The allowable range of travel shall be set

through software or servo controller soft limits placed before any electronic or mechanical limit.

The soft limits shall be reconfigurable only though an engineering operation and not changeable

during normal operations.

Description: The range of travel for each telescope axis should be defined as a fixed software

limit. Motion controllers should be programmed to decelerate as they reach the software limit,

and come to a stop at or shortly past the limit. Under normal operations (i.e., not engineering

operations) the next, electronic, limit switch should never be reached. Under engineering

operations the ECS should be capable of exceeding the software limit, but at a greatly reduced

velocity and acceleration limit. At no time should the ECS ever command an Enclosure axis past

the electronic limit.


Requirement Origin: Safety, Science Requirements.

5.6- 0110 Zenith

The ECS shall move smoothly into, through, and out of the zenith area. While within the zenith

blind spot, the ECS shall meet all slew requirements, but is not required to meet all tracking

requirements. Upon leaving the zenith zone of avoidance the ECS shall once again be in

conformance with tracking requirements. The ECS shall generate a status indication when it is

with the prescribed zenith area.

Description: The ATST zenith blind spot is applicable during normal operations a few times per

year at the Site, as described in TN-0003 Alt-Az Zenith Blind Spot and the ATST. During this

time the sun will travel through the blind spot for a few minutes (e.g., 8 minutes). For a transit

through the zenith blind spot, the Carousel azimuth must rotate at maximum slew rate and re-

acquire the target after its passage through the blind spot.





5.6- 0120 Rate of Travel

The ECS shall move the Enclosure about its axes of rotation no faster than the specified

maximum rates of travel (as defined by the Enclosure Specifications, SPEC-0010). The ECS

shall perform no acceleration or deceleration that exceeds the specified maximum acceleration,

deceleration, or torque. The ECS shall reach the prescribed rates of travel using an acceleration

profile consistent with the Telescope requirements and standard observatory operational

behavior.

Description: The Enclosure should never travel faster than the designed maximum rates of travel.

To reach these rates the ECS should use a consistent acceleration profile that keeps servo

position, current, and speed within required operational ranges. Similarly, slowing and stopping

the Enclosure should use a consistent deceleration profile that also meets these requirements.



5.6-0130 Pointing

The ECS shall be able to move each Enclosure assembly to a demand position and keep each

Enclosure assembly within the required position and velocity tolerances. The ECS shall move in

the quickest possible path to the demand position without exceeding any operational

specifications.

Description: The position of the Enclosure may be stationary in altitude and azimuth, or it may

be moving across the sky at a slow (i.e., less than 100 arc-seconds per second) rate. The demand

position will generally come from the TCS, although the ECS engineering screen shall be

capable of generating positions during engineering operations.


Requirement Origin: Science Requirements

5.6- 0140 Tracking and Following

The ECS shall move each Enclosure assembly at a nearly constant rate tracking across the sky

under the influence of an external trajectory.

The ECS shall maintain the pointing requirements while following a smooth and continuous

trajectory for each axis. The ECS shall obey the specifications of the external trajectory as

defined by the interface document between the TCS and ECS (ICD 4.4-5.6).

While tracking, the ECS shall always maintain position within the tracking specification of the

Enclosure (SPEC-0010, 4.2-0025). If the ECS is given a new, non-continuous trajectory, it shall

indicate that it is out-of-position, and move the Enclosure efficiently to match the new trajectory.

An efficient motion shall use a direct path between the old and new trajectories, simultaneous

movement of all Enclosure assemblies, and optimum performance of the Enclosure servo control

systems.



Description: The TCS supplies a 20 Hz stream of time, position, and velocity data that the ECS

shall follow. Since the field-of-view of the telescope through the enclosure aperture is larger than

the 1.5 solar radius science target requirement, the TCS will typically send the ECS only the

trajectory for the sun center. This allows the telescope to perform small offsets, such as mosaic

maps, without affecting the position of the enclosure. For larger motions, such as between stars,

the TCS will issue a new trajectory that shall require the ECS to move the Enclosure efficiently

to the new trajectory path.


Requirement Origin: Science Requirements

5.6- 0150 Slewing

The ECS shall move the Enclosure axes at the maximum operational rate of travel when

covering large distances. The maximum operational rate of travel may be changed from the

default value, but may not exceed the design limit of each Enclosure axis. While covering large

distances the ECS shall not be required to meet the pointing requirements.

Description: The ATST Enclosure will spend the majority of time tracking one object, the Sun,

as it traverses across the sky. Consequently, the need to slew is greatly reduced from typical

“night-time” telescopes. However, the Enclosure will reposition in the morning and evening, and

will transit the zenith region during summer operations.


Requirement Origin: Science Requirements, Operational Requirements

5.6- 0160 Position Offset

The ECS shall accept offset positions from the current position. The ECS shall move to the new

position through the most efficient motion profile.

Description: Position offsets are generally used only in a maintenance or engineering mode,

where the TCS is not directly involved. The TCS will generally provide a new trajectory to the

ECS instead of an offset value.



5.6-0170 In Position

The ECS shall continuously determine and report if it is within the tolerances for the correct

position and correct velocity for all pointing and tracking motions. The tolerances for position

and velocity shall be user-configurable parameters to within the precision of the encoders. The

default tolerances shall be defined by the specifications for the Carousel and shutter drive

systems specifications.



Description: The ECS uses the “in position” Boolean flag to report whether it has met the

tolerances for pointing or tracking. Whenever this value changes (i.e., the tolerances are either

met or exceeded) the value is posted to the TCS. For pointing motions the value will be out of

position while the Enclosure is in motion and will become in position once the Enclosure reaches

and holds the position. For tracking motions, the ECS will report in position when the Enclosure

position and velocity values are within the tolerance for the input trajectory stream.

Verification: Design Review and Test


3.3 SERVO SYSTEMS REQUIREMENTS

5.6- 0210 Status Information

The ECS shall monitor and report the current status or change of status of the servo systems. At a

minimum, the following shall be reported through the required ATST communications system:

Position of the servo system as determined by the servo controller.

Position of the assembly as determined by the encoder.

States of all limit switches (software, electronic).

Velocity of the servo system as determined by the servo controller.

Velocity of the assembly as determined by the tachometer.

Acceleration of the servo system as determined by the servo controller.

Output torque or current as determined by the servo controller.

The position or state of all auxiliary devices, such as locking pins, brakes, etc.

Faults, warnings, or errors within the servo controller.

Status information that changes rapidly shall be reported at a rate no faster than 10 Hz per data

sample. This rate may be varied by the operator for each status item.

Description: Status information is broadcast across the ATST Common Services Framework

event system. The customary subscribers for the ECS status information are the TCS, the

engineering user interface, and the ATST engineering archive system. Status information is used

to portray the overall current configuration of the Enclosure, although it may also be used to

sequence operations or to provide historical information. To support these roles, the ECS should

broadcast status information that is timely, useful, and encompassing.



5.6-0220 High-Speed Status Information

The ECS shall provide the capability of selecting one or more status items for high-speed

reporting. The rate of such reporting shall be 2 KHz, or the maximum reporting capability of the

servo controller, whichever is slower. The high-speed output shall use the ATST archive service.



Description: High-speed status information differs from normal status information in its

specificity and speed. It is also used only for engineering purposes, and does not play a role in

normal operations. For the Enclosure, only the servo systems may generate useful data at a rate

necessary for this requirement. The servo systems may report data at high rates for values such

as instantaneous positions, rates, torques, and currents, along with other rapidly changing values

available to the servo system and deemed generally useful for engineering diagnostics.

Verification: Design Review and Test;

Requirement Origin: Operational Requirements

3.4 ANCILLARY MECHANICAL SYSTEMS REQUIREMENTS

5.6-0400 Dome cranes

The ECS shall monitor whether the enclosure dome cranes are stowed or deployed. It shall

provide this information as part of the status of the enclosure.

Description: The safe operation of the dome cranes is handled by the GIS.



5.6-0410 Cable Wraps

The ECS shall control the operation of any cable wraps that are part of the Enclosure. For

powered cable wraps, the ECS shall control the servo system and brakes, and monitor the

position and limit sensors. For non-powered cable wraps, the ECS shall monitor the position and

limit sensors.


Requirement Origin: Engineering

5.6-0420 Entrance Aperture Cover

The ECS shall control, monitor, and report the position of the carousel entrance aperture cover.



5.6-0430 Carousel Entrance Aperture Plate

If a carousel entrance aperture plate is used, the ECS shall control and report the position of the

carousel entrance aperture plate. The ECS shall be able to move the carousel entrance aperture

plate to specified positions within its range of travel. The ECS shall be able to calculate the

expected position of the carousel entrance aperture plate based upon the current position of the

TMA, and move it to that position. The ECS shall be able to enable and disable the feedback

system between the carousel entrance aperture plate and the TMA.



Description: The entrance aperture plate is used to limit the amount of sunlight that hits the M1

mirror aperture on the TMA. To position the entrance aperture plate, the ECS needs to be able to

calculate its expected position based upon the current position of the TMA. Once at this position,

the ECS needs to hunt for and find the laser signal broadcast from the TMA. Once found, the

entrance aperture servo system should automatically follow this signal.

Verification: Design Review and Test;


3.5 PERFORMANCE REQUIREMENTS

3.5.1 General Requirements

5.6- 1000 Time to Accept or Reject Command

The ECS shall accept or reject a command given on its public interface within 0.1 seconds.



5.6- 1005 Boot Time

The ECS shall be operational and ready to receive and act upon commands within 5 minutes of a

cold, power-off start of its hardware.



5.6- 1010 Application of Information

The ECS shall apply any external information (i.e., offsets or adjustments) within 0.1 seconds.

For commands, the application of information shall be defined as testing the command attributes

for validity, putting a command request on the action queue, and returning a scheduled event. For

event reception, the application of information shall be defined as using the event information in

a meaningful way (e.g., changing a parameter in a servo loop, cancelling an action, generating an

event).



5.6- 1015 Contributions to the Error Budget

The ECS shall not contribute to the degradation of the delivered image quality of ATST.

Description: The allowed image degradations for each ATST system are specified in SPEC-0009

(System Error Budget Plan) and further breakdowns are given in TN-0043 (Enclosure Error



Budget). Neither of these error budget allocations provide relief for the ECS in terms of pointing

accuracy.


Requirement Origin: Engineering, Science Requirements; SPEC-0010:5.0-xxxx.

5.6- 1020 Computer Resources

The ECS shall not consume more than 50% of its processing capability. The system shall not

consume more than 50% of its hard disk capacity.

Verification by: Analysis and Test;


3.6 OPERATIONAL AND INTERFACE REQUIREMENTS

5.6-1200 Telescope Control System

The ECS shall accept commands and configurations from the ATST Telescope Control System

(TCS) for all operational and engineering activities. The commands, configurations, and events

used by the interface are defined in the interface control document between the TCS and TMA

(ICD-4.4/5.6).

Description: The TCS is the hierarchically superior system to the ECS. As such, it is responsible

for controlling the activities of the ECS and Enclosure. The interface control document ICD-

4.4/5.6 defines the specific methods the TCS and ECS shall use to perform all required and

specified TMA control operations.



5.6- 1210 Common Services Framework

The ECS shall provide a software interface that conforms to the ATST interface for the Common

Services Framework. The Common Services Framework interface shall be controlled by the

ATST, the system shall use the interface defined by the appropriate ICD.

The system shall implement the ATST Common Services Framework controller model. The

system shall provide controlling systems with information on its state and current configuration.

The system shall implement the command-action model defined by the ATST Common Services

Framework.

The Common Services Framework interface describes three levels of component interface: (a)

the containers and container managers the ECS components shall operate within; (b) the device

model the ECS components shall implement; and (c) the services the system shall employ to

interact with the ATST software system. A description of using the Common Services

Framework can be found in SPEC-0022, ATST Common Services Framework Users’ Manual.



Verification by: Design Review;


5.6- 1220 Global Interlock System

In the event that the system must respond to any unsafe conditions (e.g., personnel or equipment

safety) the ECS shall interact with the GIS as defined by the TCS-ECS ICD. The system shall

receive an interlock signal from the GIS and place itself into a "safe" condition within 0.1

seconds of receipt of the interlock signal. The definition of a safe condition of the system and its

associated hardware is the default state (Specification 5.6-0050).


Requirement Origin: Safety, Engineering

5.6- 1230 Ethernet on the Control LAN

The ECS shall use Ethernet for all communications on the Control LAN.

Verification by: Inspection;


5.6- 1250 Configuration Identifiers

The ECS shall use the proper configuration identifier in all communications. A configuration

identifier is supplied to the system for each and every configuration sent to it from the TCS. The

system shall use configuration identifiers to track actions throughout the system.



5.6- 1300 Engineering Display

The ECS shall supply an engineering display for the system operating software. The engineering

display shall exercise all the functionality of the system and shall be useful for actual operations

within the ATST. The engineering display shall use the Common Services Framework interface.



5.6- 1305 Time Standard

The ECS shall use International Atomic Time (TAI) in all calculations. It shall use TAI in all

pointing data distributed to its subsystems.

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





5.6- 1310 Engineering Operations

The ECS shall perform engineering operations only when a hardware lockout is activated.

Engineering operations are conditions that can possibly be dangerous to equipment or personnel,

and are noted throughout the specifications.

Examples of engineering operations include: moving a telescope axis beyond the software range

of travel, moving the Carousel in azimuth and elevation without coordinating with the TMA, and

modifying servo controller microcode. Means of hardware lockout may include use of the GIS,

Castell-type keys, and/or manual hand paddle-type devices. The ECS shall detect the use of each

and any of these devices.


Requirement Origin: Safety, Engineering

3.7 OTHER REQUIREMENTS

3.7.1 Acceptance Testing Requirements

5.6- 1400 Test Software

Contractor shall supply the test software (source, executable, dynamic libraries, etc.) for all

system requirements specified in this document.



5.6- 1405 Simulation

Contractor shall provide a simulator of the Enclosure, including interfaces, major hardware

components, servo loops, and interlocks. This simulator shall be capable of communicating with

the TCS in place of the actual ECS software.


Requirement Origin: Engineering, Operational Requirements.

3.7.2 Documentation Requirements

5.6-2000 Final Design

Contractor shall provide a Software Design Document (SDD). This document shall include all

details necessary to construct the system. During construction, this document shall be updated to

show any design modifications made during construction.





5.6- 2010 Public Interfaces

Contractor shall document all public software interfaces from the source code using doxygen,

which is a publicly available software documentation tool. Alternative source code documenting

tools may used with the permission of the ATST. The public interfaces shall be attached to the

SDD as an appendix.

Public software interfaces shall be used by the Common Services Framework and the

engineering user interface. When employing a tool such as doxygen, Contractor shall properly

document the source code and shall provide a public interface document.



5.6- 2020 Operator’s Manual

Contractor shall provide an operator’s manual that describes the proper use of the system. The

manual shall describe operation during normal observations, setup, troubleshooting, and

engineering modes.



3.7.3 Safety Requirements

5.6- 3000 Respond to Global Interlock

The system shall detect and respond to a global interlock signal. Upon receiving the GIS signal,

the ECS shall stop all ongoing actions in the ECS, reject all queued and incoming configurations,

and move the state of the ECS and all subsystems to the default state.


Requirement Origin: Safety, Operations.

5.6-3010 Hazard Analysis

The system shall include procedures, operator warnings, status and interlock signals as

determined necessary by Hazard Analysis, as described in SPEC-0010.


Requirement Origin: Safety, Operations.

Request for Waiver

RFW Number: 15813-RFW-314

1

Date Requested: 10th October 2013

RFW Title: Fast Data Acquisition

Contract No: C22019N

Requestor: Esther Fernández (AEC IDOM)

WBS: 5.6; 5.7

Document/Drawing Infringed Upon: SPE-0082

Summary of Issue: Modifications to requirement 5.6-0220 High-Speed Status

Information of SPE-0082

Next Higher Item Level Affected:

Items External to Contract Affected:

Proposed Change and Justification:

The high-speed data acquisition functionality is proposed to be implemented in the EMCS

PLC. Triggering accessible from the EMCS HMI and also from the ECS HMI under the

following conditions:

- Acquisition rate at the period of the drives control loops and not higher than 20 ms

- The data to be collected is as listed below

Time of start

Acquisition period

Azimuth Data:

Commanded position from the ECS

Motor Velocity (1-8)

Motor Torque (1-8)

Encoder Position (1-2)

Altitude Data:

Commanded position from the ECS

Motor Velocity (1-4)

Motor Torque (1-4)

Encoder Position (+x,-x)

- Maximum time of acquisition is fixed to 5 minutes (considering 20 ms of acquisition rate)

but it shall be possible to stop the acquisition at any time once it is started, both from ECS and

EMCS HMIs

- Acquisition data will be available in a .csv file at the EMCS HMI PC, easily exportable to an

Heather Marshall

Text Box

ATST RFW-0041

Request for Waiver


2

excel file. The file name will be generated automatically by the EMCS.

- The following info/data will be interchange between the ECS and EMCS regarding this

issue:

ECS => EMCS

Start acquisition command

Stop acquisition command

EMCS => ECS

Status of acquisition (e.g. not active, running, finished)

Data acquisition file name

Corrective Actions Already Attempted:

Implementation

The functionality has already been implemented in the EMCS and correct behavior and

generation of data acquisition files verified.

ECS/EMCS ICD will be updated once proposed change is agreed and corresponding

programming will be made on both systems

Documents Attached: example of an acquisition file generated by the EMCS

Waiver, if granted, Adversely Affects:

Performance: Reliability: Cost:

Dimensions: Safety: Software:

Weight: Maintenance: Other Risk:

Impact if waiver not granted:

Concessions Offered:

Contractor

Project Manager Gaizka Murga

Signature

Date 10th

of October 2013

Work Package

Manager Esther Fernández

Signature

Date 10th

of October 2013

Request for Waiver


3

ADMINISTRATIVE USE ONLY

Change Control Board Decision: APPROVED

Approval Date: 30-October-2013

Rejected Date: