Post on 28-Jun-2020
Project Documentation Document SPEC-0082
Revision B
Advanced Technology Solar Telescope 950 N. Cherry Avenue Tucson, AZ 85719 Phone 520-318-8102 atst@nso.edu 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
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: 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
Enclosure Control System Specifications
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
Enclosure Control System Specifications
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.
Enclosure Control System Specifications
SPEC-0082, Revision B Page 2 of 18
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.
Enclosure Control System Specifications
SPEC-0082, Revision B Page 3 of 18
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.
Enclosure Control System Specifications
SPEC-0082, Revision B Page 4 of 18
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
Enclosure Control System Specifications
SPEC-0082, Revision B Page 5 of 18
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.
Enclosure Control System Specifications
SPEC-0082, Revision B Page 6 of 18
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
Requirement Origin: Engineering, Operational Requirements
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
Enclosure Control System Specifications
SPEC-0082, Revision B Page 7 of 18
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
Requirement Origin: Engineering, Operational Requirements
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
Enclosure Control System Specifications
SPEC-0082, Revision B Page 8 of 18
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.
Verification by: Design Review and Test;
Requirement Origin: Safety, Operational Requirements
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.
Verification by: Design Review and Test;
Requirement Origin: Safety, Operational Requirements
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.
Verification by: Design Review and Test;
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.
Verification by: Design Review and Test;
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
Enclosure Control System Specifications
SPEC-0082, Revision B Page 9 of 18
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.
Verification by: Design Review and Test;
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.
Verification by: Design Review and Test;
Requirement Origin: Safety, Operational Requirements
Enclosure Control System Specifications
SPEC-0082, Revision B Page 10 of 18
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.
Verification by: Design Review and Test;
Requirement Origin: Safety, Operational 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.
Verification by: Design Review and Test;
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.
Enclosure Control System Specifications
SPEC-0082, Revision B Page 11 of 18
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.
Verification by: Design Review and Test;
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.
Verification by: Design Review and Test;
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.
Verification by: Design Review and Test;
Requirement Origin: Science Requirements, Operational Requirements
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.
Enclosure Control System Specifications
SPEC-0082, Revision B Page 12 of 18
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
Requirement Origin: Science Requirements, Operational Requirements
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.
Verification by: Design Review and Test;
Requirement Origin: Safety, Operational Requirements
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.
Enclosure Control System Specifications
SPEC-0082, Revision B Page 13 of 18
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.
Verification by: Design Review and Test;
Requirement Origin: Safety, Operational Requirements
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.
Verification: Design Review and Test
Requirement Origin: Engineering
5.6-0420 Entrance Aperture Cover
The ECS shall control, monitor, and report the position of the carousel entrance aperture cover.
Verification: Design Review and Test
Requirement Origin: Engineering
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.
Enclosure Control System Specifications
SPEC-0082, Revision B Page 14 of 18
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;
Requirement Origin: Engineering
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.
Verification by: Design Review and Test;
Requirement Origin: Engineering
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.
Verification by: Design Review and Test;
Requirement Origin: Engineering, Operational Requirements
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).
Verification by: Design Review and Test;
Requirement Origin: Engineering, Operational Requirements
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
Enclosure Control System Specifications
SPEC-0082, Revision B Page 15 of 18
Budget). Neither of these error budget allocations provide relief for the ECS in terms of pointing
accuracy.
Verification by: Design Review and Test;
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;
Requirement Origin: Engineering
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.
Verification: Design Review and Test
Requirement Origin: Engineering, Operational Requirements
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.
Enclosure Control System Specifications
SPEC-0082, Revision B Page 16 of 18
Verification by: Design Review;
Requirement Origin: Engineering, Operational Requirements
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).
Verification by: Design Review;
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;
Requirement Origin: Engineering
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.
Verification by: Design Review and Test;
Requirement Origin: Engineering
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.
Verification by: Design Review;
Requirement Origin: Engineering, Operational Requirements
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.
Enclosure Control System Specifications
SPEC-0082, Revision B Page 17 of 18
Verification by: Inspection;
Requirement Origin: Engineering, Operational Requirements
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.
Verification by: Design Review and Test;
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.
Verification by: Inspection;
Requirement Origin: Engineering
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.
Verification by: Design Review and Test;
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.
Verification by: Inspection;
Enclosure Control System Specifications
SPEC-0082, Revision B Page 18 of 18
Requirement Origin: Engineering, Operational Requirements
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.
Verification by: Inspection;
Requirement Origin: Engineering, Operational Requirements
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.
Verification by: Inspection;
Requirement Origin: Engineering, Operational Requirements
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.
Verification by: Design Review and Test;
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.
Verification by: Design Review and Test;
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
Request for Waiver
RFW Number: 15813-RFW-314
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
RFW Number: 15813-RFW-314
3
ADMINISTRATIVE USE ONLY
Change Control Board Decision: APPROVED
Approval Date: 30-October-2013
Rejected Date: