atst telescope control system - dkist.nso.edu · telescope control system specification spec-0019,...

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


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


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.



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.



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.



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



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



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



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.



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.



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.



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.



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


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.


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


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



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.


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.



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.



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)



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.


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.



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.



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.





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.



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.


Source: Operations (SPEC-0036), Engineering (SPEC-0011)



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.



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.


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



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.



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.



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.



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.



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.



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.



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.



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.


Source: Science (SPEC-0001), Operations (SPEC-0036).



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.


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.



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.



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.





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.



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.



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)).



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.


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.





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.



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.



3.4 SUBSYSTEMS

The TCS controls the state and operations of the telescope subsystems through the approved

interfaces.



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.


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.



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.



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.



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;



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;


Select the Lyot stop position;



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:



Select the wavefront correction mode for M3 and M6; and




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;


Select the output storage type of the context viewer(s); and

Select the calibration mode for control of the PA&C;



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:


Select the output storage type of the acquisition camera(s);

Set the filter; and

Set the region of interest;


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



interface and are used to synchronize the PA&C spinning modulators with the cameras located in

the instrument systems.

The TCS shall send through the interface a trajectory stream defining the position of the

occulters located at the Gregorian and prime foci.

The TCS shall perform the following operations on the PA&C:


Select the calibration mode for control by the WCCS;

Select the observing or calibration configuration;

Set the polarizer rotation rate and zero point; and

Send a trajectory stream for the occulter(s);


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.



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.



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.





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.


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


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).



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.



4.4-0620 Subsystem Commands

The TCS shall obey the DKIST Common Services Framework command interface when issuing

all commands to the TCS subsystems.





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.



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.



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.



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.



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.).





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.



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.



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.



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;



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.





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.



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.



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.



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.





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.



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.



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.



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



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.


Source: Safety, Engineering (SPEC-0013)