Project Documentation Document SPEC-0019
Revision F
Telescope Control System
Specification
Bret Goodrich Software
September 2016
Name Date
Released By : Joseph McMullin
Project Manager 14-Oct-2016
Telescope Control System Specification
SPEC-0019, Revision F Page ii
REVISION SUMMARY:
1. Date: October 5, 2003
Revision: 0.1
Changes: Initial Document
2. Date: November 17, 2003
Revision: 0.2
Changes: Function and performance requirements
3. Date: February 6, 2004
Revision: 0.3
Changes: New Template
4. Date: March 15, 2004
Revision: 0.4
Changes: Additional Requirements
5. Date: March 28, 2004
Revision: 0.5
Changes: Added introduction and descriptions
6. Date: April 8, 2004
Revision: 1.0
Changes: Changes from review.
7. Date: March 22, 2005
Revision: A
Changes: Release after PDR.
8. Date: May 11, 2010
Revision: B
Changes: Updates for construction
9. Date: December 4, 2012
Revision: C
Changes: Changes for requirements in scanning, wavefront control, and weather station as detailed
in CR-0305.
10. Date: May 21, 2013
Revision: D
Changes: Added rate motion offset specification 4.4-0190 as detailed in CR-0375. Fixed typos.
11. Date: September 11, 2013
Revision: E
Changes: Changes per CR-0415: Added AO loop off on move, 4-4-0220. Modified tracking
requirement, 4.4-0165, to change heliocentric to helioprojective definition.
12. Date: March 22, 2016
Revision: F
Changes: New specification for WCCS modes. Added requirements from CR-0563. Added
requirement from SPEC-0157. Further changes and approval per CR-0742 in Sept. 2016
Telescope Control System Specification
SPEC-0019, Revision F Page iii
Table of Contents
1. OVERVIEW ........................................................................................................... 1 1.1 DOCUMENT SCOPE ................................................................................................. 1 1.2 DOCUMENT LAYOUT ................................................................................................ 1
1.3 REQUIRED DOCUMENTS .......................................................................................... 1 1.4 VERIFICATION METHODS ......................................................................................... 1 2. TELESCOPE CONTROL SYSTEM DESCRIPTION ............................................. 3 2.1 OVERVIEW .............................................................................................................. 3 2.1.1 Pointing and Tracking .................................................................................................. 3 2.1.2 Trajectories ................................................................................................................... 4 2.1.3 Wavefront Control ........................................................................................................ 4 2.2 SUBSYSTEMS ......................................................................................................... 5
2.3 CONTROL FLOW ..................................................................................................... 6 2.3.1 Commands and Configurations .................................................................................. 6 2.3.2 Events ........................................................................................................................... 7 2.3.3 Global Interlocks .......................................................................................................... 7 3. FUNCTIONAL REQUIREMENTS ......................................................................... 8 3.1 GENERAL REQUIREMENTS ....................................................................................... 8
3.2 POINTING ............................................................................................................. 10 3.3 WAVEFRONT CORRECTION .................................................................................... 19
3.4 SUBSYSTEMS ....................................................................................................... 21 3.5 PERFORMANCE REQUIREMENTS ............................................................................. 25 3.6 INTERFACE REQUIREMENTS ................................................................................... 26
4. OTHER REQUIREMENTS .................................................................................. 30 4.1 DOCUMENTATION REQUIREMENTS .......................................................................... 30
4.2 SECURITY REQUIREMENTS ..................................................................................... 30 4.3 MAINTAINABILITY REQUIREMENTS .......................................................................... 31
4.4 SAFETY REQUIREMENTS ........................................................................................ 31
Telescope Control System Specification
SPEC-0019, Revision F Page 1 of 32
1. OVERVIEW
This document defines the specification for the DKIST Telescope Control System (TCS). The
TCS is one of the four principal software systems, responsible for the control of the telescope
assembly and associated hardware.
1.1 DOCUMENT SCOPE
This document includes all requirements necessary to complete the construction of the DKIST
Telescope Control System. Requirements are derived from the DKIST Science Requirements
(SPEC-0001), the Operational Concepts Definition (SPEC-0036), the DKIST Software Design
Requirements (SPEC-0005), and Software Concepts Definition (SPEC-0013). Requirements for
the various DKIST subsystems are called out in the design requirements for that subsystem,
although the TCS requirements for such subsystems are defined here.
1.2 DOCUMENT LAYOUT
Requirements are identified by a requirement heading consisting of an underlined requirement
number and associated title, as in:
4.1-0001 Language support
The paragraph that follows the requirement heading is a detailed description of the requirement.
Some requirements may have additional paragraphs that describe a common or preferred design
solution, or may further illuminate the requirement through an example.
1.3 REQUIRED DOCUMENTS
Documents referenced by this document are:
DKIST Science Requirements, SPEC-0001.
Software Design Requirements, SPEC-0005.
Telescope Mount Assembly Specifications, SPEC-0011.
Software Concepts Definition, SPEC-0013.
Common Services Framework User’s Manual, SPEC-0022-1.
Operational Concepts Definition, SPEC-0036.
Thompson, W.T., "Coordinate systems for solar image data", A&A 449, 791-803 (2006).
Telescope Control Hand Paddle Specification, SPEC-0157
1.4 VERIFICATION METHODS
Included in each major numbered specification listed herein this document 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.
Telescope Control System Specification
SPEC-0019, Revision F Page 2 of 32
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,
computational fluid analyses, closed form analyses, etc.
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.
Telescope Control System Specification
SPEC-0019, Revision F Page 3 of 32
2. TELESCOPE CONTROL SYSTEM DESCRIPTION
The DKIST Telescope Control System (TCS) is one of the four software principal systems that
control the operation of the DKIST facility. Together with the Observatory Control System
(OCS), the Data Handling System (DHS), and the Instrument Control System (ICS), these
systems completely control the lifecycle of an DKIST experiment. A full description of
experiments, their lifecycle, and the principal systems can be found in the DKIST Software
Concepts Definition (SPEC-0013).
2.1 OVERVIEW
The DKIST and its operational modes are somewhat different from modern nighttime telescopes.
The primary target is the Sun and nearby coronal areas. The telescope will follow features that
move upon a differentially rotating solar surface. The DKIST also supports a high-order adaptive
optics system that can both significantly improve the resolution of the telescope optics and act as
a correlation tracker for objects of interest. Additionally, observations performed by the DKIST
tend to be both of long duration and of significant instrumentation complexity. Common solar
observations involve several instruments or cameras, extended setup and configuration, and
substantial interactions with the observer. Features observed may grow, evolve, or disappear
during observations, requiring dynamic capabilities to change setups or targets during an
observing run.
2.1.1 Pointing and Tracking
Operationally, the most important function of the TCS is determining and delivering precise
pointing information to the TCS subsystems. Pointing and tracking the Sun is a well-understood
problem, although several issues still reduce the overall precision of the calculation. Specifically,
the conversion to both heliocentric and heliographic coordinate systems requires that the solar
axis of rotation be known, and the conversion to heliographic coordinates requires a model for
differential rotation rates based upon solar latitude.
The DKIST has pointing requirements for both open-loop and closed-loop tracking as defined by
the TMA specifications, SPEC-0011, Requirements 1.1-0140 through 1.1-0170. The open-loop
requirements should be achieved with a standard pointing map to correct for flexure and other
recurrent errors. Closed-loop pointing requires a feedback mechanism to determine the non-
recurrent errors. There are two possible sources for the error signal: an off-axis acquisition
telescope attached to the primary mirror cell and the active/adaptive optics system(s). Each of
these has particular advantages and disadvantages. The acquisition telescope may be available as
a guide signal source, but may not have the spatial or temporal resolution to provide a guide
signal and suffers from non-common-path alignment errors. The active and adaptive optics
systems will have the required resolution, but cannot determine absolute positional error.
During construction and integration, another input guide signal will be available: a portable
stellar wavefront sensor. This sensor will be inserted into the telescope beam at locations from
the primary focus to the coudé room floor. It will be used on stellar point sources and deliver an
accurate and absolute guide reference signal. After integration it will be removed from the
telescope.
Telescope Control System Specification
SPEC-0019, Revision F Page 4 of 32
Therefore, two types of closed-loop tracking models are required. The first accepts absolute
reference positions such as stars or a point on the solar limb. This input is used to adjust the
pointing errors from the model while keeping the absolute position fixed. The second accepts
relative reference positions from objects that are ‘floating’ in the coordinate system. This input is
used to offset from the pointing model error and modify the absolute position.
2.1.2 Trajectories
The position of a target object must be recalculated often enough to provide a precise trajectory
for the mount and enclosure. Although the allowable positional error of the enclosure is quite
large, allowing for intermittent positional updates to the Enclosure Control System, the mount
requires a stream of data of 20 Hz or better rate. The updates contain the required altitude and
azimuth of the telescope mount assembly, the rotational angle of the coudé rotator, current
tracking velocities for each axis, and a timestamp defining the time the position is valid. Fifty
milliseconds later another update will arrive at the Mount Control System.
2.1.3 Wavefront Control
The TCS controls the operation of the DKIST wavefront correction systems. The wavefront
correction control system determines the figure of the primary mirror and the positions of the
secondary and feed optics tip-tilt mirrors. Via the deformable mirror (DM) and AO tip-tilt
mirrors the wavefront correction adaptive optics system internally corrects the image wavefront
before it is sent to the instruments. The wavefront correction control system requires wavefront
correction parameters to be offloaded to other TCS subsystems: the M1 mirror, the M2
tip/tilt/focus, and the feed optics tip/tilt. The parameters directly sent to the subsystems are
considered to be the wavefront correction data stream.
The TCS performs three wavefront correction operations: it controls the state and operational
modes of the wavefront correction systems, it tells the TCS subsystems which elements of the
data stream to monitor, and it accepts position offloads from the wavefront correction control
system. The TCS itself does not sample or rebroadcast the wavefront correction data stream;
doing so would place an unacceptable delay on the reception of correction values.
Figure 1: The flow of wavefront correction data through the TCS subsystems.
Mount
M1
M2
M3/QSA
M6/QSA
M5/TTM
M10/DM
AOS
aOSWCCS
3 KHz 3 KHz1 KHz1 Hz 1 Hz 1 Hz.05 Hz.1 Hz 1 Hz
TCS MCS M1CS M2CS FOCS WCCS
Pointing
Telescope Control System Specification
SPEC-0019, Revision F Page 5 of 32
2.2 SUBSYSTEMS
The TCS operates the mechanical components of the telescope through a number of computer
subsystems. The subsystems are responsible for the actual servo or hardware control, while the
TCS coordinates their activities. Subsystems control the enclosure, primary, secondary, and feed
mirrors, adaptive and active optics, and the thermal systems.
The Mount Control System (MCS) controls the Telescope Mount Assembly (TMA), including
the altitude and azimuth drives, coudé rotator, mirror covers, cable wrap assemblies, and other
components associated with the mount operation. The TCS sends trajectory data to the MCS at a
20 Hz (or better) rate.
The Enclosure Control System (ECS) operates the DKIST enclosure, including the carousel,
shutter, aperture plate, aperture cover, and other auxiliary equipment attached to or associated
with the enclosure. The TCS sends trajectory data to the ECS at a 1 Hz (or better) rate.
The M1 Mirror Control System (M1CS) is responsible for the primary mirror performance, its
figure and thermal equilibrium. The TCS controls the wavefront correction mode of the M1CS.
The Top End Optical Assembly Control System (TEOACS) controls the secondary mirror,
including its tip-tilt-focus and thermal requirements. It also controls the heat stop, Lyot stop, and
occulter mechanisms located at the prime focus. The TCS controls the pointing and wavefront
correction mode of the TEOACS.
The Feed Optics Control System (FOCS) operates the smaller optical components required to
bring an image to an instrument. The components associated with the FOCS are the mirrors M3
through M6, and the thermal monitoring for each.
Figure 2. Command control flow for the TCS and its subsystems. The TCS transmits configuration
commands to its subsystems (i.e., operational or calibration modes, telescope position, wavefront
correction strategy, etc.). It receives status and health information back.
TCS
WavefrontPA&C TEOAM1AcquisitionFeed
Optics
EnclosureMount
DHS
OCS
Configurations
TCS headers
ConfigurationsTrajectories
Wavefront Strategy
Status Status Status Status
Status
StatusStatus
Status
wavefront offload datafast tip-tilt control
calibration control
Telescope Control System Specification
SPEC-0019, Revision F Page 6 of 32
The Wavefront Correction Control System (WCCS) delivers corrected images to the instruments.
The components associated with the WCCS are the adaptive optics system, the active optics
system, and the deformable and fast tip-tilt mirrors. The TCS determines how the WCCS
distributes wavefront correction data to the other subsystems.
The Acquisition Control System (ACS) provides an image of the solar disk. The acquisition
camera allows the operator to locate and point to solar features.
The Polarimetry Analysis & Calibration (PA&C) system operates the polarizers and calibration
components located at the Gregorian Optical Station and elsewhere on the telescope. The TCS
configures these components to match the current observational mode of the observatory.
2.3 CONTROL FLOW
The TCS operates upon configurations passed to it from the OCS. Configurations are passed
within commands defined by the principal systems interface (SPEC-0013), and are themselves
defined by the OCS-to-TCS interface. Configurations and commands inside the TCS are
described here.
2.3.1 Commands and Configurations
The list of available TCS commands is quite short and follows the command-action-response
model of CSF (SPEC-0022-1). Briefly, the TCS can be commanded to start or resume an action,
cancel or pause an ongoing action, and set or get an attribute. Each of these commands may send
a configuration in the argument to further define the operation. The configuration is a list of
attribute-value pairs, where the attributes have been defined by the TCS. Commands are
expected to have a short life on the TCS; 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 is shown by aborting a running command. If a
command does not return until the action is complete, a subsequent command to abort the
command cannot use the same command channel. It must either perform a block and wait
operation or use a second out-of-band channel to get its message to the TCS. Clearly this is not a
desired behavior.
Commands arrive from either the OCS or the TCS engineering user interface, depending upon
whether the command is a typical operational command (the OCS) or an engineering activity
(the TCS engineering user interface). The format of the command is identical in both cases, and
the source is irrelevant to the TCS.
There are several important configuration attributes. The configuration identifier is a unique
string that identifies the experiment and observation being performed. This identifier is required
in every configuration, every event, and every log message; by doing so the state of a particular
observation can be determined at any time. The TCS uses the configuration identifier when it
broadcasts trajectories or sends commands to its subsystems.
Also required in the TCS configuration is an attribute or attributes that define the action to be
performed. To start an action the required attributes are the observational task, position of the
target object, and the coordinate system. Additional attributes may further define the action, such
Telescope Control System Specification
SPEC-0019, Revision F Page 7 of 32
as a non-default track rate, a scan pattern, start time, or a particular adaptive/active optics
configuration.
2.3.2 Events
Events are the mechanism that actions use to both broadcast their state and deliver asynchronous
signals. The state of an action moves between scheduled, running, paused, and done depending
upon the command executed and the results of the ongoing action. These states are broadcast as
events. Listeners subscribe to events 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 ICS (feedback from instrument commands, position information), the
DHS (headers), and the TCS subsystems (trajectory streams, wavefront streams).
The TCS is also a subscriber to events. The subsystems generate state events when actions
commanded by the TCS are completed or when asynchronous alarms occur. Other principal
systems may also generate events that the TCS may be interested in receiving.
2.3.3 Global Interlocks
The TCS 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 and place them into a “safe” configuration upon reception of an
interlock. 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 TCS is required to detect that an interlock condition exists on either itself or one of its
subsystems. The response of the TCS to an interlock condition is to place itself into a suitably
safe configuration. Upon the release of the interlock condition the TCS will return to a normally
operating condition through an operator’s command. Neither the TCS nor the subsystems will
need to be rebooted or restarted.
The TCS monitors the GIS to determine its own state. If the TCS 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 TCS to both prevent
wrongly changing the state of the observation and to provide additional safety control by
disabling mechanisms and halting trajectory streams.
Telescope Control System Specification
SPEC-0019, Revision F Page 8 of 32
3. FUNCTIONAL REQUIREMENTS
3.1 GENERAL REQUIREMENTS
The general requirements define those characteristics all DKIST software systems must
incorporate to operate together within the DKIST software framework.
4.4-0001 Principal System
The TCS shall perform as one of the four software principal systems; the others are the
Observatory Control System (OCS), Data Handling System (DHS), and Instrument Control
System (ICS). As a principal system the TCS shall coordinate its actions with the other principal
systems to perform all science and operational activities at the observatory. The TCS shall follow
the coordination commands delivered from the OCS to control the telescope subsystems and to
communicate status information back to the OCS.
The basic communications and control philosophy of the DKIST software systems is described
in the DKIST Software Operational Concepts (SPEC-0013). The TCS shall operate in an
environment where coordinated activities are required.
Verification: Design Review, Inspection
Source: Engineering (SPEC-0013)
4.4-0002 Subsystems Master
The TCS shall control the DKIST and all telescope subsystems. It shall be responsible for
coordinating any activities that use the telescope and its subsystems. It shall control directly the
telescope subsystems, read their status, and provide direction as required.
Verification: Design Review, Inspection
Source: Engineering (SPEC-0013)
4.4-0003 Best Software Practices
The TCS shall conform to the DKIST software development requirements. Under these
requirements the TCS shall:
Use the DKIST Common Services Framework for all communications, commands,
events, logging, archiving, and database functions;
Use the DKIST Common Services Framework to build Controllers for, at a minimum, the
top-level TCS controller and communications with the telescope subsystems. A controller
is defined in the DKIST Common Services Framework User’s Manual (SPEC-0022-1).
Use software libraries approved by DKIST for the implementation of the TCS.
Telescope Control System Specification
SPEC-0019, Revision F Page 9 of 32
Deliver documented source code, compiled object code, associated libraries, build and
release materials necessary to edit, build, compile, link, load, run, test, and debug the
TCS.
Deliver a user’s manual for the TCS.
Use a source code repository for all developed TCS software, and make the repository
available to AURA during construction.
Verification: Design Review, Inspection
Source: Engineering (SPEC-0005)
4.4-0004 Logging
The TCS shall log pertinent data to the DKIST facility log mechanism. Pertinent data shall
include, but not be limited to, state changes, configuration changes, errors, alarms and warnings,
and any other information that may assist in reconstructing the operation of the TCS. The TCS
logging level shall be user selectable for the depth of information.
Verification: Design Review, Test
Source: Engineering (SPEC-0005)
4.4-0005 Default State
The TCS shall have a defined default state for all operations and control loops that it controls,
including but not limited to: pointing and tracking, thermal control, and wavefront correction.
Unless approved otherwise by AURA, the default state of any TCS component or controller shall
be an inert, non-moving, non-powered condition. The TCS shall assume this state on an interlock
condition, initialization command, shutdown, or when demanded through the software interface.
Verification: Design Review, Test
Source: Engineering (SPEC-0005, SPEC-0013)
4.4-0006 Restart
The TCS shall perform all action requests sent through its public interface without need of reboot
or re-initialization, unless the request demands such an operation.
Verification: Design Review, Analysis
Source: Engineering (SPEC-0005)
4.4-0007 Health
The TCS shall be capable of determining its health and report that health through the Common
Services Framework health mechanism. The TCS shall be able to determine if it is performing
within its operational specifications, and return a result of good, ill, or bad for TCS health states
Telescope Control System Specification
SPEC-0019, Revision F Page 10 of 32
that are operational, performing below specification, and not performing at all, respectively. The
TCS health report shall include information on the particular TCS systems that are performing
below specification and the possible reason for the poor health.
Verification: Design Review, Test
Source: Engineering (SPEC-0005), Operations (SPEC-0036)
4.4-0008 Availability
The TCS shall always be available to accept or reject commands. It shall not block any command
request while processing another command request.
This requirement prevents the TCS from processing a command in 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: Design Review, Test
Source: Engineering (SPEC-0005)
4.4-0010 Persistence of Data
Static information required by the TCS to operate shall be recoverable after a restart or reboot.
This information may include, but is not limited to, pointing maps, zero points, ephemeris, and
configuration parameters. Dynamic information, such as current position and state, may be reset
or recovered after initialization.
Verification: Design Review, Test
Source: Engineering (SPEC-0005)
3.2 POINTING
The pointing requirements define the functional operations of the TCS: the motions of the
telescope mount assembly (TMA) and enclosure.
4.4-0100 Time
The TCS shall use International Atomic Time (TAI) in all calculations. It shall use TAI in all
pointing data distributed to its subsystems.
The TCS shall provide Coordinated Universal Time (UTC) in all displays and status events.
Verification: Test
Source: Engineering (SPEC-0005), Operations (SPEC-0036)
Telescope Control System Specification
SPEC-0019, Revision F Page 11 of 32
4.4-0105 Solar Ephemeris
The TCS shall calculate the current solar ephemeris, including but not limited to, local apparent
sidereal time, position and rate of motion of the solar disk, the solar rotational axis, and the
differential rotation rates for solar latitudes. The ephemeris data shall have a better accuracy and
precision than that required for pointing and tracking of the telescope mount.
Verification: Design Review, Test
Source: Science (SPEC-0001), Operations (SPEC-0036)
4.4-0110 Ephemeris Prediction
The TCS shall provide a stand-alone CSF service to perform solar, planetary, and stellar
ephemeris calculations on demand for requested epochs.
The service shall calculate on demand the solar ephemerides and telescope positions for
requested epochs or conditions. In particular, the service shall be capable of calculating time and
location for any date of the following: sunrise, sunset, 10 degrees elevation both after sunrise and
before sunset, local noon, zenith blind spot entrance and exit. The service shall calculate the
values for any date between years 2000 and 2100.
Verification: Design Review, Test
Source: Science (SPEC-0001), Operations (SPEC-0036)
4.4-0120 Stellar Ephemeris
The TCS shall calculate the current ephemeris for any input stellar coordinate. The ephemeris
data shall contain the information necessary to point the telescope mount assembly at the object
to the precision and accuracy of the telescope as found in SPEC-0011 Req. 1.1-0170. The TCS
shall provide an input mechanism to accept stellar coordinates in Right Ascension, declination,
and epoch.
Verification: Design Review, Test
Source: Science (SPEC-0001), Operations (SPEC-0036)
4.4-0125 Planetary Ephemeris
The TCS shall calculate the current ephemeris for any planet or major solar system body up to
the year 2100. The ephemeris data shall contain the information necessary to point the telescope
mount assembly at the object to the precision and accuracy of the telescope as found in SPEC-
0011 Req. 1.1-0170. The TCS shall provide an input mechanism to accept both the IAU name of
the body and the orbital parameters of the body.
Verification: Design Review, Test
Source: Science (SPEC-0001), Operations (SPEC-0036)
Telescope Control System Specification
SPEC-0019, Revision F Page 12 of 32
4.4-0130 Pointing
The TCS shall providing pointing information to the telescope altitude, azimuth, and coudé
rotator controllers at a rate of at least 20 Hz and within the accuracy and precision requirements
for these systems. All pointing information shall be corrected for repeatable errors due to flexure,
temperature, atmosphere, and wavelength.
The TCS shall provide pointing information for the following Telescope Mount Assembly
(TMA) controllers:
The TMA azimuth: The pointing information for the TMA azimuth positions shall be
given in degrees from true North, with negative values indicating positions counter-
clockwise as viewed from above.
The TMA altitude: The pointing information for the TMA altitude shall be given in
degrees from the horizon, with values greater than 90 degrees indicating motion beyond
the zenith.
The TMA coudé rotator: The pointing information for the TMA coudé rotator shall be
given in degrees from true North, with negative values indicating positions counter-
clockwise as viewed from above.
The PA&C Gregorian focus: The pointing information for the Gregorian focus shall be
given in degrees from the TMA structure north.
The Prime focus: The pointing information for the prime focus shall be given in degrees
from the TMA structure north.
Verification: Design Review, Test
Source: Engineering (SPEC-0013)
4.4-0135 Pointing Maps
The TCS shall provide a tool for creating pointing maps. This tool shall include features for
target acquisition, data collection, pointing map calculation, pointing map storage and retrieval.
The pointing map shall contain error information for altitude, azimuth, and rotator.
The TCS shall perform pointing map operations on demand on night time point sources.
The TCS shall utilize a pointing map that covers the sky area the DKIST telescope can see, per
SPEC-0011, Requirement 1.1-0140. This pointing map shall contain errors for the altitude,
azimuth, and coudé rotator. The map shall have a sufficient sample interval to provide the
required open-loop pointing accuracy and precision.
Verification: Design Review, Test
Source: Operations (SPEC-0036), Engineering (SPEC-0011)
Telescope Control System Specification
SPEC-0019, Revision F Page 13 of 32
4.4-0137 Open-loop Pointing Offset
The TCS shall provide an interface to allow an external system to apply an offset to the telescope
pointing. The input offset shall be used by the TCS as an additional open-loop corrective error.
The DKIST telescope may have additional recurring errors from sources not capable of being
sampled during the pointing maps. Such errors may be from thermal gradients placed on the
various telescope mechanical structures and thermal offsets between nighttime pointing maps
and daytime operations.
Verification: Design Review, Test
Source: Engineering (SPEC-0011)
4.4-0140 Pointing Correction Mechanism
The TCS shall provide a mechanism to correct the open-loop pointing error of the telescope. This
mechanism shall be capable of running under command from the operator or OCS at any time.
The preferred mechanism for correcting pointing errors is to position the telescope at three or
more locations on the solar limb, manually adjust the position at each position, and then calculate
the positional error based upon these inputs.
Verification: Design Review, Test
Source: Operations (SPEC-0036)
4.4-0145 Scanning
The TCS shall perform scanning motions under command from the OCS. Scanning motions shall
be motions about any or all of the telescope axes (altitude, azimuth, and coudé azimuth); they
shall be either stepped or continuous motions, and shall be in any of the supported TCS
coordinate systems. The TCS shall support box, spiral, boustrophedon, and random scan
patterns. The TCS shall support optional attributes for step size, velocity, starting location,
number of steps and rows, and maximum range of travel.
The TCS shall support box scan patterns by moving continuously in a fixed rectangular pattern.
The input parameters are the heliocentric (x, y) coordinates of the center of the rectangle, the
lengths of the x direction (Solar EW) and y direction (Solar NS), and the speed in arc-seconds
per second. If the x and y lengths are equal then the pattern degenerates to a square.
The TCS shall support spiral scan patterns by moving continuously in a generalized
Archimedean spiral on the solar disk. As such the radius function "r(theta)" has the general form
r(theta) = a + b * theta ^(1/c), and the spiral has the form: (theta) = x0 + r(theta) * cos(theta);
y(theta) = y0 + r(theta) * sin(theta), where theta is an angle in [radians], a and b are real numbers
greater than or equal to 0 in [arcsec], c is an integer not equal to 0 (dimensionless), and x0 and y0
are real numbers in [arcsec]. If a > 0, b = 0 -- pattern degenerates into a circle. The input
Telescope Control System Specification
SPEC-0019, Revision F Page 14 of 32
parameters are the heliocentric (x, y) coordinates of the center of the spiral, parameters a, b, and
c in the spiral equation above, and the speed in arc-seconds.
The TCS shall support boustrophedon scan patterns by moving continuously back and forth in
rows on the solar disk. Input parameters are:
Control parameter 1: starting coordinates of the Boustrophedon "(x0,y0)" in [arcsec] from
sun center
Control parameter 2: positive/negative real number, solar EW/WE length "a" in [arcsec]
Control parameter 3: positive/negative real number, solar NS/SN length "b" in [arcsec]
Control parameter 4: positive/negative real number, total length in EW/WE direction L1
in [arcsec]; L1/a = N1 ; N1 positive integer greater than or equal to 1
Control parameter 5: positive/negative real number, total length in NS/SN direction L2 in
[arcsec]; L2/b = N2 ; N2 positive integer greater than or equal to 1
Control parameter 6: speed in [arcsec/s]
The "boustrophedon" has an alternating/reversing direction (sign change involved) and a
progressing/incrementing direction (increases monotonically in one direction along one of the
axis +/-x or +/-y). The reversing direction is determined by the axis that has a value of 1 after
rounding or taking the floor of L1/a and L2/b.
For the Boustrophedon the boxes are required to complete. This requires that the pattern always
starts and finishes with motion in the alternating/reversing direction.
Please note that the settings of L1 and L2 determine whether the pattern orientation is horizontal
(EW/WE) direction (L1 > a, L2 = b) or vertical (NS/SN) direction (L1 = a, L2 > b). Also note: a
and b can equal 0, but not at the same time: if a=0 and b=0 then an error message should occur.
If a = 0 or b = 0 ---> pattern degenerates into a linear back-and-forth pattern.
The TCS shall support random scan patterns by moving continuously and randomly within a
defined area on the solar disk. The random scan pattern shall blur the final image enough to
support the need for a flat field for the wavefront correction system. The random scan pattern
shall run at configurable rates up to 30 arc-seconds per second and at configurable areas up to
200 arc-seconds.
Verification: Design Review, Test
Source: Operations (SPEC-0036)
4.4-0150 Pointing Modes
The TCS shall control the telescope pointing through one of the following “modes”. The TCS
shall use these modes to control and coordinate the pointing loops in the TCS and the telescope
subsystems, sending the resulting position demands to the mount and enclosure control systems.
Telescope Control System Specification
SPEC-0019, Revision F Page 15 of 32
In open-loop mode, the TCS shall perform blind pointing and tracking for a demanded position
based solely upon the generated ephemeris and any known recurrent systematic errors (i.e.,
position offset in each axis, bearing runout, current temperature, etc.).
In closed-loop mode, the TCS shall receive pointing error (“guide”) information and use this
information, along with any known recurrent error, to generate pointing commands for the mount
and enclosure.
Guide information can be supplied from two sources: an external guider or the Wavefront
Correction Control System (WCCS). An external guider such as the Acquisition Control System
(ACS) indicates the discrepancy between the pointing map value and the actual value of the
position error. An object tracked by the ACS has an absolute position that is used as the
reference position for the telescope coordinate system. A pointing error indicates that the TCS
pointing map has a discrepancy between the calculated recurrent error and the actual observed
error. The offload of pointing error to the TCS is needed to meet the ACS input pointing error
frequency of up to 5 Hz.
Pointing errors from the ACS are sent to the TCS through an interface specified by the TCS-to-
ACS Interface Control Document (ICD-1.8/4.4). The TCS shall define this interface to meet
input pointing error frequency of up to 5 Hz.
Pointing errors from the WCCS indicate the amount of drift or bias the WCCS has accumulated
in correcting for image motion. An object tracked by the WCCS may not have a fixed position in
the telescope coordinate system. Consequently, a pointing error indicates that the TCS absolute
position may have drifted and should be updated. The offload of accumulated bias from the
WCCS to the TCS is needed to meet the WCCS input pointing error frequency of up to 0.05 Hz.
Pointing errors from the WCCS are sent to the TCS through an interface specified by the TCS-
to-WCCS Interface Control Document (ICD-2.3/4.4). The TCS shall define this interface to meet
input pointing error frequency of up to 0.05 Hz. Raw: Position is calculated using ephemeris
only. No pointing map is used.
Open-loop: Position is calculated using ephemeris and recurrent error information. No
guide signal is used.
o Offset: An offset can be applied to correct for systematic errors detected and
applied by an external system.
Closed-loop: Position is calculated using ephemeris, pointing map, recurrent error
information, and guide signal(s). The following guide sources may be used (in any
combination);
o External Guider (e.g. ACS): Guide signal comes from an external source that
generates errors based upon the absolute position of source defined target. The
format of the guide signal is defined by the interface between the TCS and the
Acquisition Control System.
o Adaptive Optics: Positional error signal comes from the WCCS. The format of the
signal is defined by the interface between the TCS and the Wavefront Correction
Control System.
Telescope Control System Specification
SPEC-0019, Revision F Page 16 of 32
Closed-loop guiding from the guider gives an absolute position reference signal in that the error
delivered to the TCS comes from a source with a known position in the sky (e.g., a star or the
limb of the sun). This source may originate from either the Acquisition Control System (i.e., a
solar limb finder algorithm) or from a stellar source detected by the context viewer. The TCS
shall use this type of guide signal to adjust the relative offset of the pointing model
These modes shall be selectable by the observer or operator.
Verification: Design Review, Test
Source: Operations (SPEC-0036)
4.4-0155 Sky Coverage
The TCS shall be able to point to all areas of the sky accessible by the Telescope Mount
Assembly, per SPEC-0011, Requirement 1.1-0140. The pointing accuracy shall be consistent
with the current operating mode in all areas except the zenith blind spot and the lower elevation
angles used only for maintenance.
Verification: Design Review, Test
Source: Operations (SPEC-0036)
4.4-0157 Forbidden zone when mirror cover and enclosure are open
Notwithstanding the requirements of 4.4-0155, the TCS shall not point the telescope and
enclosure within an area between 24 arcmins and 25 degrees from the sun center whilst the sun is
above the horizon and the enclosure and M1 cover are open. When the sun is below the horizon
or if either the enclosure or M1 mirror cover is closed the TCS shall be able to point the
telescope within this area. Commands issued to the TCS that would point the telescope within
this area, or that would cause the telescope to cross through this area, shall be rejected.
Trajectories that would cross this area shall be modified to not enter the area and the TCS shall
issue an alarm showing that the tracking performance is not valid. Commands to the TCS that
would open both the M12 mirror cover and the enclosure cover while the telescope is within this
area shall be rejected.
Verification: Test
Source: CR-0563
4.4-0160 Zenith Blind Spot
The zenith blind spot is defined as the area on the sky at zenith where the telescope mount
assembly cannot meet the velocity and acceleration performance specifications defined in
SPEC-0011, Requirements 1.1-0150 and 1.1-0160.
Telescope Control System Specification
SPEC-0019, Revision F Page 17 of 32
The TCS shall be able to track through the zenith blind spot. Some degradation of pointing
performance is allowed, but the performance shall be restored upon exiting the zenith blind spot.
The TCS shall report regularly the distance and time until the zenith blind spot is reached. The
TCS shall generate a CSF alarm while the telescope is in the zenith blind spot.
Verification: Design Review, Test
Source: Operations (SPEC-0036)
4.4-0165 Tracking
The TCS shall track a position in one of the following coordinate systems:
Topocentric: The TCS shall accept an altitude/azimuth target position and remain at that
position.
Sidereal: The TCS shall be capable of tracking a sidereal object (i.e., a star), given the
sidereal position and epoch.
Planetary: The TCS shall be capable of tracking a planetary object given the ecliptic
position or name of the major planetary body.
Orbital-elements: The TCS shall be capable of tracking an object given its orbital
elements.
Helioprojective: The TCS shall accept a helioprojective target position and remain at that
position relative to Sun center. Both helioprojective-cartesian and helioprojective-radial
shall be supported coordinate systems.
Heliographic: The TCS shall be capable of tracking at a heliographic rate. The
heliographic pointing accuracy shall be consistent with the solar rotation model.
All input positions shall be in the coordinate frame of the selected coordinate system. The
tracking system shall be user selectable. An option to disable tracking shall also be provided.
Helioprojective-cartesian coordinates are expressed as (θx, θy, d) as defined by Thompson with θx
and θy in arc-seconds and d expressed in solar radii. Helioprojective-radial are expressed as (ρ, ψ,
d) with ρ and d in solar radii and ψ in degrees. Heliographic coordinates are extended Carrington
(θ, φ, r) as defined by Thompson, with θ and φ in degrees and r in solar radii. (See Thompson,
W.T., "Coordinate systems for solar image data", A&A 449, 791-803 (2006).). In heliographic
tracking, both standard tracking and differential-rate tracking shall be supported.
The TCS shall provide simultaneous status information on the current telescope, enclosure, and
coudé rotator positions in the topocentric, sidereal, and currently selected coordinate systems.
Verification: Design Review, Test
Source: Science (SPEC-0001), Operations (SPEC-0036).
Telescope Control System Specification
SPEC-0019, Revision F Page 18 of 32
4.4-0170 Occulter
The TCS shall provide to the PA&C tracking information to be used to position occulters at the
Gregorian and prime foci. The tracking information shall be sufficient to allow the PA&C to
determine the position of occulters in translation and rotation in order to block the solar limb.
Verification: Design Review, Test
Source: Science (SPEC-0001), Operations (SPEC-0036).
4.4-0175 Drift
The TCS shall accept optional drift rates in the current coordinate system and apply those rates to
the current position of the telescope, enclosure, and coudé rotator. Drift rates shall not exceed the
maximum tracking velocity for any telescope axis.
Drift rates are defined as an added velocity in the tracking coordinate system that allows the
telescope to follow an object that is not stationary in the tracking coordinate system.
Verification: Design Review, Test
Source: Operations (SPEC-0036)
4.4-0180 Target
The TCS shall accept a target position in any of the tracking coordinate (requirement 4.4-0165
herein) systems. The TCS shall point the telescope to the target position and track it in the
requested coordinate system.
The TCS shall have defined fixed positions for various engineering positions, including the
parked position and the service positions of the telescope, as defined in the TCS to TMA
interface (ICD 1.1/4.4). These fixed positions shall be reconfigurable.
Verification: Design Review, Test
Source: Operations (SPEC-0036), Engineering (SPEC-0013)
4.4-0185 Offsets
The TCS shall accept and display offsets from a nominal input target position in any of the above
coordinate systems. The TCS shall provide offset capability for the TMA altitude, azimuth, and
coudé rotator.
The TCS shall not allow individual offset requests that exceed 1 degree.
Verification: Design Review, Test
Source: Operations (SPEC-0036)
Telescope Control System Specification
SPEC-0019, Revision F Page 19 of 32
4.4-0190 Rate Offsets
The TCS shall accept and display rate offsets from a nominal input target position in any of the
required tracking coordinate systems (see specification 4.4-0165). The TCS shall provide offset
capability for the TMA altitude, azimuth, and coudé rotator. When commanded through the TCS
interface, the TCS shall begin moving at a fixed rate in one axis of the requested coordinate
system. When commanded again, the TCS shall cease moving at the fixed rate in that axis. The
altitude, azimuth, and coudé rotator shall operate independently and simultaneously. Each axis of
the requested coordinate system shall operate independently and simultaneously.
The rate of motion shall be selectable through one of three fixed values. The fixed values shall be
parameters in the TCS parameter database. The rate of motion shall change when commanded
through the TCS interface, even during an ongoing rate offset.
Description: DKIST will operate the rate offsets through an operator hand paddle. This device
has six buttons for each direction on the three rotators and three buttons for the different fixed
rates. The coordinate system currently in use is automatically selected. When in use, the operator
will select the fixed rate by pressing the appropriate button, then press and hold a direction
button for an axis. While holding this button, the operator may also press a direction button for
another axis, causing this axis to also begin moving. Releasing the direction button shall cause
the motion to cease in that axis.
Verification: Design Review, Test
Source: Operations (SPEC-0036)
3.3 WAVEFRONT CORRECTION
This section defines the role of the TCS in wavefront correction of the telescope. The TCS
selects the wavefront correction strategy for each subsystem.
4.4-0200 Wavefront Correction
The TCS shall control the wavefront correction strategy for the telescope under direction from
the OCS and/or operator. The TCS shall respond to one of the three possible wavefront
correction modes by sending the appropriate commands to the telescope subsystems. It shall
monitor the behavior of the telescope subsystems to assure that the appropriate wavefront
correction mode is operational.
Wavefront information is sent from the WCCS to the pertinent telescope subsystems: the M1
Control System, M2 Control System, and Feed Optics Control System. Each of these recipient
subsystems can either use internal lookup tables to perform their corrections (open-loop
wavefront correction) or use the wavefront information sent by the WCCS (closed-loop
wavefront control). Additionally, the WCCS can determine either active or active-plus-adaptive
optics corrections. It is the responsibility of the operator or observer to select the appropriate
mode. It is the responsibility of the TCS to propagate the selected mode to the telescope
subsystems. It is the responsibility of the WCCS to generate the appropriate corrections based
upon the selected mode and send those corrections to the telescope subsystems.
Telescope Control System Specification
SPEC-0019, Revision F Page 20 of 32
A wavefront correction mode sent by the TCS shall be one of the following:
Open loop: The M1CS, M2CS, and FOCS will use their internal lookup tables to perform
the optical corrections. The WCCS does not transmit wavefront correction information to
these systems.
Closed loop active optics: The M1CS, M2CS, and FOCS will receive and use optics
corrections from the WCCS. The WCCS will perform only active optics and quasi-static
alignment corrections.
Closed loop adaptive optics: The M1CS, M2CS, and FOCS will receive and use optics
corrections from the WCCS. The WCCS will perform high order corrections through its
internal components (e.g., the deformable mirror and fast tip-tilt mirror(s)).
Verification: Design Review, Test
Source: Operations (SPEC-0036)
4.4-0210 WCCS Control of the Polarimetry Analysis and Calibration
The TCS shall provide the capability for the Wavefront Correction Control System to control
directly the actions of the Polarimetry Analysis and Calibration system. The TCS shall notify
both the WCCS and the PA&C when this capability is in effect and when normal control of both
systems has resumed.
To allow this activity, the TCS shall prevent further external actions from occurring on other
systems until either the Wavefront Correction Control System completes its actions on the
Polarimetry Analysis and Calibration system or the operator cancels the ongoing WCCS action.
Further external actions include commanded operations such as telescope offsets, scans, new
target position, new wavefront modes, etc. The TCS shall continue to track on the current
position during this period.
Verification: Design Review, Test
Source: Operations (SPEC-0036); Engineering (SPEC-0129)
4.4-0215 Wavefront Correction Offload
The TCS shall receive from the Wavefront Correction Control System an offload for the MCS of
any built-up tip-tilt bias in the WCCS. The TCS shall apply this offload as a positional error
coming from the AO, per the closed loop pointing requirements of Requirement 4.4-0150.
Offloads shall occur at rates of no more than 1 Hz.
Tip-tilt mirrors in the wavefront correction system may accumulate positional bias as they
perform their corrections. It is useful to offload this bias to the telescope pointing to recover
some of the dynamic range of the mirror. The TCS shall accept the WCCS offload and apply it to
the pointing correction for the Telescope Mount Assembly and MCS as described in Req.
4.4-0150. From the TCS point-of-view, this offload is indistinguishable from a guider correction
signal.
Telescope Control System Specification
SPEC-0019, Revision F Page 21 of 32
Verification: Design Review, Test
Source: Operations (SPEC-0036)
4.4-0220 Unlocking AO before motion
The TCS shall unlock the WCCS AO systems before the telescope moves to another target. The
TCS shall first issue an IDLE mode to the AO (assuming it is running) before (a) moving to a
new target position, (b) applying a target offset, (c) applying a pointing origin offset, or (d)
applying a guide handset correction.
The TCS is not responsible for relocking the AO system; this behavior must come from the OCS
scripts running the observation or from the operator when running in manual mode.
Verification: Design Review, Test
Source: Operations (SPEC-0036)
4.4-0225 Wavefront Correction Mode
The TCS shall accept a WCCS mode attribute and use the value of the attribute to set the
corresponding AO modes for the FOCS, TEOACS, and M1CS. For the WCCS mode value of
“off”, "idle", and “limb tracking” the FOCS, TEOACS, and M1CS AO modes shall be set to
"passive." For all other values of the WCCS mode, the FOCS, TEOACS, and M1CS AO mode
shall be set to "active." The TCS shall reject a command if the WCCS mode attribute is sent with
any FOCS, TEOACS, or M1CS AO mode attribute.
WFC mode AO modes M2 FTT mode / input source
off passive off / teoa
idle passive off / teoa
calibrate active on / wfc
diffraction limited active off / teoa
seeing limited on-disk active off / teoa
seeing limited coronal active off / teoa
limb tracking passive on / wfc
The TCS shall provide the current state of the WCCS mode attribute in its status event.
Verification: Design Review, Test
Source: Engineering (SPEC-0129)
3.4 SUBSYSTEMS
The TCS controls the state and operations of the telescope subsystems through the approved
interfaces.
Telescope Control System Specification
SPEC-0019, Revision F Page 22 of 32
4.4-0400 Sequencing Subsystems
The TCS shall control the sequencing of commands sent to the subsystems. All commands sent
to the TCS will contain no knowledge of the specific subsystem, its sequencing requirements, or
its current state.
The TCS shall monitor and maintain the software connection with the subsystems. The TCS
shall reconnect with subsystems if they are rebooted or otherwise lose their connection. The TCS
shall generate an alarm if it cannot connect to a subsystem and shall generate log messages on
any connection failure and reconnect.
Verification: Design Review, Test
Source: Engineering (SPEC-0013).
4.4-0405 Enclosure
The TCS shall control the Enclosure Control System as defined in the TCS-to-ECS Interface
Control Document. The TCS shall give the ECS a continuous stream of azimuth and altitude
data, corrected for dome center or opening alignment errors, sufficient to keep the dome position
always within tolerance. The TCS shall read all enclosure status information, including, but not
limited to, azimuth position and rate, shutter position and rate, cable or utility wraps, door and
equipment sensors. The TCS shall not control engineering equipment associated with the
enclosure such as cranes, doors, and lifts. The TCS shall not control the thermal systems of the
enclosure.
Verification: Design Review, Test
Source: Engineering (SPEC-0013).
4.4-0410 Mount
The TCS shall control the Mount Control System as defined in the TCS-to-TMA Interface
Control Document. The TCS shall provide the MCS a continuous stream of position and rate
data, including the azimuth and altitude axes of the mount assembly, and the coudé rotator. The
TCS shall set the position of the drive motors, brakes, and locking pins. The TCS shall read all
MCS status information, including, but not limited to, azimuth and altitude position and rate,
coudé rotator position and rate, cable wrap position, thermal control systems, drive status, and
limit switches.
Verification: Design Review, Test
Source: Engineering (SPEC-0013).
4.4-0412 Specific Coude Platform Rotation
For certain polarization calibration measurements it is required that the coude table position is
maintained at a fixed offset relative to the azimuth position.
Telescope Control System Specification
SPEC-0019, Revision F Page 23 of 32
In addition to the coude modes that maintain a fixed alignment relative to the sun and a fixed
alignment relative to the local horizon, the TCS shall implement a mode that mantains a fixed
relationship between the telescope azimuth and the coude table position.
Verification: Test
Source: Telescope Control Hand Paddle Specification (SPEC-0157).
4.4-0415 M1 Mirror
The TCS shall control the M1 Mirror Control System (M1CS) as defined in the TCS-to-M1
Assembly Interface Control Document.
The TCS shall perform the following operations on the M1CS:
Select the wavefront correction mode;
Monitor the status and health;
Send the current mount position, temperature, and other values needed for determining
the open-loop mirror figure error; and
Select the thermal cooling mode;
Verification: Design Review, Test
Source: Engineering (SPEC-0013).
4.4-0420 M2 Mirror and Top End Optical Assembly
The TCS shall control the Top End Optical Assembly Control System (TEOACS) as defined in
the TCS-to-TEAO Interface Control Document. The TEAOCS includes the M2 Mirror and the
Lyot stop.
The TCS shall perform the following operations on the TEOACS:
Select the wavefront correction mode for the M2 tip-tilt-focus;
Monitor the status and health;
Select the Lyot stop position;
Verification: Design Review, Test
Source: Engineering (SPEC-0013).
4.4-0425 Feed Optics
The TCS shall control the Feed Optics Control System (FOCS) as defined in the TCS-to-Feed
Optics Assemblies Interface Control Document.
The TCS shall perform the following operations on the FOCS:
Telescope Control System Specification
SPEC-0019, Revision F Page 24 of 32
Select the wavefront correction mode for M3 and M6; and
Monitor the status and health;
Verification: Design Review, Test
Source: Engineering (SPEC-0013).
4.4-0430 Wavefront
The TCS shall manage the Wavefront Correction Control System as defined in the TCS-to-
WCCS Interface Control Document.
The TCS shall perform the following operations on the WCCS:
Select the wavefront correction mode for the AO/aO systems;
Monitor the status and health;
Select the output storage type of the context viewer(s); and
Select the calibration mode for control of the PA&C;
Verification: Design Review, Test
Source: Engineering (SPEC-0013).
4.4-0435 Acquisition
The TCS shall control the Acquisition Control System as defined in the TCS-to-ACS Interface
Control Document.
The TCS shall perform the following operations on the WCCS:
Monitor the status and health;
Select the output storage type of the acquisition camera(s);
Set the filter; and
Set the region of interest;
Verification: Design Review, Test
Source: Operations (SPEC-0036), Engineering (SPEC-0013).
4.4-0440 Polarimetry Analysis and Calibration
The TCS shall control the Polarimetry Analysis and Calibration System (PA&C) as defined in
the TCS-to-PA&C Interface Control Document. The TCS shall control the position of the
various optical elements in the PA&C.
The TCS shall send through the interface the current rate and start time of the DKIST
synchronization system. These values are delivered to the TCS through the OCS-to-TCS
Telescope Control System Specification
SPEC-0019, Revision F Page 25 of 32
interface and are used to synchronize the PA&C spinning modulators with the cameras located in
the instrument systems.
The TCS shall send through the interface a trajectory stream defining the position of the
occulters located at the Gregorian and prime foci.
The TCS shall perform the following operations on the PA&C:
Monitor the status and health;
Select the calibration mode for control by the WCCS;
Select the observing or calibration configuration;
Set the polarizer rotation rate and zero point; and
Send a trajectory stream for the occulter(s);
Verification: Design Review, Test
Source: Science (SPEC-0001), Engineering (SPEC-0013).
3.5 PERFORMANCE REQUIREMENTS
4.4-0500 Accept or reject command in 0.1 sec
The TCS shall accept or reject a command given on its public interface within 0.1 seconds.
Verification: Design Review, Test
Source: Engineering (SPEC-0005)
4.4-0505 Boot within 5 minutes
The TCS shall be operational and ready to receive and act upon commands within 5 minutes of a
cold, power-off start of its hardware.
Verification: Design Review, Test
Source: Engineering (SPEC-0005)
4.4-0510 Apply offset information within 0.1 seconds
The TCS shall apply any external offsets or adjustments within 0.1 seconds. The offset
information may come from a hand paddle, guider, AO system, or instrument. The offset shall be
applied to the TCS pointing model.
Verification: Design Review, Test
Source: Engineering (SPEC-0005)
Telescope Control System Specification
SPEC-0019, Revision F Page 26 of 32
3.6 INTERFACE REQUIREMENTS
4.4-0600 Control LAN
The TCS shall use TCP/IP for all communications on the Control LAN. The TCS shall maintain
two separate TCP/IP connections for the communications between the TCS and OCS and TCS to
telescope subsystems, respectively. For performance reasons, if necessary, the TCS shall be able
to separate the Mount Control System network into its own TCP/IP connection.
Verification: Design Review, Inspection
Source: Engineering
4.4-0605 Common Services Framework
The TCS shall use the DKIST Common Services Framework for all communications on the
Control LAN.
Verification: Design Review
Source: Engineering (SPEC-0005).
4.4-0610 Containers and Components
The TCS shall use container and components as described by the Software Concepts Definition
(SPEC-0013) and defined in the CSF User’s Manual (SPEC-0022-1).
Verification: Design Review
Source: Engineering (SPEC-0013)
4.4-0615 Configuration Identifiers
The TCS shall use the proper configuration identifier in all communications. A configuration
identifier is supplied to the TCS for each and every configuration sent to it from the OCS. The
TCS shall use configuration identifiers to track actions throughout the TCS.
Verification: Design Review
Source: Engineering (SPEC-0013)
4.4-0620 Subsystem Commands
The TCS shall obey the DKIST Common Services Framework command interface when issuing
all commands to the TCS subsystems.
Verification: Design Review
Source: Engineering (SPEC-0013)
Telescope Control System Specification
SPEC-0019, Revision F Page 27 of 32
4.4-0625 Events
The TCS shall use the DKIST Common Services event interface to send and receive
asynchronous information between itself and the subsystems.
Verification: Design Review
Source: Engineering (SPEC-0013)
4.4-0630 Sequencing
The TCS shall be responsible for maintaining any sequence or order of command execution for
commands sent by the principal systems. Commands from the OCS shall be executed in the
order they are received or, if given with associated start times, in the order of the start times. All
valid commands shall be queued by the TCS for execution.
Verification: Design Review, Test
Source: Engineering (SPEC-0013)
4.4-0635 Health
The TCS shall check, update, and report its health on a regular basis. The TCS shall use the CSF
health mechanism defined in SPEC-0022-1.
Verification: Design Review, Test
Source: Engineering (SPEC-0013)
4.4-0640 Alarms
The TCS shall generate alarms for any errors or problems it detects that require operator
notification or intervention. Alarms shall be generated for loss of control or contact with its
subsystems, entry into the zenith blind spot or any mechanism end-of-travel.
Verification: Design Review, Test
Source: Engineering (SPEC-0013).
4.4-0645 Control of Telescope Motion
The TCS shall provide an interface to allow other principal systems to adjust the position of the
telescope. This adjustment may be in the form of an offset, track rate change, or predefined
motion pattern (scan, box, etc.).
Verification: Design Review, Test
Source: Operations (SPEC-0036), Engineering (SPEC-0013)
Telescope Control System Specification
SPEC-0019, Revision F Page 28 of 32
4.4-0650 Telescope Information
The TCS shall provide an interface to publish all appropriate telescope status information (i.e.,
position, rate, time, state, etc.). Appropriate information shall include all status, log, and alarm
events specified by all interface control documents to the TCS.
Verification: Design Review, Test
Source: Operations (SPEC-0036), Engineering (SPEC-0013)
4.4-0655 OCS Interface
The TCS shall obey the OCS-to-TCS interface defined by both principal systems. This interface
is to be written by AURA with input from the TCS contractor.
Verification: Design Review, Test
Source: Engineering (SPEC-0013)
4.4-0660 Engineering Display
The TCS shall supply an engineering display for the TCS operating software. The engineering
display shall exercise all the functionality of the TCS and shall be useful for actual TCS
operations of the DKIST. The engineering display shall use the principal systems interface to the
OCS.
Verification: Design Review, Inspection
Source: Engineering (SPEC-0013)
4.4-0665 Hand-box Interface
A DKIST hand-box is a portable, hand-held device for controlling engineering operations on a
system. It is not a part of the TCS contract. It is used generally by an operator or engineer to
perform set-up and calibration operations on telescopes and instruments. The envisaged hand-
box would interface with the DKIST control systems to perform activities such as: moving the
telescope around the solar disk, opening and closing the mirror and enclosure shutters, rotating
the coudé platform to a new position, and align feed optics mirror. Most activities that use the
hand-box are engineering ones in that they do not use predefined “modes” or automated
processes. Instead, they would drive a telescope axis or mirror tip-tilt motor while a hand-box
button is depressed.
The TCS shall provide an interface to support a stand-alone hand-box. The interface shall allow
direct control for the following activities:
Movement of each telescope and enclosure axis at slow and fast fixed rates;
Selection of coordinate system and tracking mode;
Movement of tip-tilt motion for M2 and Feed optics mirrors;
Telescope Control System Specification
SPEC-0019, Revision F Page 29 of 32
Open and close M1 mirror cover and enclosure cover;
Movement of each PA&C calibration optic; and
Enabling and disabling mechanisms;
The TCS design and implementation shall allow further activities to be added at a later date. The
TCS design shall describe how to add more activities to the hand-box interface.
Verification: Design Review, Inspection
Source: Engineering (SPEC-0013)
Telescope Control System Specification
SPEC-0019, Revision F Page 30 of 32
4. OTHER REQUIREMENTS
4.1 DOCUMENTATION REQUIREMENTS
4.4-1000 Final Design
The TCS shall provide a final design document. This document shall include all details necessary
to construct the TCS. During construction, this document shall be updated to show any design
modifications made during construction.
Verification: Design Review
Source: Engineering (SPEC-0013)
4.4-1005 Public Interfaces
The TCS shall document all public software interfaces. Public software interfaces are used by the
principal systems, communications system, and the TCS subsystems.
Verification: Design Review, Inspection
Source: Engineering (SPEC-0013)
4.4-1010 Operator’s Manual
The TCS shall provide an operator’s manual that describes the use of the TCS by a DKIST
operator. The manual shall describe operation during normal observations, setup,
troubleshooting, and engineering.
Verification: Design Review, Inspection
Source: Engineering (SPEC-0013)
4.2 SECURITY REQUIREMENTS
4.4-1100 Rely upon DKIST for secure communications
The TCS shall presume all communications to it are secure. No protection devices shall be
implemented by the TCS or the operating system under the TCS (e.g., encryption, firewall,
passwords). All security shall be provided by AURA.
Verification: Design Review, Inspection
Source: Operations (SPEC-0036)
Telescope Control System Specification
SPEC-0019, Revision F Page 31 of 32
4.3 MAINTAINABILITY REQUIREMENTS
4.4-1200 Source Code
The TCS shall provide all source code written for the TCS. Third party libraries or packages
selected and used by the TCS shall also be provided with source code. Exemptions for this
requirement shall be requested by the TCS Contractor to AURA before proprietary source code
is utilized by the TCS.
An exemption to this requirement shall be granted by AURA for the use of the TPOINT
proprietary software package in the TCS.
Verification: Design Review, Inspection
Source: Engineering (SPEC-0005)
4.4-1205 Source Documentation
The TCS shall document all source code in a manner consistent with good software practices.
Specifically:
A consistent syntactical style shall be used.
Source files shall have a header containing version number, revisions, author(s), and
functional description.
Source functions or methods shall have a description of the interface and operation of the
function.
Major algorithms or operational sections of code shall be clearly commented.
Verification: Design Review, Inspection
Source: Engineering (SPEC-0005)
4.4-1210 Revision Repository
The TCS shall use a revision repository (such as CVS) during construction. The repository shall
be accessible by the DKIST during construction.
Verification: Design Review, Inspection
Source: Engineering (SPEC-0005)
4.4 SAFETY REQUIREMENTS
4.4-1300 Respond to Global Interlock
The TCS shall respond to a global interlock signal by placing itself and its subsystems in a safe
state. The safe state shall prevent the TCS from moving any mechanisms or equipment while the
Telescope Control System Specification
SPEC-0019, Revision F Page 32 of 32
interlock condition exists. The TCS shall reject commands while the global interlock signal is
active.
The TCS shall respond to the release of a global interlock signal by accepting new commands.
The TCS shall not exit the safe state until commanded by the OCS or the engineering user
interface.
Verification: Design Review, Inspection
Source: Safety, Engineering (SPEC-0013)