TCS Software Design Description: Authors

Project Documentation
Document SPEC-0021
DRAFT - Revision C
TCS Software Design Description
Authors
Chris Mayer, David Terrett & Pat Wallace
Date
th
11 September 2006
Advanced Technology Solar Telescope 950 N. Cherry Avenue Tucson, AZ 85719

Phone 520-318-8102 atst@nso.edu http://atst.nso.edu Fax 520-318-8500
Revision Summary:
1. Date: 16th December 2004

Revision: A
Changes: Original version
2. Date: 9th May 2006

Revision: B
Changes: Updated to reflect Panguitch release
3. Date: 11th September 2006

Revision: Draft of Rev C
Changes: Updated for TCS CDR
SPEC-0021 Draft of Rev C Page i

Table Of Contents
1. Introduction ............................................................................................... 1
1.1 Purpose .............................................................................................................................. 1
1.2 Scope ................................................................................................................................. 1
1.3 Definitions, Acronyms and Abbreviations ........................................................................ 1
1.3.1 Definitions.................................................................................................................. 1
2. System Overview....................................................................................... 2
2.1 Introduction ....................................................................................................................... 2
2.2 Deployment Diagram ........................................................................................................ 4
2.3 Implementation Language ................................................................................................. 5
2.4 Source code ....................................................................................................................... 5
2.5 Use of ATST Common Services ....................................................................................... 6
3. System Context ......................................................................................... 6
3.1 Context diagram ................................................................................................................ 6
3.2 External Interfaces............................................................................................................. 7
3.3 Time System...................................................................................................................... 8
4. SYSTEM DESIGN ............................................................................................ 9
4.1 Configurations ................................................................................................................... 9
4.2 Events .............................................................................................................................. 11
4.3 The Device Model ........................................................................................................... 12
4.4 The Controller Model ...................................................................................................... 12
4.5 Controller Commands ..................................................................................................... 14
4.5.1 Load ......................................................................................................................... 14
4.5.2 Init ............................................................................................................................ 14
4.5.3 Startup ...................................................................................................................... 14
4.5.4 Shutdown.................................................................................................................. 14
4.5.5 Uninit ....................................................................................................................... 15
4.5.6 Submit ...................................................................................................................... 15
4.5.7 Pause ........................................................................................................................ 15
4.5.8 Resume..................................................................................................................... 16
4.5.9 Get ............................................................................................................................ 16
4.5.10 Set............................................................................................................................. 16
4.6 Engineering screens......................................................................................................... 16
4.7 TCS Components ............................................................................................................ 20
4.8 The “OSL” Controllers.................................................................................................... 22
4.8.1 OslController2.......................................................................................................... 23
4.8.2 HeadController......................................................................................................... 24
4.9 Logging ........................................................................................................................... 24
4.10 Pointing and Tracking.................................................................................................. 25
4.10.1 The Interface to the Telescope Control System ....................................................... 25
4.10.2 Supported Coordinate Systems ................................................................................ 34
4.10.3 Solar Ephemerides ................................................................................................... 36
4.11 The sollib library.......................................................................................................... 37
4.12 Scanning ...................................................................................................................... 38
4.12.1 Random .................................................................................................................... 38
4.12.2 Grid .......................................................................................................................... 39
4.12.3 Scan .......................................................................................................................... 40
4.13 Controlling Devices That Track................................................................................... 42
4.13.1 Change of mode to follow........................................................................................ 44
SPEC-0021 Draft of Rev C Page ii

4.13.2 Change of track identifier......................................................................................... 44

4.14 Position feedback......................................................................................................... 44
4.15 Telescope and Shutter Alignment................................................................................ 45
4.16 Handling The Zenith Blind Spot.................................................................................. 46
5. DETAILED DESIGN.................................................................................. 47
5.1 Loading and Initialization................................................................................................ 47
5.2 STARTUP ....................................................................................................................... 48
5.3 Operational startup .......................................................................................................... 48
5.3.1 Observing startup ..................................................................................................... 49
5.4 Configurations ................................................................................................................. 49
5.4.1 Sequencing ............................................................................................................... 52
5.4.2 Complex TCS attributes ........................................................................................... 52
5.5 Interlocks ......................................................................................................................... 54
5.6 Pointing Kernel................................................................................................................ 55
5.6.1 Sub-components....................................................................................................... 56
5.6.2 Operating Modes...................................................................................................... 58
5.7 Pointing Update Tool ...................................................................................................... 59
5.8 Environment .................................................................................................................... 60
5.9 Thermal Control Package ................................................................................................ 61
5.9.1 Consolidate thermal data.......................................................................................... 63
5.9.2 Seeing reduction....................................................................................................... 64
5.9.3 M1 Thermal Model .................................................................................................. 64
5.9.4 Thermal control........................................................................................................ 64
6. Compliance Matrix .................................................................................. 65
7. ACKNOWLEDGEMENTS ......................................................................... 68
8. REFERENCES.......................................................................................... 68
9. Appendices .............................................................................................. 70
9.1 Container Manager .......................................................................................................... 70
9.1.1 Overview .................................................................................................................. 70
9.1.2 Description ............................................................................................................... 70
9.1.3 ATST Application Control....................................................................................... 70
SPEC-0021 Draft of Rev C Page iii of 71

1. INTRODUCTION
1.1 PURPOSE
The intention of this document is to describe the structure of the software that constitutes the ATST
Telescope Control System, how it interfaces to the remainder of the ATST control system and how the
requirements expressed in [1] are met.
The intended audiences of this document are:

- The reviewers of the TCS Critical Design
- The developers of the TCS work package
- The developers of the TCS sub-system work packages
The layout of this document is as follows:
Section 2 provides a brief overview of the whole TCS system. It describes what the TCS is and how it is
structured and deployed. Section 3 sets the TCS within the context of the remainder of the ATST control
system and in particular specifies which other systems the TCS must interface with. The detail of what
passes over each of these interfaces is described in separate Interface Control Documents (ICDs). Section
4 is an introduction to the infrastructure that the TCS will be built with, known as the ATST Common
Services. Finally Section 5 moves on to the detailed design of the TCS. It describes the packages that
make up the TCS together with specifics of the TCS components and classes.
A compliance matrix can be found in Section 6 cross referencing how the design described in this
document meets the TCS design requirements [1].
Between the TCS PDR in March 2005 and the CDR in October 2006, there were major changes to the
ATST infrastructure software. In particular, the Controller class was introduced and the Device class was
dropped. The design presented here is based on the version of the ATST Common Services known as
“Panguitch_base” available from the ATST CVS repository. Note that Panguitch_base does not yet
include a C++ implementation of the common services. The consequences of this are discussed later.
1.2 SCOPE
The software described by this design is the ATST Telescope Control System. It is referred to throughout
this and other ATST documentation as the Telescope Control System or more usually by its acronym the
TCS.
The purpose of the TCS is to provide a high quality stable image of a specified point on the solar disk or
corona to instruments at the Gregorian, Nasmyth or Coudé focal planes. The TCS achieves this by
coordinating and controlling the activities of its subsystems under instruction from the Observatory
Control System (OCS).
Note that as defined here the ATST Telescope Control system does not include direct control of any
ATST hardware. That job is the responsibility of the TCS subsystems which are described in separate
design documents.
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

Specific definitions, acronyms and abbreviations used in this document are described below. For a more
general glossary and acronym list as used in ATST see [4].
1.3.1 Definitions
SPEC-0021 Draft of Rev C Page 1 of 71

Telescope subsystems – the subsystems of the TCS are the Mount Control System (MCS, also known as
the Telescope Mount Assembly TMA), the M1 Control System (M1CS), the M2 Control System (M2CS),
the Feed Optics Control System (FOCS), the Acquisition Control System (ACS), the Wavefront
Correction Control System (WCCS), the Heat Stop Assembly (HSA), the Enclosure Control System
(ECS) and the Polarization Analysis and Calibration System (PAC, also sometimes referred to as the
Gregorian Optical Station GOS)
Virtual telescope – the astrometric building block used to construct the pointing kernel. The virtual
telescope is an ideal telescope that responds instantaneously to new demands. The demands can be in the
form of a changed sky target or image position. The virtual telescope can also predict target or image
coordinates knowing the mount encoder readings.
Slew – a discontinuous change in position or velocity demand from the TCS.
2. SYSTEM OVERVIEW
2.1 INTRODUCTION
The ATST control system consists of four principal systems, the telescope control system (TCS), the
observatory control system (OCS), the data handling system (DHS) and the instrument control system
(ICS). The OCS is responsible for high level observatory operations like scheduling, allocating resources
and running “experiments”. Experiments consist of a series of observations with a particular
instrumentation setup. The data from these experiments is stored and displayed by the DHS.
The role of the TCS in this system is to

• point and track the telescope in a range of coordinate systems.
• monitor and control the thermal loads on the telescope
• perform scans and offsets coordinated with other observatory activities
• monitor and control the active and adaptive optics systems
• provide interactive control for the observatory operators
An overview of how these requirements are met by the TCS software is shown in the package diagram
below.
The util package at the top of the diagram contains the utilities used by the TCS to build the software
system. Although all the other packages shown are dependent on util, the dependences are not shown so
as not to clutter the diagram. Amongst other tools, the util package contains in particular the sub classes
of the Common Services Controller class that are will be used throughout the TCS software.
Below util in the diagram are the jes and cm packages. These contain respectively the Java Engineering
Screens (JES) and the TCS Container Manager (CM). The JES is an extension of the Component class
that can be used to graphically layout an engineering user interface using the Swing widget set. Once
designed, the screens can be activated such that they connect to other components as well as register for
events. This allows configurations to be issued as well as status to be displayed. Full details of the JES
and how it can be used can be found in [24].
The TCS Container Manager is used to load, initialize and startup the various components of the TCS.
Depending on how it is configured, this can be done automatically or step by step. The manager is
flexible enough that it can start up any container of the overall ATST control system and then load and
initialize any components into these containers. The selection of containers and components is done
graphically. A more detailed description of a current CM prototype can be found in the Appendix (see

section 9.1) Together, the JES and CM provide the interactive control of the TCS for the observatory
operators.
The remaining packages in the diagram constitute the TCS itself.
util
jes cm
thermal configs
environment tpk subsys
Figure 1 Top level TCS packages
At the heart of the TCS lies the pointing kernel package called tpk. This software system produces a
stream of demands to the tracking mechanisms of the ATST in order to accurately follow the current
science target and guide object. Its main role therefore is to meet the requirements of the first and third
bullet points above. The exact value of the demands produced will depend on how the TCS is configured.
The pointing kernel is a generic package that can be configured to control a range of different telescopes.
In order to keep telescope specific code out of the kernel a separate package called “subsys” is provided
to translate the outputs of the kernel into the signals and controls required by the ATST. Amongst other
roles the package will ensure the kernel data is in the correct format and units for the TCS subsystems,
clamp demands, track the current wrap states etc.
Configuration is handled by the Configs package. This package verifies and manipulates the
configurations received from the OCS and ICS. Configurations consist of a set of attribute value pairs that
the TCS will match by sending configurations to its subsystems and to its own internal components. A
configuration might consist of a heliocentric coordinate pair plus a required focal station for example. In
response to such a configuration the TCS would adjust its internal state such that suitable streams of
position demands were generated for the mount and focal station. The practical result of this would be

that the telescope would slew to the target such that it would appear stationary at the specified point of the
required focal station.
Due to the substantial heat loads on the enclosure and mirrors, an important task for the TCS is to manage
and monitor the thermal environment of the telescope. This task is performed by the thermal control
package. This thermal control package is dependent on the current configuration of the TCS which in turn
is under the control of the operator and/or the OCS.
Finally, the Environment package handles the reading and averaging of the environmental parameters
needed by the TCS such as temperature, humidity and pressure.
2.2 DEPLOYMENT DIAGRAM

Another view of the TCS can be found by looking at the TCS deployment diagram. This is shown in
Figure 2.
Engineers workstation
<< component >>

TCS GUI
Event & Command channel
TCS Controller Weather server
<< component >> << component >>

TCS Environment
Event channel
Figure 2 TCS Deployment Diagram
The deployment diagram shows where the main components of the TCS will run. As can be seen, the
deployment diagram is quite straightforward. The bulk of the TCS will run on a dedicated Linux
workstation and be written in a combination of Java and C++. The operating system used will be Red Hat
Enterprise Linux (the version is TBD) or the equivalent CentOS release. The standard hardware for
running ATST Linux applications has not yet been specified. The baseline machine we have assumed
here is the Advantech ACP-2000 with a PCA-6187 processor card which supports an up to 3.4GHz
Pentium 4 class processor. The machine will be configured with 512Mbyte memory and an 80 GB local
disk. The Advantech is a 2U industrial rack mounted PC with a least two space PCI slots for the GIS and
time bus interfaces. It has 300W dual redundant power supplies that are hot swappable.

The Environment package is shown as running on a separate machine. There are two reasons for this. The
first is that we want the environmental data collection to be interrupted as little as possible. In particular
we want to make it available even if the TCS is shut down. Secondly we do not yet know what hardware
will be needed to read the environmental data. It may be that a Linux workstation such as is used for the
TCS is not appropriate.
The TCS engineering interface will be written in Java and communicate with the TCS using the ATST
common services. It is shown running on a separate machine although this is not a requirement. It could
be run on any workstation supporting the Java and ATST common software environments. The current
expectation however is that the TCS GUI will execute on a separate workstation from the TCS itself to
avoid any potential problems with the graphical display starving the TCS of resources. For further details
refer to Section 4.6.
The TCS is expected to be robust and run continuously. It will only be shutdown for engineering purposes
and not for example at the beginning of each observing day. If the TCS is shut down it will return all
system resources to the operating system i.e. there will be no memory leaks, unreturned buffers etc.
The TCS will assume that all communications within this environment are secure i.e. it will not
implement any firewall, encryption or password access. All security considerations will be dealt with by
the ATST common services and the observatory wide computer systems.
2.3 IMPLEMENTATION LANGUAGE

Earlier versions of the TCS Design envisioned the TCS to be written completely in C++. The main
reasons for this were that the pointing kernel of the TCS although requiring modification for the ATST
was written as a combination of C/C++ and that the ATST Common Services supported C++ containers
and components.
To date only a Java implementation of the ATST Common services has been available and this has meant
all prototyping has had to be via Java components and containers. As a result of this prototyping it was
realized that there was no compelling reason to write the remainder of the TCS in C++ just because the
pointing kernel was in that language. Instead, the pointing kernel could be wrapped in Java.
There are two ways this wrapping can be achieved within the ATST Common Services. The first is write
a Java controller that then uses the Java Native Interface (JNI) to call the pointing kernel methods. The
second is to embed the pointing kernel into a C++ component and container and then implement a C++
controller that invokes the appropriate kernel calls in response to configurations received.
The design presented here assumes that the first method will be adopted. The reason for this is simply that
it is the only method currently available and it has been shown to work reliably in the prototypes
developed so far. However, given the period that is likely to elapse between now and the construction of
the TCS and the maturing of the common services over the same period, this design decision should be
reviewed before construction begins.
2.4 SOURCE CODE

The latest source code for the TCS can be found in the CVS repository on maunder.tuc.noao.edu. The file
RELEASE.NOTES in the top level directory provides a brief summary of the capabilities of each tagged
release.
The templates directory provides standard templates for files, include files and classes. The templates are
constructed so as to allow documentation production using doxygen or Javadoc.

In order that the TCS is not precluded from being ported to another operating system, all Linux operating
system calls will be wrapped in a TCS operating system independent library. All the wrappers will do is
simply call the Linux system call unconditionally. The purpose of this is to clearly identify where the
operating system specific calls are located not to provide an operating system independent application.
Similar wrappers will be provided for any CPU architecture specific features although it is not intended
that any such features should be used.
2.5 USE OF ATST COMMON SERVICES
The TCS is one of the major systems of the ATST. As such it must work seamlessly with the other
components that make up the overall ATST control system. In particular it must accept and act on
configurations sent by the OCS or ICS and in turn must send configurations to its subsystems. The TCS is
therefore built using the ATST Common Services which in turn constrains its design.
At the highest level the TCS will consist of two containers. One container will be used for the
environmental package and the other for the remainder of the TCS. The TCS container will then hold a
number of components. Each of these components will be initialized and then started by a container
manager via the init and startup methods of the top level TCS component. During this phase the TCS
components will attempt to make connections to the other ATST components with which they need to
communicate and will retrieve their initial state from the ATST run time database.
The starting assumption in the TCS design is therefore that the various pieces of the system will be
implemented as ATST components or subclasses of ATST components. Particular use will be made of the
controller class which is derived from component and adds the command/action/response behaviour
needed to handle configurations. Details of the controller model in general and the particular controllers
and components within the TCS can be found in [23] and Section 4.2 respectively.
3. SYSTEM CONTEXT
In order to see where the TCS sits in relationship to the remainder of the ATST control system the TCS
context diagram is shown below in Figure 3
3.1 Context diagram

DHS OCS ICS
Configurations Configurations TCS

TCS Status
Defaults TCS Status
Database Status GIS
Server
Interlocks
TCS
State TCS Configurations + TCS Status
ACS Status ECS
MCS
WCCS
PAC M1CS M2CS FOCS HSA
Figure 3 TCS Context diagram

The diagram shows the TCS with each of the systems with which it interacts. TCS subsystems are shown
in green. To avoid clutter, only a single double headed arrow is shown and only the ECS arrow is labeled.
For each subsystem interaction the TCS sends configurations to the subsystem and retrieves status from
it. The status is retrieved either by subscribing to an event channel or by using “get” methods on
component properties. In turn, subsystems will subscribe to event channels provided by the TCS. All
these interactions use the common services.
3.2 EXTERNAL INTERFACES
Each of the interactions of the TCS with its subsystems is governed by an ICD. The ICDs and their
document numbers are tabulated below
Subsystem ICD Reference

Mount 1.1/4.4 [9]
M1 1.2/4.4 [8], [16]
M2 1.4/4.4 [7]
Feed Optics 1.5/4.4 [11]
Wavefront 2.3/4.4 [10]
Acquisition 1.8/4.4 [12]
Enclosure 4.4/5.0 [5]
EMS 4.4/6.3.2
HSA 1.3/4.4 [6]
PAC 3.1.1/4.4 [13]
Table 1 TCS subsystem interface control documents
The Environmental Monitoring System is not shown as an external device in the context diagram as
certain aspects of it are part of the TCS.

The ICD for each subsystem lists the attributes that can be set as part of a configuration along with
subsidiary details like units and range. The first part of the ICD describes those attributes that are of most
interest to the TCS. These are sent to the top level component in the subsystem for distribution to
subsystems lower level components. The second part of the ICD describes those attributes that are
associated with subsystem sub-controllers. These will also be sent to the top level subsystem controller
but are likely then to be passed direct to the sub-controller. The final part of the ICD lists those events that
the subsystem will monitor. Most of these events will be generated by the TCS but some may be
generated by other subsystems.
The real time database server is used by all ATST systems as a persistent store to save state between
reboots. The TCS will access the server via the ATST Common Services to retrieve default parameters on
startup and save its state periodically.
The Global Interlock System (GIS) is the hardware safety system that protects the ATST and its personnel
from damage. In the presence of interlock signals from the GIS subsystems may be prevented from
coming on line for example or individual mechanisms will not be able to be moved. The interface to the
TCS is described in [14]. The hardware board used to interface to the GIS will be taken from the list of
supported ATST hardware. As a baseline, the 48 channel Adlink PCI-7348 has been adopted for the time
being.
The remaining interactions shown in the context diagram are between the TCS and its peer systems in the
ATST control hierarchy. Both the OCS and the ICS will send configurations to the TCS which it will
verify and then attempt to match by controlling its subsystems. The intention is that the TCS will operate
independently of the OCS and ICS and will not therefore subscribe to any event channels that those
systems may provide (this is TBC with regards to the ICS).
The final interaction is between the TCS and the Data Handling System. The DHS will not control the
TCS but may need to subscribe to data provided by it (this is TBC)
The interactions described above are covered by the following ICDs
System ICD Reference

Instrument 3.1.6/4.4
OCS 4.2/4.4 [15]
DHS 4.3/4.4
GIS ?? [14]
3.3 TIME SYSTEM

The TCS acts as the time master for the ATST. Ideally the time standard will be provided by a standalone
system to which the TCS and each subsystem can be directly connected. Failing this the TCS will be
provided with a bc637PCI card from Symmetricom that will allow direct connection to a GPS antenna to
lock the TCS to TAI. Time will then be distributed to the other systems via IRIG-B.
On startup of the TCS application, time will be read from the time card and used to set the system clock.
Periodically after this the time will be re-read and the system clock reset to the time standard. Within the
TCS pointing kernel all timestamps etc. will be read directly from the time standard but by ensuring the
system clock is also closely locked to this standard we will also synchronize less critical events. TAI will
be the timescale of choice for the TCS and all its subsystems.

4. SYSTEM DESIGN
This section describes the system design of the TCS and in particular its use of the ATST common
services. The TCS design is constrained by the need to interact seamlessly with the rest of the ATST
control system and to use the ATST Common Services in its operation [1]. The first part of this section
therefore recaps and summarizes the ATST Design with regard to the use of configurations and in
particular the controller model. Section 4.4 then describes the controller model as applied to the TCS.
4.1 CONFIGURATIONS
Configurations lie at the heart of the ATST Common Software. Configurations consist of a list of
attributes and values that the system to which the configuration has been sent must match. This matching
is handled by an ATST controller which is described later. A configuration can be set up by issuing a
series of set commands (Section 4.5.10) or more usually by sending a complete configuration with a
submit command (Section 4.5.6).
The class diagram for a configuration is shown below.
<< interface >> AttributeTable

IAttributeTable - table :Map << interface >>
(from atst.cs ::interfaces ) IAttribute
+ AttributeTable ():
(from atst.cs ::interfaces )
+ contains (aName :String ):boolean
+ insert (newAttribute :IAttribute ):void
+ remove (name :String ):void
+ get (name :String ):IAttribute
+ getNames ():String[]
+ extractOnPrefix (prefix :String ):IAttributeTable
+ extractOnSuffix (suffix :String ):IAttributeTable
+ merge (source :IAttributeTable ):void Attribute
+ toString ():String
+ size ():int - name :String
+ readData (in :BufferedReader ):IAttributeTable - value :String[]
+ readData (fName :String ): - definition :String
+ displayAttributes ():void * + Attribute (newName :String ):
+ show (s:String ):void + Attribute (newName :String ,bool :boolean ):
+ getMap (): + Attribute (name :String ,i:long ):
+ setMap (map :):void + Attribute (name :String ,d:double ):
+ Attribute (name :String ,f:float ):
+ Attribute (name :String ,s:String ):
+ Attribute (name :String ,sArray :String[] ):
+ setName (newName :String ):void
+ getName ():String
+ setValue (newValue :String[] ):void
+ getStringValue ():String
Configuration
+ getValue ():String[]
#id :String = null + setDefinition (entryName :String ):
#headertag :String = null
<< interface >>
+ Configuration (baseConfig :):
IConfiguration
+ Configuration (baseId :String ,headerTag :String ):
(from atst.cs ::interfaces ) << realize >>
+ Configuration (baseId :String ):
- Configuration ():
+ getId ():String
+ setId (newId :String ):void
+ getHeaderTag ():String
+ setHeaderTag (headerTag :String ):void
+ show (s:String ):void
+ merge (source :):void
+ toString ():String
+ clone ():Object
Figure 4 Class diagram for configurations
The diagram shows that a configuration is a specialized form of AttributeTable that contains a unique
configuration id and header tag. An AttributeTable consists of a collection of Attributes each of which has
a name and value.

Configurations go through a set of states as illustrated below on receipt of commands and events from the
underlying devices. The commands are submit, cancel, pause and resume. The events are Done or
Aborted
When a configuration is first created it enters the initialized state. It remains in this state while it is sent to
a controller with a submit command. On receipt of the configuration it will be immediately be checked for
validity. If the configuration is not accepted the controller will issue a rejection to the submitter and the
configuration will be discarded.
What happens next will depend on whether the configuration contains a “starttime” attribute. If starttime
is present and the time is not already expired, the configuration will be placed on a queue in time order. If
starttime is not present then the configuration will immediately be passed to an action thread for
execution. The configuration is then running. If the underlying devices can match the demand
configuration then it will eventually end and a successful done signal passed back to the submitter. If on
the other hand it can not be matched then an abort will be sent back. In either case the configuration is
then destroyed.
Configurations that are queued will be allocated an action thread when their starttime matches the current
time.
Unknown
Create
Initialized
Delayed
Queued
Submit
Ready
Running
Time expired
Matched
Failed
Aborted Done
Figure 5 Configuration states
Another way in which the configuration can end is via a cancel command. Earlier designs of the ATST
common services envisioned an attribute that would control how severe the cancel is. This is no longer
the case. The TCS will take the following actions on receipt of a cancel command
1. If the configuration is queued then it will be removed from the queue and an abort event sent for
it. This behaviour is provided by the common services

2. If the configuration is running then the action thread propagates the cancel command to all the
components involved in the configuration and then aborts and destroys the configuration. This
behaviour is also provided by the common services.
3. If the TCS is running a sequence then after executing the actions in 2 above then no further steps
in the sequence will be executed and the sequence will be destroyed.
The existence of queued configurations has some consequences for the TCS. In particular configurations
that are valid now may not be valid later or vice versa. The obvious configurations where this is a
problem are configurations that contain target parameters. The target (typically a point on the Sun) may
be below the horizon when the configuration is submitted or it may have set by the time the configuration
is de-queued. The TCS handles this by use of the starttime attribute and a TCS specific
“horizonchecking” attribute. When a configuration is received that contains target attributes then the TCS
will first look for the starttime attribute. If starttime is present then the TCS will use that time to validate
the configuration otherwise it will use the current time. If the result of this check is a demand elevation
that is below the horizon then whether the configuration is rejected or not will depend on whether
horizonchecking is on or off. With horizonchecking off, the configuration will be accepted but the
demands to the mount and enclosure shutters will be clamped at the lower elevation limit. The telescope
will thus track along the lower elevation limit until the target rises.
With regard to the starttime attribute, the TCS is not expecting to use this in any configurations that it
generates for its subsystems. The only controller that will make use of starttime will be the top level TCS
head controller if it receives a starttime from the OCS or ICS. If a queue-able configuration is received
then this will be sent for immediate execution by the subsystems once it is de-queued by the TCS.
Note that the above does not prevent the OCS or ICS from submitting queue-able configurations to TCS
subsystems provided they do not also include the atst.tcs.starttime attribute as well as the subsystem
specific starttime attribute in the same configuration.
4.2 EVENTS
As well as providing configurations that can be sent from one component or controller to another, the
ATST common services also provides events that can be used to signal changes of state or status.
Although both configurations and events can be used to pass data between components, they do so by
very different mechanisms.
Configurations require that there is a connection maintained between the two communicating
components. Events on the other hand use a “publish-subscribe” mechanism. The source of the data
publishes it and then any number of clients can subscribe. The publisher does not care how many or who
the subscribers are and there is no permanent connection between the two. If a publisher is not present
then a subscriber receives no events until the publisher is started.
In the ATST common services the data sent with events is encoded as an attribute table. Arbitrary
amounts of data can therefore be sent as an event, all a subscriber needs to know is the name of the event
so that it can register to receive it. Events are used internally by the common services to signal the
matching of configurations and will be used extensively by the TCS to report status and also to send
trajectory streams to its subsystems.
There is currently one issue with the event system that will affect the final design of the TCS and that is
the problem of what to do about non-periodic or low frequency events. Suppose for example the status of
the M1 mirror cover was signaled by an event each time it was opened or closed. Suppose also that after

it has been opened the TCS is shut down and then restarted. Currently in this situation, the TCS would not
discover the state of the M1 cover until it was closed again.
There are a number of ways to deal with this

• insist that all events are periodic at some “reasonable” rate e.g. 1 Hz
• modify the event system such that when a system subscribes for an event it is immediately sent
the last value published
• insist that every non-periodic event or periodic but low frequency event has a corresponding
attribute that can be accessed via a “get”
Each method has advantages and disadvantages. Currently it is being assumed that option 2 will be
implemented before construction starts but if not then option 3 will be used. This will have implications
for the implementation of each of the TCS subsystems.
4.3 THE DEVICE MODEL

The section on the TCS use of the device model that was present in earlier versions of this document has
been removed following the decision that a device class would not be implemented in the common
services. It is currently believed that the controller model (see below) provides all the facilities needed by
the TCS.
4.4 THE CONTROLLER MODEL

An ATST Controller implements what is called the command/action/response model. In this model
“commands” are separate from the “actions” that they trigger. In this way many commands may be sent to
a controller resulting in many simultaneous actions and in particular a controller is not blocked whilst
waiting for a previous command/action to complete. On receipt of a command, the controller will send an
immediate response to the sender saying whether the attributes sent with the command are acceptable or
not. It will then queue the command for either immediate or later action. Once queued, the controller is
ready to accept another command. The actions started by commands are handled by separate threads
under the control of an action manager. Actions can complete as either “done” or “aborted”. Normal
completion for an action would be “done” but if an error occurred then it would be “aborted”. This
response is advertised by an event called configstatus which senders can monitor for completion.
The class diagram of the ATST Controller is shown in the figure below

<< interface >>

IRemote
<< interface >> << interface >> << interface >>

IController IControllerLifeCycle IComponentAdmin
(from atst.cs ::interfaces ) (from atst.cs ::interfaces ) (from atst.cs ::interfaces )
<< interface >>

IActionCallback
+ done (config :IConfiguration ):void
<< interface >> + abort (config :IConfiguration ):void
IControllerAdmin + report (config :IConfiguration ):void
<< realize >>
<< realize >> ActionCallback

- component :IComponentAdmin = null
Controller
+ ActionCallback (ownerComponent :IComponentAdmin ):
+ UNKNOWN:String = "unknown" + doDone (config :IConfiguration ):void
+ OK:int = 0
- currentStatus :String = "LOADED"
- paramSet :Set= null
+ Controller ():
+ init (args :IAttributeTable ):void
+ startup (args :IAttributeTable ):void
+ shutdown ():void
+ uninit ():void
+ remove ():void
+ submit (config :IConfiguration ):int
+ submit (configuration :IConfiguration ,callback :IActionCallback ):int
+ submit (configuration :IConfiguration ,pause :long ):int
+ submit (configuration :IConfiguration ,pause :long ,callback :IActionCallback ):int
+ get (table :IAttributeTable ):IAttributeTable
+ set (table :IAttributeTable ):void
#doSubmit (configuration :IConfiguration ):void
+ cancel (configId :String ):void
Figure 6 Controller class diagram
Controllers accept configurations as the parameters of their commands. It is important for the TCS and its
subsystems to distinguish between the completion of an action and the state of an underlying piece of
hardware. An ATST configuration is in the running state until it is done or aborted. This may or may not
coincide with an underlying piece of hardware being physically stationary or not. For example if a filter
wheel is moved from one position to another then when the hardware reaches the new filter demand a
signal must be sent to the action thread to tell the configuration it is done. In this case the hardware device
stopping coincides with the configuration being done. In the case of slewing the mount to a new
astronomic target however the action is done when the mount, coude and enclosure first match the
position and velocity tolerances. The mechanisms will continue to track and it would be incorrect to
consider the configuration as still running because of this. Another way of looking at this is to consider
that the configuration is done when the mount is stationary in the frame in which the demand coordinates
are specified.
The life cycle of a controller is shown in Figure 7.
load init startup
Loaded Initialized Running
Unknown
remove uninit shutdown
Figure 7 Controller life cycle

The next section discusses the commands that trigger movements between these states

4.5 CONTROLLER COMMANDS
4.5.1 Load
This is not a command to the controller itself but the action of a container or container manager that loads
the controller itself from disk. A controller should do very little at load time and constructors should be
kept to an absolute minimum. Once loaded the controller will be connected to the ATST Common
Services and it will be able to perform low level functions through those services such as setting and
getting attribute information, logging, checking health and posting alarms. A controller should execute no
functional behaviour nor allocate any resources at this level. If it is in control of hardware it must
certainly not attempt to move it.
4.5.2 Init
Standard behaviour during the init phase will be to start any housekeeping services, allocate any resources
needed for later phases etc. This is the state that many subsystems will be brought to at night when they
are not being used operationally. It is essentially a standby mode where the system is activated but not
fully operational. For example the M1 control system’s thermal control would still be running but the
mirror itself wouldn’t be being actively or passively controlled.
A controller will always reach the initialized state as a result of an init command. This is guaranteed by
the common services. Should some error occur during the initialization actions the controller should set
its health to bad or ill and raise one or more alarms depending on the severity of the failure.
As can be seen from Figure 6, the init command can take an attribute table that can be used to control the
form that the initialization takes.
4.5.3 Startup
Following an init, the next stage will be to receive a startup. This command takes the controller into the
running state which is the state for operational use. Only in the running state is the controller able to act
upon and execute arbitrary configurations. Whether the controller actually acts on a submitted
configuration will depend on whether any errors were encountered on reaching the initialized and then
running state. It may be that due to problems some or all configurations will be rejected.
An example of what a mcs controller might do during the startup phase is to turn on the brakes and oil
pumps and enable the servos.
Controllers should avoid unexpected hardware movements during startup particularly those that might be
hazardous. For example it would certainly not be appropriate to automatically datum the mount as part of
the startup phase. Reaching the running state is a necessary condition for a controller to be operational but
for some controllers it may not be fully sufficient.
Again as with init the startup command can take a configuration as a parameter allowing the startup
process to be customized when needed.
4.5.4 Shutdown
Shutdown is essentially the reverse process of startup so any actions undertaken as part of the startup
process should be undone during the shutdown. The aim of the shutdown is however to get back to the
initialized state. Whilst in the running state the controller may have executed many configurations that
leave mechanisms active. These should be also be halted as part of the shutdown. For example if the
mount was tracking it should be stopped.

4.5.5 Uninit
This command is the reverse of init and should undo any actions that resulted from the init. As a result of
the uninit command the controller should be back in the same state as if it had just been loaded from disk.
4.5.6 Submit
Once a controller is in the running state then it is ready to act on any configurations sent to it.
Configurations are sent with the submit command. On receipt of a submit, the controller will verify that
the configuration is valid.
Within the TCS validation will consist of a number of stages
1. The name of the attribute (if it is for the TCS and not one of its subsystems) will be checked to
ensure it is known about. If any TCS attribute name is unknown then the configuration will be
rejected.
The alternative of simply ignoring unknown names could lead to a situation where a complex
configuration is submitted with one of the attribute names spelt incorrectly. The user might not
notice that the configuration had been accepted but that one attribute was actually discarded in the
process.
2. The value of the attribute will be range checked. Range checking is provided through the
common services and the property database. If the value is out of range then the whole
configuration will be rejected.
3. Conflict checking. This is check on the current configuration as sent to ensure there are no
conflicting demands. For example setting the telescope tracking mode to On but also setting the
mcsmountmode to move would be a conflict as the mount would simultaneously be asked to
move and follow.
4. A self consistency check. This is to validate whether the current configuration when applied to
the current state of the telescope will result in an overall configuration that is valid. The obvious
example here is where the telescope is tracking an RA and Dec. and the new configuration
consists simply of a new RA. The new RA may be perfectly valid and well formed but combined
with the current declination may result in an elevation demand below the horizon limit. Another
example would be where the enclosure shutter was open and the TCS was tracking the Sun and
an attempt was made to turn off the cooling loops.
If all these validation checks are passed then the configuration is handed to an action thread for
execution.
4.5.7 Pause
This command pauses the actions associated with an earlier submit. For components within the TCS this
command is not generally useful as the configuration state will only be running for a very short time
typically less than 0.05s This is because the components within the telescope like the virtual telescope are
ideal. Internal TCS components will therefore essentially always be “done” and the concept of pausing
and then resuming a component that responds on such a short timescale is not relevant.
The pause will be significant for TCS actions that involve a sequence of steps. For such sequences the
next step will not be taken until a resume is received (see below)

It will be necessary for the TCS to propagate the pause to any subsystems that are part of the current
configuration.
4.5.8 Resume
Resume restarts the actions that were previously paused. For internal TCS components this will generally
be irrelevant as their actions will already have completed by the time the pause is given. The TCS will
forward the resume to any components that are part of the specified configuration.
4.5.9 Get
This is a low level command provided to any sub-class of component. Get can be used to retrieve an
attribute from the current configuration. A Get without any attributes will return all the attributes in the
current configuration.
4.5.10 Set
Set will similarly specify attributes for the default configuration. These attributes may be over ridden by
an attribute provided with a subsequent preset. Since set only affects the default configuration and not the
current one it is not possible to affect a configuration that has been checked and transferred ready for a
start.
4.6 ENGINEERING SCREENS

It is a requirement [1] that the TCS provide an engineering display that is capable of exercising the full
functionality of the TCS although these screens need not necessarily use the principal systems interface
described in the TCS/OCS ICD [15]. For the design of the engineering screens presented here we have
adopted to use the principal systems interface as this will allow consistent testing of that interface prior to
the delivery of the other principal systems.
The design of the engineering interface component should meet the following requirements
1. Screens should be easy to construct and modify. Ideally the screens should be laid out graphically
and it should be possible to group and/or align widgets.
2. General widgets should be provided that can be configured to send arbitrary configurations to the
TCS
3. As well as general widgets, it should be possible to send fixed configurations where the user only
has to supply the attribute values without having to know the attribute names.
4. It should be possible to attach a widget to an arbitrary event and extract one or more values from
the attribute table associated with that event.
5. It should be possible to use color, both to enhance the appearance of the display as well as
providing color rules so that widgets can alter their appearance dependent on the values they are
displaying.
6. It should be possible to save screen layouts such that they can be recovered later.
A prototype engineering display has been written that demonstrates these features. The prototype is
known as the JES (Java Engineering Screen) and is described fully in [24]. The following paragraphs
provide an overview and some screen shots.
The JES is a graphical tool for laying out a graphical display. It has been written using Java Swing to
enable it to be as platform independent as possible. As long as Java is installed on your machine it should
be possible to use the JES. An earlier prototype of the JES used the SWT widget set but this requires the
appropriate shareable libraries for the platform being used to be installed. The JES tool is implemented as
an ATST Common Services component and so can make use of all the standard services provided and in

particular, the connection and event service. The tool operates in two modes, edit and execute. In edit
mode the mouse can be used to select and position a range of different widget types anywhere on the
screen display area as shown in Figure 8
Figure 8 JES screen in edit mode

The screen shows a new widget being added to the screen. The initial size of the widget is indicated by
the rectangle and the available widgets by the drop down menu. Once the widget is placed on the screen
then it can be further edited once selected to tune its size, color etc. The edit screen for the Static Text
widget is illustrated below

For all widgets you can set the x, y positions plus the height and width manually as shown here by the
text widget or by dragging the widget using the cursor. Each widget then has some widget specific
settings. For the text widget displayed here there is the text that is to be displayed, the font size, the
foreground color and the font style. The preferred setting if selected will set the size of the widget just
large enough to contain the text that is to be displayed.
Once a screen has been designed it can immediately be activated by placing it into execute mode. This
makes for a very quick design cycle. If the executing display isn’t quite what is wanted it can immediately
be switched back to edit mode, the changes made and then switched back to execute. It is not necessary to
save the screen and then launch another application to see the effect of the changes.
Once the design of the screen is satisfactory it can be saved. The saved layout is stored as XML so could
potentially be edited with a standard text editor before being reloaded. This might be useful if some global
change was required to all the widgets in a display.
A more complex example that was put together to control a prototype TCS demonstrator is shown in the
figures below. Figure 9 shows the engineering screen running in execute mode and Figure 10 shows the
same screen in edit mode. Some of the widgets visible in this screen apart from the static text are
• Configuration widget. This is the rectangle to the left of the screen under the text “TCS
Configuration”. It consists of a drop down list of available attributes plus a field in which the
attribute value can be entered. Clicking the add button will add it to the current configuration
which is then tabulated on the right hand side of the widget. Currently the atst.tcs.mode attribute
has been set to a value of “follow”. Additional attributes could be added and then the apply button
pressed to send the configuration to the TCS.
• Sub-screen buttons. Underneath the configuration widget are four buttons labeled “MCS
Control”, “ECS Control” etc. These buttons launch new screens which in this case provide direct
access to the MCS, ECS etc.
• Text update widgets. These widgets are recognized in the edit mode figure by the presence of text
starting $(top).tcs. These widgets are attached to events with the names displayed in the text.
Whenever the event is received the corresponding widget on the screen is updated. The $(top)

prefix is a macro which is specified when the JES application is started. The macro is substituted
on startup to create the full name of the event. Macros have been introduced to cope with the
development environment where multiple users may want to run copies of the TCS at the same
time. To avoid namespace clashes all names in the TCS can be altered by providing a new value
for the “top” macro. Engineering screens must then similarly be able to be switched to register to
receive the new names.
Figure 9 An example TCS Engineering Screen
Figure 10 The same screen in edit mode

Perhaps the most interesting widget on the prototype screens is that in the lower right hand corner. The
tabbed panel widget allows separate tabbed panes to be defined. Each of these tabbed panes can be treated
and edited like a separate screen and have other widgets added to it. The edit window for the tabbed panel
is show in Figure 11. It is slightly different from the main screen edit window but the controls work the
same . In particular, it is possible to copy and paste from the main screen to the tabbed panel.
Figure 11 Edit window for a tabbed panel

The advantage of the tabbed panel is that it allows a lot of detailed information to be added in a small
amount of screen space with easy selection of the details you are interested in. The tabs here provided
detailed views of the MCS and ECS but it is easy to switch to view the Feed Optics Controller or a graph
of the azimuth demand and achieved positions.
4.7 TCS COMPONENTS

In this section we use the term component to refer not only to the ATST component class but also to sub
classes of it. In fact most TCS components will be controllers or sub-classes of controllers. Using the
super class name however avoids constantly switching terminology.
The ATST component model imposes a strict hierarchy on the control flow through the ATST control
system. This means that any attribute destined for a sub-component must pass through a parent and so the
name of the attribute maps exactly on to the component hierarchy. For example if there is an attribute
atst.tcs.seq.mcs.mode then the OCS (which implements the top level atst component) will send this
attribute to the top level tcs component which in turn will send it to its seq component. The TCS will then
send the attribute to the mcs subsystem.
A component in the hierarchy may intercept an attribute and as a result generate its own configuration.
For example if the top level tcs component had an attribute atst.tcs.mode then it might on receiving this

value generate a configuration that contained atst.tcs.seq.mcs.mode. This attribute would then be sent to
the seq and mcs components just as in the previous example. The atst.tcs component could not send the
mode attribute direct to the mcs component and bypass the seq.
The TCS component hierarchy is shown below
tcs
thermal ems tpk seq
mcs m1cs ecs m2cs focs wccs hsa acs
Figure 12 TCS Component hierarchy

Those items in light blue are TCS components whereas those in green are the top level components of
each of the TCS subsystems. The roles of these components are as follows:
thermal – this device handles the thermal control aspects of the TCS. Apart from some configuration
parameters its main role will be to monitor the thermal state of the telescope and raise warnings etc. if
there are problems.
ems – this is the environmental monitoring system controller. Again it will play a mainly monitoring role
and provide suitably massaged data for the pointing kernel.
tpk – this is the TCS pointing kernel. This component will provide the trajectory event streams that will
be subscribed to by TCS subsystems to control the tracking devices e.g. the mount axes.
seq – this is the main sequencing device within the TCS. Its role is to do the straightforward sequencing
that is needed to bring the telescope into line with the current demand configuration. Under the sequence
component we currently have most of the TCS subsystems so that there is a place where such sequencing
can occur if it is needed. Currently the only component that does not need to be sequenced in some way is
the ACS but this may change if it re-acquires its guiding role as well as its acquisition role.
For more complex sequencing than can be handled at the component level and particularly for any
sequencing that involves operator intervention then we are looking to the OCS level to provide the
necessary facilities.

4.8 THE “OSL” CONTROLLERS

Give the hierarchy in the preceding section and the functionality provided by the standard ATST
controller it will be necessary to sub class it for use by the TCS. The two new features we need to
implement are;
1. The ability for a controller to pass configurations to sub controllers without returning a done
signal until all the child controllers are done
2. The ability for a controller to init, startup, shutdown etc. a range of other components
The first functionality is needed by any controller that passes configurations to a sub controller. If you
think of controllers forming a tree like structure then only the leaf nodes don’t require this ability. The
second ability is needed by the controller at the top of the tree. Without it the OCS would have to
initialize, startup, shutdown and uninit every component within the TCS. This in turn would need it to
know what components the TCS implemented and new components added to the TCS would require
modifications to the OCS.
The class diagram for the TCS controllers is shown below.
Controller
(from atst.cs ::controller )
ActionCallback
OslController2
(from atst.tcs ::util )
_ActionCallback
- _map :HashMap
(from atst.tcs ::util )
#_action (config :IConfiguration ):String - _owner :OslController2 = null
#issue (config :IConfiguration ,controller :String ,queue :IAttributeTable ):int - _queue :IAttributeTable = null
#__action (config :IConfiguration ):String
- addToQueue (id :String ,queue :IAttributeTable ):void + _ActionCallback (owner :IComponentAdmin ,queue :IAttributeTable ):
- signalDone (id :String ,queue :IAttributeTable ):void #doDone (config :IConfiguration ):void
- signalAbort (id :String ,reason :String ,queue :IAttributeTable ):void #doAbort (config :IConfiguration ,reason :String ):void
- checkAbort (queue :IAttributeTable ):String
- queueFinished (queue :IAttributeTable ):boolean
HeadController TimerTask
(from atst.tcs ::util ) (from java::util )
#_subcomponents :IAttributeTable = null
#doInit (att :IAttributeTable ):void

#doStartup (att :IAttributeTable ):void
#doShutdown ():void
#doUninit ():void
#__init (att :IAttributeTable ):void
#__startup (att :IConfiguration ):void
#__shutdown ():void
#__uninit ():void
InitTask UninitTask
(from atst.tcs ::util ::HeadController ) (from atst.tcs ::util ::HeadController )
- _name :String = null - _name :String = null
- _att :IAttributeTable = null - _timer :Timer = null
- _timer :Timer = null
+ UninitTask (name :String ,timer :Timer ):
+ run ():void + run ():void
+ InitTask (name :String ,att :IAttributeTable ,timer :Timer ):
StartupClass ShutdownTask
(from atst.tcs ::util ::HeadController ) (from atst.tcs ::util ::HeadController )
- _name :String = null - _name :String = null
- _att :IAttributeTable = null - _timer :String = null
- _timer :Timer = null
+ ShutdownTask (name :String ,timer :Timer ):
+ StartupTask (name :String ,att :IAttributeTable ,timer :Timer ): + run ():void
+ run ():void
Figure 13 TCS Controller classes

The ability to pass configurations to sub controllers and yet maintain a busy state is implemented within
OslController2. The ability for a controller to init, startup etc. a range of other controllers is implemented

in HeadController. A HeadController inherits from OslController2 as in general it will also need the
ability to pass configurations to its sub controllers. Note that the four classes that are derived from
TimerTask are all from atst.tcs.util.HeadController i.e. they are all internal private classes used only by
HeadController.
4.8.1 OslController2
The OslController2 class extends the functionality of the common services Controller class. Most
importantly it can be used to forward attribute tables to other controllers, and then hold itself in a busy
state until all of the other controllers have replied. It would then itself complete with a state equal to the
most severe returned from all of the other controllers.
A sequence diagram showing how controllers collaborate is shown below

OCS ConfigSender TCS configHandler :OslController2 Subsys configHandler :OslController2
SendConfig : status := submit (config )
Response : Controller.OK
doAction : new
queue :AttributeTable
doAction : status := __action (config )
doAction : x := issue (config ,controller ,queue )

issue : Controller.OK
Completion : Controller.DONE
Completion : done
ActionCompletion : Controller.DONE
Submit : destroy
Figure 14 Controller collaboration
In this diagram the OCS sends a configuration to the TCS and the TCS in turn sends a configuration to
one of its subsystems. In general there could be several layers of controllers in the TCS as well as in the
subsystems and the TCS might simultaneously be sending configurations to multiple subsystems.
Although this would complicate the situation, the essential principles are captured in this simpler
example. The main requirement is that the OCS sees only two signals returned. The first is an
acknowledgement from the receiver that it has received and accepted the configuration that was sent and
the second is a signal that the configuration has been acted on and is now matched. There are two
alternate scenarios not shown here. The first is that the configuration is rejected. In this case there will be
no further signals. The second is that the configuration was accepted but never matched due to some
error. In this case the second signal will be an error response rather than a done.
For the TCS to provide this behaviour to the OCS requires in turn that all controllers under it behave the
same way, hence the decision to extend the standard Controller class to encapsulate the required
behaviour. The way this must be done is for a parent controller to remain within its doAction method until
all its sub controllers have both acknowledged (or rejected) the configurations they were sent and
completed their actions.

The OslController2 class achieves this by extending the Controller class and overriding its doAction
method. When an action happens on this class it enters the doAction method and performs the following
operations.
1) A queue is created. This is in fact just an attribute table but will be used to store the status of all
Controllers that this controller has invoked actions on. From now on these will be known as sub-
controllers. Each attribute stored in the queue will be named according to the attribute table
passed to the sub-controllers, and the value it contains will be the current status of that action.
2) __action is now called and passed the configuration that this method was passed. __action is in
fact an empty method that is present to allow subclasses to alter the configuration before it is
considered for forwarding. Subclasses will override the __action method, add, remove or alter
attributes within the configuration and then return a status value. This status value is also
eventually added to the queue and combined with the others to form the overall status of this
action.
3) This class now has a configuration that may contain many attributes that are destined for many
different sub-controllers. This needs to be split into separate configurations, one for each sub-
controller that we have an attribute for. The attributes are looped over by name. The name
decides where the attribute will be going. A hash map of configurations is created and whenever
a new name is looped over a new configuration is added to this hash map. The attribute is placed
into the configuration. If a configuration, destined for a sub-controller we need already exists,
then the attribute is simply placed into that configuration.
4) All attributes have now been iterated over and placed in their correct configurations ready to be
submitted to the sub-controllers. The controller now loops through the hash map of
configurations, submitting each one and at the same time placing an entry for it on the queue.
5) After all configurations have been sent the controller updates its own entry on the queue to say
that it has finished. It then enters a loop that checks for all entries on the queue to finish. The
thread of execution will not pass this point until answers from all sub-controllers have arrived.
(A future version will allow cancellation here in case of error, so that the controller doesn’t get
stuck in a busy state).
6) Each time one of the sub-controllers has finished the action callback will get executed with the id
of the configuration passed to it. This id is used to notify the queue that the particular sub-
controller has completed its action. After all queue entries have been updated with done or abort
the controller will itself complete with the most severe status of all the entries in the queue.
4.8.2 HeadController
A HeadController extends OslController2 and adds the ability to initialize, startup, shutdown and un-
initialize any number of sub controllers. It is possible to wait (with a time out) for a sub controller to
complete its operation before issuing the operation to the next controller or the HeadController can simply
issue the operations in parallel.
This class works by extending the OslController2 class and overriding the doIinit, doStartup, doShutdown
and doUninit methods. As can be seen from the class diagram, it contains an attribute table called
_subcomponents that is used to store the names of all of the sub-components it controls. This table is
populated during the initialization of the controller; any attributes passed in that have the prefix
“subcomponent” are placed into this table. After that the sub-components table is used whenever one of
the four methods is invoked on this controller. Basically, it will connect to each of its sub-components
and invoke the same method.
4.9 LOGGING

The TCS will use the ATST Common Services Log Service [23] to log its system activity. In accordance
with the ATSTCS, the TCS will recognize messages of two types. Status messages are messages that will
always be logged whereas debug messages will only be logged during diagnostic checks. Both types of
messages will be stored in a relational database.
The ATST Log Service enumerates a number of different message categories. All TCS status messages
will be placed in the default category whereas debug messages will be placed into the most appropriate
category e.g. flow, init, timer etc. For a full list see [23].
It is expected that the ATST component model (and its sub class the controller model) will provide
logging of such things as state and configuration changes, commands and configurations etc. The TCS
will log all alarms errors and warnings.
The TCS will make use of the debug level within the ATST log service to log its debug messages in
various degrees of detail.
4.10 POINTING AND TRACKING
Note that most of the following sections have been extracted from versions of ATST Pointing and
Tracking [25]with minor formatting differences. For full details of the pointing and tracking strategy used
by the ATST TCS and in particular the details of how to use the library sollib, refer directly to that paper.
The pointing problem for ATST has two aspects:
1. Given the coordinates of a solar surface or coronal feature (the “target”) we want to control the
telescope mount and movable optics so that the image of the feature appears in the right place in
the focal plane.
2. Given the coordinates to which the mount and movable optics have been set, we want to know the
solar coordinates imaged at a given place in the focal plane.
These two are complementary, linked by the same transformation chain and differing only in the direction
in which the chain is traversed. The first aspect is about pointing and tracking, the second addresses
displayed coordinates and World Coordinate Systems. The extreme ends of the chain, so far as this
document is concerned, are (i) the heliographic longitude and latitude (Ψ, Φ) and (ii) the demanded
coordinates sent to the telescope control system (TCS). There are a number of intermediate coordinate
systems some of which have uses in their own right.
The following section deals first with the TCS pointing kernel, a relatively self-contained component
from whose internal complexities the solar observer can be insulated. The next reviews the choice of
supported coordinate systems, the dominating influence on the observer’s perception of the ATST
pointing controls. The final section discusses methods for generating the required solar ephemerides,
both orbital and physical.
4.10.1 The Interface to the Telescope Control System
Because of the need to calibrate the pointing of ATST using stars, and to reduce development costs, it is
proposed to use a proprietary telescope pointing kernel (TCSpk). This is principally intended to track
celestial targets, and so solar observing will be treated as an extension, a specific case of tracking any
solar-system target.

4.10.1.1 POINTING AT SOLAR TARGETS
The interface to the pointing kernel will be topocentric apparent place, continuously recalculated in order
to generate the requisite non-sidereal tracking rates. The starting point for this calculation will usually be
heliographic coordinates, but sometimes heliocentric coordinates. The pointing calculation will be quite
rigorous, taking properly into account planetary aberration (i.e. light time) and diurnal parallax. Light
deflection (i.e. the Sun’s gravitational lens effect) will probably be neglected, as for solar features it is
always below 4 mas, though it could be up to 1.75″ for a coronal feature distant from the Sun and seen
against the limb.1
Working in apparent (α, δ) has the disadvantage that the coordinates of the main object of interest, namely
the Sun, are continuously changing. The motion in latitude could be reduced were the kernel to support
ecliptic coordinates, and the longitude drift could be reduced by working in terms of the mean Sun.
However, they would never quite go away—diurnal, monthly, synodic and annual terms would always be
present—making such strategies less advantageous. Moreover, the rates in (α, δ) change so smoothly that
keeping the coordinates and their rates of change up-to-date to the required accuracy is straightforward.
4.10.1.2 TCSPK ARCHITECTURE
TCSpk is a suite of just over 50 ANSI C functions, around which a telescope control system can be
developed. It has been used on a number of projects including SOAR and LBT. The TCSpk functions
implement the astrometric pointing kernel part of a TCS in a rigorous, general and modular way,
insulating the TCS designer from many intricacies. The algorithms used by TCSpk are described in
Wallace (2002) [22].
Because TCSpk does a specialized job and is intended to be merely a part of a complete TCS, it is
designed to place as few constraints on the TCS developer as possible. There is no preferred operating
system or user-interface style for example, and even the real time requirements can be met in a variety of
ways. This flexibility will make TCSpk easy to integrate within an ATST control system design. For
example, TCSpk lends itself to use in a C++ design, providing the mathematical algorithms without
dictating the way they are grouped and interconnected. Experience with the SOAR and LBT control
systems has provided many insights into the best ways of dealing with the object-oriented design issues.
TCSpk uses the SLALIB/C library for all its positional-astronomy transformations and a subset of the
TPOINT pointing-analysis software (see below) for calculating pointing corrections. Both are de facto
standards, reducing maintenance concerns.
4.10.1.3 TPOINT
Pointing analysis will be via the proprietary TPOINT system. This is a straightforward command-driven
system that can be used interactively or run automatically using scripts. The rigorous TCSpk
transformations are built into TPOINT so that analysis and control are tautologically linked. TPOINT is
used by most large professional telescopes.
4.10.1.4 SLALIB/C
The proprietary SLALIB/C positional-astronomy library comprises 182 functions coded in about 23K
lines of ANSI C. Among other capabilities, the library can perform milliarcsecond predictions of line-of-
1
As with other ephemeris minutiae, consistency with other solar observers will be an important consideration.

sight to celestial targets. It is central to both TPOINT and TCSpk. The library is completely platform-
independent, and is compatible with applications written in either C or C++.
The current development version of SLALIB/C additionally includes support for the IAU 2000
precession-nutation and Earth rotation models, in both classical (equinox-based) and new (CIO-based)
forms. At present, the TCSpk software uses the more traditional equinox-based approach (and a different,
but almost as accurate, precession-nutation model) and a decision has yet to be made on whether to
introduce the new methods into TCSpk. The only practical difference this will make to ATST users is
whether apparent right ascensions are recorded using the new zero-point, or the equinox, or both.
4.10.1.5 POINTING-KERNEL FEATURES
It would of course be possible to write a simple ATST pointing kernel from scratch, using standard
positional-astronomy transformations to compute mount encoder demands that correspond to the solar
feature to be studied. However, starting with TCSpk should make this basic job much easier to do
properly (and get right first time), while offering important additional capabilities, such as the following.
• All telescope control systems provide as their basic function the ability to point and track
the mount in order to follow the sky coordinates of a specified target, in this case a solar
feature. The ATST design will go a step further by additionally allowing the image
position in the focal plane to be specified.
With this explicit control over image (x, y), the ATST control system will deliver, as a
matter of course, rapid transfer of images from acquisition device to instrument, fast
dithering, precise blind positioning on slits and fibers and so on. In non-TCSpk systems,
the way this is traditionally done is to make ad hoc changes to the pointing, either by
perturbing the target (α, δ) or (Ψ, Φ) coordinates or by introducing spurious pointing-
model offsets. A cascade of further ad hoc adjustments is then required, for example to
correct the behavior of an autoguider. In contrast, the proposed ATST system has all
these capabilities simply as part of the way the system works.
• The target image remains centered on an off-axis instrument “hot-spot” even when the
rotator (which in the case of ATST includes the coudé floor) is turned.
• ATST’s various moving optical elements will be treated not as free-standing devices but
as components of an integrated pointing system. Limb-guiding while roaming or
scanning will happen naturally, and, should it be required, bandwidth splitting between
the slow mount and a tip/tilt mirror would be easy to implement.
• The ATST pointing kernel will have inbuilt handling of field orientation at Nasmyth and
coudé foci. The fact that a given experiment is being done at, say, coudé will not,
beyond cable wrap issues, be something the observer needs to be particularly aware of.
• For limb guiding, the pointing kernel will automatically take care of differential
refraction and atmospheric dispersion.
• The kernel will provide for the accurate logging of target positions, and there will be
support for World Coordinate System mapping.

• Control of instrument rotator angle will be handled rigorously, ensuring accurate results
even near the zenith. The kernel reckons field orientation at the “pointing origin”
(which is in general not at the rotator axis) enabling precise alignment between solar and
instrument coordinates.
• The basic pointing transformations that the kernel uses are rigorous and glitch-free even
near the zenith (and even for large mechanical misalignments, not that this will be a
concern for ATST).
• High computational efficiency is built into the design of the kernel. On a typical PC,
hundreds or even thousands of highly accurate astrometric transformations per second
are possible, should the ATST control system design require it.
• After commissioning, the design of the kernel is such that the pointing model can be
upgraded without writing new code. Moreover, because the calibration and operational
implementations of the pointing model use identical code, there are no hidden sign errors
or subtle distortions.
• The ATST control system can use as many simultaneous pointing models as necessary.
This technique could support multiple foci, via switching or dichroics, and allow for
geometrical misalignments and flexures peculiar to one part of the telescope—a limb
guider, the occulter and so on.
4.10.1.6 ARCHITECTURAL CONSIDERATIONS
Designing a TCSpk-based ATST pointing control system is mainly a matter of managing a data context
and reacting to events by introducing appropriate changes to it. The kernel design is essentially modeless,
producing different effects as a consequence of the passing of time and the changing data context, not
because set-piece maneuvers are carried out. The TCS designer has to address the following:
• Access to TAI date and time has to be provided. The GPS offset, and UTC leap
seconds, are handled outside the kernel.
• Starting the system begins by setting up a data context containing the items needed to
drive the kernel. This contains fixed site-specific information and locations for all the
changing parameters.
• Among many other tasks, the user interface must provide ways for the operator to
change the kernel’s context, in particular by announcing a new target.
• The ATST system must schedule a call to the kernel’s “slow update” function once
every minute and a call to the “medium update” function once every 5s or so, to refresh
different parts of the context. The timing of these events is not critical, and the update
frequencies are merely suggestions.
• The system must also call a “fast update” routine at, say, 20 Hz, to generate the tracking
demands. Even this is not especially time-critical, because of the kernel’s use of
timestamps. However, a fixed and reliable update rate will make for easier fault
diagnosis and generally smoother results.

• In addition to satisfying the TCSpk housekeeping needs, the ATST’s slow, medium and
fast updates will perform the solar coordinate transformations necessary to supply the
updated topocentric apparent places and differential rates that drive the kernel proper. A
cascaded series of ephemeris calculations (for example the heliocentric Earth position
and velocity might be refreshed once a minute, the solar rotation perhaps every five
seconds) will ensure that CPU load remains small.
Once running, the kernel will generate a stream of time-stamped (az, el, θ) encoder demands for tracking
the specified target, taking into account both the complex and changing astrometric transformations and
the telescope pointing model. The precise interface to the mount control system (MCS) will dictate how
this information will be used. Ideally the MCS will accept the time-stamped positions without restriction
and even during the abrupt change of demand when a slew begins will automatically apply the required
signal shaping to catch up smoothly. More usually the mount designer expects velocities as well as
positions and is intolerant of glitches; this can be accommodated by using the kernel to make multiple
predictions and taking differences.
4.10.1.7 DIFFERENTIAL ROTATION
Solar targets in general will have intrinsic motions, and surface features will share in the latitude-
dependent differential rotation. It is proposed to handle both of these effects by permitting solar targets,
in whatever coordinate system, to have optional timestamps and differential rates.
Thus the user interface could supply a target in heliographic coordinates ( Ψ0, Φ0) with a timestamp t0 and
differential rates (∂Ψ/∂t, ∂Φ/∂t ). The rates could come from a standard model, in which case ∂Φ/∂t
would be zero, or obtained numerically by differencing positions recorded some time apart. A day or two
later, at time t, the same target could be recalled, and the pointing kernel would as a matter of course set
the telescope to the coordinates ( Ψ0+∆t×∂Ψ/∂t, Φ0+∆t×∂Φ/∂t), where ∆t = t − t0. The telescope would
then point to the target, with its differential motion allowed for.
4.10.1.8 ZENITH BLIND SPOT
All altazimuth telescopes are limited in their ability to observe the zenith region. On a night-time
telescope, this is usually not an operational problem, because as one science target goes through the
“blind spot”, another can be observed. However, ATST has only one science target, the Sun, and at the
Haleakala site there will be days during the northern summer when the Sun cannot be observed for a few
minutes as it passes through the blind spot. It is thus essential to understand what causes the blind spot
and to deal with it efficiently.
There are four natural limits to tracking in the zenith region:
• Azimuth tracking speed. The inaccessible region lies inside a figure-of-eight—see

Figure 15. The “waist” corresponds to the case of tracking exactly through the zenith,
where it is possible to track up to or away from the zenith, but there is a sudden 180°
azimuth change between the two.
• Azimuth slew speed. In the case where the track does not go exactly through the zenith,
a point is reached where, although neither the velocity nor the acceleration has reached
the maximum allowed, unless a slew is begun immediately the target cannot be picked
up again until after it has passed the point of symmetry on the other side of the meridian.
This region is lenticular in shape, because it is the overlap of two regions, north and
south of the zenith.

• Azimuth acceleration. The inaccessible region in this case is a four-lobed shape. As a

rule, the available velocity and acceleration performance means that the four-lobed
shape lies almost entirely inside the figure-of-eight set by the maximum tracking speed.
In other words, the available acceleration is usually not the limiting factor.
• Geometrical inaccessibility. Mechanical non-perpendicularity between either (i) the

azimuth and elevation axes of the mount or (ii) the telescope and the elevation axis will
lead to a circular hole in the sky coverage around the zenith: no combination of azimuth
and elevation encoder readings will point the telescope within this region. For ATST
this impossible area is unlikely to be more than a few arcseconds in radius and will
hence lie entirely within the other blind spots.
The blind spots for ATST, sited at Haleakala, are shown in Figure 15. For illustrative purposes it has
been assumed that the full azimuth slew speed of 3°/s is available for the required 180° change, whilst for
the maximum rate at which accurate tracking is available a lower figure of 0.75°/s has been used. The
maximum azimuth acceleration available during tracking has been assumed to be 0.1°/s/s. The large
circle is the nominal 0.5° blind spot.

Figure 15 Zenith blind spot. The figure-of-eight region is set by the maximum available tracking speed. The four-
lobed region is set by the acceleration limit. The lenticular region indicates where slewing would begin and end for
a blind spot symmetrically disposed about the meridian. The outer circle is for the nominal r=0.5°.
In practice, it is not possible to give a hard-and-fast rule that dictates the optimum way to pass through the
region. The symmetry of the lenticular-shaped slew-limited region proves that it must be the “minimum
lost time” blind spot. However, one way or another the telescope and enclosure have to complete a 180°
azimuth change, and this alone will dominate how much observing time will be lost. Moreover, any
seconds shaved off the lost time by abandoning tracking the moment the lenticular region is reached may
well be at the cost of prematurely terminating an integration time. The proposed policy for ATST is for
the TCS to warn when the speed limit will be reached and to leave it up to the user (or the automated
observing sequence) to elect when to break off and get the 180° slew over with.
The TCSpk pointing kernel’s default zenith avoidance maneuver is to execute a circle track around the
zenith at a nominated distance. For ATST something a little more elaborate will be needed. This can
either be implemented in the kernel itself or, probably easier, in the sequencer that is running the
observations. Once the final pre-transit observation has completed, overriding the demanded (α, δ) with
one on the edge of the blind spot would be one method.

However, there are potential difficulties that extend well outside the area of the blind spot itself. As the
zenith is approached, the pointing corrections that are being applied in order to track the source will call
for large azimuth adjustments that will cause complementary field-rotation effects. This in itself is not a
problem, because the TCSpk pointing kernel uses rigorous techniques both to track in (az, el) and to
control the rotator. But to accomplish this without continuous guiding requires very precise knowledge of
the pointing coefficients and, moreover, the correct allocation of the total pointing corrections into the
various geometrical contributions: zero points, non-perpendicularities and azimuth-axis tilts. Figure 16
demonstrates the effect. The test circumstances are as follows:
• The site is Haleakala.
• We are about to make a 1-minute track touching the southern edge of the 0.5° diameter
zenith blind spot at its mid-point.
• The operational pointing model includes a value for the northwards tilt of the azimuth
axis that differs by 5" from the (unknown) true value. On the meridian, the mid-point of
our simulated track, there is consequently a pointing error of 5".
• We correct the mid-exposure pointing by introducing an ad hoc 5" adjustment to the

elevation encoder zero-point.
• The simulation records the changing positions of eight points equally spaced around a 5′
field of view during the 60-second exposure.
The resulting trails are over 2" long. Although 5" uncertainties in individual pointing coefficients, as used
in the simulation, are rather larger than would be expected for a modern large telescope like ATST, such
errors are by no means unknown. There are two conclusions to be drawn:
4. Despite ATST being a “one-target telescope”, thorough and frequent all-sky night-time pointing
analyses will nonetheless be needed in order to characterize the sources of error.
5. For fields near the zenith (even several degrees away in fact), the adaptive optics system and/or
limb guider will play an important role in maintaining accurate tracking.

Figure 16: Tracking errors in 1 minute for a field on the southern edge of the nominal r=0.5° zenith blind
spot, in the case where the pointing effect of a 5″ northwards tilt of the azimuth axis has been compensated by
an ad hoc 5″ adjustment to the elevation zero-point.
Errors in the telescope/elevation and elevation/azimuth non-perpendicularities produce trails of similar

size but at right-angles to those in Figure 16. Fortunately, the two types of non-perpendicularity cause
similar effects near the zenith, where they have the largest effects on tracking; hence it is not necessary to
determine the proportions of the two types of non-perpendicularity, as long as the total amount is
accurately known.

4.10.2 Supported Coordinate Systems
Solar coordinate systems are discussed from a space physics point of view by Hapgood (1992) [18] and
by Fränz & Harper (2002) [17]. Thompson (2002) [21] adresses the solar image aspects. There are also
many Web pages concerning sunspot observing and solar space observatories that contain useful material.
In these references, there is a limited amount of sharing of identifiers (HEEQ, HCI etc.), but on the whole
the nomenclature is somewhat inconsistent and precise definitions are elusive. There is of course a
danger that these ATST proposals could add to this unsatisfactory state of affairs. To guard against this,
the following approach has been taken:
• The total number of supported coordinate systems for ATST has been kept to a bare
minimum. Only four systems are proposed, compared with several times that number in
the cited references.
• Duplication is avoided by not separately naming the Cartesian and polar representations
of each system.
• Similarly, units are not stipulated, and applications are free to choose (for example) solar
radii or meters. The natural home for much of this flexibility is the user interface rather
than the TCS itself.
• Where standard transformations exist, in common with other branches of astronomy,

these are taken for granted and not provided in special solar forms.
These measures mean that the supported list of coordinate systems does not include most of those
discussed in the references. Apart from the desire for economy, there are two reasons for this. The first is
that the overlap between the needs of (i) solar and solar-terrestrial space observatories and (ii) ground-
based solar observatories is limited, so that an exhaustive list might confuse ATST users without adding
useful capabilities. The second is that many of the omitted coordinate systems are based on the ecliptic.
Use of the ecliptic is problematical in modern high-accuracy work. Not only does the ecliptic slowly
rotate relative to the stars, but at a sub-arcsecond level the concept has no rigorous basis. At least two
distinct types of ecliptic are in use (inertial and geometric). The latest IAU resolutions on reference
frames (IAU 2000, B1.1-9) in effect bypassed the ecliptic and equinox, and from now on the trend will be
towards use of the International Celestial Reference System alone.
If, despite this, there does prove to be an ATST demand for ecliptic coordinates, appropriate ones (such as
Hapgood's HAE, HEE and HEEQ) can readily be added to the design.
The five adopted ATST coordinate systems are described in the following sections. Each system has a 2-
character identifier.
4.10.2.1 HELIOGRAPHIC (HG)
Heliographic coordinates (Ψ, Φ) are based on the solar equator, with a prime meridian that rotates relative
to the Earth and stars. In a solid body this meridian would be defined by surface features, but in the case
of the Sun it is provided by a conventional ephemeris. The heliographic longitude and latitude of a
sunspot is approximately constant, though its position on the Sun’s disk changes from day to day.

HG coordinates will be the primary method for specifying the solar surface feature that is to be observed.
Conversely, when the position of an object is to be recorded, HG coordinates will be the usual choice. If
the radial distance r is specified, the default unit is the photospheric solar radius. Outside the TCS, the
user interface may support other options, for example height above the photosphere, or wavelength.
4.10.2.2 STONYHURST
Stonyhurst coordinates differ from heliographic coordinates in that longitudes are reckoned from the
center of the Sun’s disk. A given solar feature thus has a Stonyhurst longitude that changes at about 13°
per day, corresponding to the synodic period of 27.2753 days.
HS coordinates would not, as a rule, be used to specify a target. They are included mainly as a
convenient link in the chain of transformations.
4.10.2.3 HELIOPROJECTIVE (HP)
Helioprojective coordinates specify the position of a feature seen in a solar image that has been projected
onto a plane. Only one projection will be supported, namely gnomonic (i.e. tangent-plane), with the
origin at the center of the Sun’s disk. The default units will be the projected radius of the solar disk.
Helioprojective coordinates can be used when displaying or storing solar image data.
4.10.2.4 HELIOCENTRIC (HC)
Heliocentric coordinates are Sun-centered but are tied neither to the Sun’s equator nor to the solar
rotation. They could be used when specifying a target in the corona. A good choice of units would be
meters, though for some applications AU might be more convenient.
The only directly supported orientation is that of the International Celestial Reference System. For ATST
purposes this is the same as the J2000 mean equator and equinox (within 25 mas) and FK5 (with 0.1″).
Other orientations, such as the true equator and equinox of date, and various ecliptic coordinates, are
available through calls to functions in the SLALIB library.
4.10.2.5 AG: GEOCENTRIC APPARENT PLACE
Geocentric apparent right ascension and declination (α, δ) will be available to assist in recording
observations but will not in fact be the interface to the telescope control system. The pole is the
precessing-nutating celestial intermediate pole (CIP); the zero point of right ascension will be the true
equinox of date and/or the celestial intermediate origin (CIO).
Notes:
• This is not a spatial coordinate system, but one specifically used to describe a pointing
direction; hence there is no radial coordinate.
• Geocentric apparent place differs from topocentric apparent place by being free from
diurnal parallax and diurnal planetary aberration. Thus it is a convenient starting point
from which another solar observatory could begin the pointing calculation.

4.10.2.6 TOPOCENTRIC APPARENT PLACE (AP)
Topocentric apparent right ascension and declination (α, δ) will be the interface to the telescope control
system. The pole is the precessing-nutating celestial intermediate pole (CIP); the zero point of right
ascension will be the true equinox of date and/or the celestial intermediate origin (CIO).
Notes:
• This is not a spatial coordinate system, but one specifically used to describe a pointing
direction; hence there is no radial coordinate.
• Topocentric apparent place differs from geocentric apparent place by including the
effects of diurnal parallax and diurnal planetary aberration. It is thus not suitable for
record-keeping, as it is peculiar to the ATST observing site.
• Refraction is not included - the direction corresponds to the case where the telescope is
in vacuo.
4.10.3 Solar Ephemerides
There are two ephemeris aspects to consider: the heliocentric Earth ephemeris, which provides the
geometrical direction to the Sun and hence the ATST pointing target, and the solar physical ephemeris,
which allows points on the solar disk to be assigned heliographic coordinates.
4.10.3.1 HELIOCENTRIC EARTH EPHEMERIS
The ATST pointing predictions begin with the heliocentric (x, y, z) coordinates of the Earth. There are
two ways these can be obtained:
• By interrogating a JPL numerical ephemeris such as DE405.

• By using a mathematical model.
The first method has the advantage that the utmost accuracy can be achieved, moreover without a heavy
computing load. On the other hand using the interpolation software that comes with DE405 is itself
complex and introduces support risks, and the (binary) ephemeris file must be present and in the correct
version.
For these reasons, the proposal for ATST is to use the mathematical model approach, in the form of a
simplified version of the VSOP2000 series (Moisson & Bretagnon 2002 [19]), as implemented as
function slaEpv in the SLALIB/C library. This 2500-line C program delivers pointing predictions that
agree with JPL DE405 to within 15 mas throughout the 21st century. On a 2 GHz Pentium processor
each prediction consumes a non-trivial 4 ms of CPU time. However, the Earth position and velocity will
be among the information recomputed at a low rate and then interpolated: the deterioration in pointing
accuracy even for hourly updates is well under 1 mas.
4.10.3.2 SOLAR PHYSICAL EPHEMERIS
For ATST we propose to adopt the model used by the Astronomical Almanac (see Seidelmann 1992
[20]):

• The solar north pole is fixed at α2000 = 286.1300°, δ2000 = +63.8700°.
• The rotation angle W = 84.10° + 14.1844000°× (days since J2000 TDB).
• The radius of the photosphere is 696 000 000 meters.
Note that:
1. The original Carrington expressions do not describe a pole that is fixed in space and moreover are
consistent with neither a fixed nor a moving ecliptic. Carrington wrote:
I = 7°15′
Ω = 73°40′ + 50″.25 t
but should in fact have written:
I = 7°15′ + 0″.08 t
Ω = 73°40′ + 46″.60 t
to take account of planetary precession and thereby fix his solar rotation axis with respect to the
stars.
2. Various subtly different interpretations are in use, the 1992 Explanatory Supplement formulation
proposed for ATST use being just one of them.
3. The 1992 ES rotation period (360/14.1844 days) and Carrington's value (25.38 days) differ by
about 0.4 seconds, causing a heliographic longitude drift of 0.1° per century.
4. The precise Carrington epoch with respect to modern time scales is not available, a further
obstacle to truly canonical use.
5. B0, L0 and P (the latitude and longitude of the center of the disk and the position angle of the
north pole) will, if needed, not be calculated directly from the usual formulas but will instead be
obtained by passing the relevant points through the usual transformation procedures.
6. Carrington rotation number will be a user interface issue and not provided by the TCS.
7. The distinction between TDB and TT will be neglected
4.11 THE SOLLIB LIBRARY

The coordinate systems and ephemerides described in the preceding section have been encapsulated in the
sollib library. This is described fully in [25]. The functions within sollib will be called as follows in order
to track the solar disk
• Call solSolpeq at the TCS slow rate (probably once a minute) to refresh the heliocentric Earth
ephemeris and precession-nutation matrix components of the solar ephemeris parameter set.
(Even every hour would be ample, but the savings would be negligible.)

• Call solSolpt at the TCS medium rate (say every 5s), followed by a call to solSoleph.
This will produce a topocentric apparent α, δ for the centre of the Sun and − by using the value
from last time − differential track rates dα/dt, dδ/dt.
• At the TCS fast rate, perhaps 20Hz, call the appropriate transformation functions, to get α,δ for
the solar target (heliographic for photospheric features, heliocentric for coronal features,
helioprojective for points on the solar disk). Such an α, δ is for the time of the medium update.
By retaining the differential rates (and their corresponding reference times), the target will be
correctly tracked.
With this approach, the only significant compromise that is being made is that the solar rotation since
the last medium update time is being ignored. Because it takes about two weeks for a solar feature to
rotate from one limb of the Sun to the other, the maximum error in 5s is about 0.02 arcsec.
Comparisons of the output of sollib with data from the Astronomical Almanac gave excellent
agreement except for an offset of about 0.06° in the computed value of L0. Comparison of sollib
with output from the JPL Horizons system did not show this difference. The discrepancy turns out to
be the neglect of the light travel time in Carrington’s equations making the Sun a special case
compared to other solar system bodies. Technically at present the computed value of L0 is therefore
wrong both in sollib and in the JPL Horizons computations. The issue has been raised at the recent
IAU General Assembly. If the current special status of the solar rotation equations is maintained it
will be a simple matter to modify sollib to allow for this.
4.12 SCANNING
Requirement 4.4-0011 is that the TCS can perform scanning motions autonomously or in coordination
with the ICS. At this stage three scanning modes have been identified. These are random, grid or scan.
The grid scan is perhaps the easiest to handle as it consists of a set of discrete positions. Indeed this type
of scan could easily be handled by a script at the OCS level. It is however expected to be a fairly common
observing mode and so will be handled within the TCS by a sequence component (add reference here)
Scan and random scans on the other hand involve continuous motion and these require coordination with
the pointing kernel.
The fast loop and medium loops within the pointing kernel operate on an object of class Target. Each time
the fast loop runs (every 50ms) it calls the position method on the current Target. Each time the medium
loop runs it calls the update method on class Target. The position method returns the coordinates of the
target in the current tracking frame at the specified time and the update method is an opportunity to adjust
the parameters that generate the coordinates. Typically any time consuming calculations should be done
in the update method so that the position method does not hold up the remainder of the fast loop.
For both random and scan type scans, the Target class will be sub-classed to give a RandomTarget and a
ScanTarget. These Targets will then be fed parameters via configurations that will allow them to generate
the appropriate coordinates at any specified time. The details of the algorithms used the generate the
coordinates can be found in the following sections.
4.12.1 Random
Random scanning is used so that a detector will see a uniform illumination for calibration purposes. It
may be that different types of random pattern are eventually required but the TCS has assumed that the
primary requirement is to spend approximately equal integration times at each point traversed. This in

turn means the telescope needs to move at approximately constant speed during the scan or else the
telescope will dwell longer at points where the axes reverse direction at the same time.
The other constraint is that the scans should be confined to a box of size typically 5 by 5 arcmin. This
limits the maximum speed at which the telescope can scan. There is a limit on the maximum speed which
each axis can obtain from a standing start if it is to stay in the box given the acceleration and deceleration
limits.
The algorithm used to compute the scan will proceed as follows

• a random point will be generated within the scan area
• the direction of this new random point from the preceding point will be computed. If the direction
lies within a cone +/- 135° of the previous direction then discard it and generate another point.
This check eliminates paths where the telescope goes back on it itself towards the direction it has
just come from. In such a case both axes would need to slow to a stop and reverse at the same
time which is incompatible with a constant speed.
• A time to reach the new point is computed on the assumption the axes move at the specified scan
speed
• Once a long enough run of random points is generated a cubic spline fit is made which can be
used to generate the path at each instant of time. The cubic spline ensures there are no jerks at the
randomly generated positions and that the velocities match there.
The diagrams below show a typical path generated by such an algorithm for a scan confined to a box 5
arcmin by 5 arcmin with a target speed of 150 arcsec/s. The second plot shows the actual achieved speed.
The average speed is about 10% higher than the target speed as the initial times to reach the points were
computed ignoring acceleration and deceleration. This can be corrected by computing the times assuming
a mean speed of 0.9 times the target speed.
4.12.2 Grid
A grid scan is a discrete scan where the telescope stops for a specified time at a number of points on a
rectilinear grid. The user will be able to specify the frame in which the grid is to be performed, the
orientation of the grid relative to that frame and the number of points in x and y plus the separations and
the dwell time at each grid point. This type of scan is ideal for the sequencer. Each point of the grid will
correspond to a new phase of the sequence. The telescope will slew to the grid position and track there.

As soon as that phase is done, the next phase will start which will be to stay tracking the position for
“dwell time” seconds by starting a timer. When that phase is done and the timer expires, the slew to the
next grid point will begin. This will continue until all the grid is complete.
4.12.3 Scan
In this mode the telescope will move continuously in one direction and then jump to an offset position
perpendicular to that scan to start another continuous movement. The user can specify the length and
duration of the scan plus the offset between rows. At the end of each row the user can choose whether to
scan the next row in the opposite or same direction as the previous one. Scanning in the opposite direction
should give some efficiency gains.
The problem with such a scan is controlling the time sequence such that we know when the telescope is at
the start of the scan and moving with the correct velocity. The basic design strategy of the pointing kernel
is to work with a virtual telescope. This is an ideal telescope that is instantaneously in position. The
pointing kernel generates the demand and then expects the mount servos to match those demands and
signal when it has done so. The problem with this model and a scan is that when one scan line is
completed the kernel will immediately ask the telescope to move to the next scan line. It will be some
time however before the real telescope matches this demand and by this time the start of the scan will be
missed. This is illustrated in the diagram below
Figure 17 Scan and telescope path

The solid lines show the desired scan pattern and the dashed line shows the track of the actual telescope.
It is clear that the start of the second scan line is missed as the real telescope reverses direction and then
settles on the new direction. The same will happen at the end of every scan line.
There are a number of possible solutions to this problem. One simple way for example would be to
artificially extend the scan lines and then discard the data at the start of each line. The approach adopted
for the ATST will be to control the path taken by the telescope as it moves from scan line to scan line so
that we can ensure that it reaches the start point with the correct velocity.
Controlling the path can be done in a number of ways. One simple approach would be to fit a cubic to the
path in each axis using the current position and velocity and the desired position and velocity at the start
of the scan line as constraints. This solution gives the 4 polynomial coefficients in terms of the slew time
and the start and end positions and velocities. The maximum and minimum accelerations and velocities
can then be used to solve for the slew time.

Although the above provides a smooth path from the position and velocity now to the position and
velocity at the start of the scan it is inefficient in that the acceleration is a linear function of time. The
slew time is therefore artificially long. If we want to minimize the time it takes to get from the current
position to the final position then we must use the maximum accelerations and decelerations available and
not worry about the jerk. The TCS will therefore compute the path using either two or three phases
depending on the distance to travel. The phases will be an acceleration , a coast (if needed) and a
deceleration. The acceleration and deceleration will be at the maximum rates available.
The basic equations governing the path are
Δx = x start − x now
where xstart and xnow are the scan start position and position now respectively.
Δx = v now t1 + 0.5a1t12 + v 2 t 2 + v 2 t 3 + 0.5a3 t 32

v 2 = a1t1 + v now
t1, t2 and t3 are the times in the separate phases, a1 and a3 are the accelerations which will be equal but
opposite in sign and equal to the maximum possible.
The final constraint is the scan start velocity which is given by

v start = v 2 + a3t 3
The algorithm used by the ScanTarget class will proceed as follows:
1. Save the current target and use this as the central position of the scan
2. Fetch the current position and velocity xnow and vnow
3. Compute the current position of the start of the scan in azimuth and elevation.
4. Compute the demand position 1 second later and so derive xstart and vstart for each axis.
5. Compute the path in accordance with the equations above and form the total time T to complete
the slew.
6. Repeat steps 2,3 and 4 above for the current time plus T
This will provide an initial estimate of the path from the current time t0 to t0+T. Each time the position
method is called on the ScanTarget with a time between these limits then the following will be executed
1. Fetch the current position and velocity xnow and vnow

2. Use the results of step 5 for xstart and vstart for time T to recompute the path and hence derive a
new estimate of T
3. Repeat step 5 above for the current time plus the new estimate of T
4. Convert to the tracking frame
The above iterative approach is necessary because we are assuming that the path calculated is the same as
the actual path each axis will follow. In practice this will not be the case. If we simply used a one-off
approach to computing the path then any discrepancies between the actual path and the computed path
will show up as errors in the start of the scan. Note that the path computations need to be done in az/el
coordinates but need to be presented to the pointing kernel in whatever the current tracking frame is.

Given that we have specified the duration of each scan line then for times later than T but less than T +
tscan then we can compute the demand position in a straightforward way. Suppose we have asked for a
helio-projective scan rotated by θ with a scan duration tscan and a scan length lscan . The algorithm would
be
1. Compute the distance traveled along this scan line for this time using the scan speed lscan/tscan
2. Rotate by angle θ and offset to get the demand helio-projective position at this time
3. Convert to the tracking frame
Once the current scan line is complete and provided all the scan lines haven’t been completed then the
ScanTarget class will revert to its path computation mode using the position and velocity at the end of the
current scan line for the start of the path and the start of the next scan line as the end of the path.
The above sequence of path computation and scanning will continue until the whole scan is complete. At
this point it will restore the original saved target and exit. At the end of the scan the telescope will
therefore revert to tracking the previous target.
4.13 CONTROLLING DEVICES THAT TRACK
Many ATST mechanisms have to track a continuously changing demand position being generated by the
TCS pointing kernel; these are:
1) the mount axes

2) coudé room rotation,
3) enclosure azimuth and shutter position
4) prime focus occulter
5) AO and correlation tracker sensors or pickoff mirrors
6) Nasmyth instrument rotators
Such mechanisms can be operating in any one of the following states:
• Following – tracking the demand from the TCS

• Moving – slewing to a new fixed position at which point they will stop
• Stopped – stationary at some position (either specified in a configuration or whatever results
from exiting from the following state).
• Parked – at the mechanism’s park or stop position (not all mechanisms may implement this state)
Note that the stopped state is not meant to imply that the mechanism necessarily has its brakes applied
and servos powered off; it could be implemented by simply feeding a fixed position and zero velocity to
the servos.
The complication with these mechanisms is the following state and how this maps on to the ATST
configuration states. Although the mechanism will be continuously changing its position the associated
configuration is not necessarily “running”. Indeed, it is more likely to be done. The reasons for this
initially perhaps confusing terminology and why it is essential to the operation of the ATST control
system is explained below.
The mechanism subsystem that is following will receive a new position demand from the TCS
approximately every 50ms consisting of:

• A timestamp (as a modified Julian date on the TAI timescale)

• The desired position at that time
• The desired velocity at that time
• A unique track identifier
The units of position and velocity will be chosen to allow easy linterpretation of the event stream – e.g.
for the mount, degrees rather than radians – and the velocities will be per second.
The timestamp will typically be between zero and 50ms ahead of the current time but this is not
guaranteed. Arrival of demand events outside this interval (while in the “following” state) indicates a fault
and should be logged. Arrival of events more than one second early or late, or the absence of any new
events for more than one second, indicates a serious fault which should cause the subsystem to enter a
fault state.
The velocity component of the demand enables the subsystem to extrapolate the position to both earlier
and later times. In the absence of any change to the positions of the targets (other than a constant
differential tracking rate) that the TCS is tracking or changes to the telescope pointing model, successive
demands will describe a smooth track where extrapolating forward from one point or backwards from the
next give much the same position. However, if there is a change in a target position or an adjustment to
the pointing model there will be a discontinuity in the tracks described by the two demands as illustrated
in Figure 18. These discontinuities in the track can be any size from close to zero to the full range of
movement of the mechanism. The TCS will signal such a discontinuity by changing the track identifier.
Any signal shaping required to stay within the performance limits of the mechanism’s servos is the
responsibility of the subsystem control system.
Position
Time
Figure 18
Some mechanisms track only very slowly (for example, because of changes in differential refraction or
atmospheric dispersion as the telescope altitude changes) in which case the velocity component of the
demand may not be computed by the TCS and will always be set to zero.

We will consider two scenarios to illustrate how such a tracking mechanism should behave under the
control of the TCS
4.13.1 Change of mode to follow

Assume that the mechanism receives a configuration that puts its mode into follow. The action initiated
by this configuration is probably simply the setting of a flag that tells the device to start acting on an event
channel. As such the action is extremely rapid. However, before the controller state is returned to done the
device must check its current position against the time stamped TCS demand. If the difference is greater
than a specified tolerance then the action must remain busy until the tolerance criterion is met. This
criterion must include not only position tolerance but also velocity tolerance. It is not sufficient to set the
configuration state to done simply because the positions are close if it is known that the mechanism can
overshoot and oscillate before it settles. Velocity criteria can be met in a number of ways. If it is possible
to accurately measure the device’s velocity then a straightforward check can be applied. Alternatively if
the time to settle is known it may be that a simple delay can be inserted.
The reason for only reporting done when the mechanism is truly settled is that the TCS and higher level
systems will be watching to see when every device in the configuration returns to done. This will be the
signal that the next step its observing sequence can be started. Typically this might be the opening of a
shutter to start an integration. If some mechanisms have reported that they are done too early then the
integration may be degraded.
The above is also the reason that a mechanism once it is within tolerance must not leave its action running
whilst tracking. If this is done the higher level sequencers will never know when the mechanism is ready.
Although in principle these systems could compare their demand positions with the current position
reported by the mechanism it would also require them to understand the dynamics of each of their
subsystems. It is more appropriate that this information resides in the subsystem. If a mechanism’s servo
was retuned for example all the higher level devices that were monitoring that mechanism would
probably have to be modified.
4.13.2 Change of track identifier

When a discontinuity appears in the stream of TCS demands it will signal this by a change of the track
identifier both within the stream of demands and as a configuration submitted to the top level controller.
The identifier changing should be considered equivalent to the receipt of a configuration that puts the
mechanism into follow mode and should therefore be handled exactly like the situation described in the
previous section. The configuration state will be “running” until the mechanism is once more within
tolerance. Even if the discontinuity is so small that the mechanism remains within tolerance all the time,
the configuration state must briefly be changed to running and then be returned to done.
If the trigger for going to “running” is simply the change of the track identifier this relieves the
mechanism from deciding whether the discontinuity is big enough to warrant going to the running state
but can instead set it unconditionally..
4.14 POSITION FEEDBACK

In spite of the above comments about using the return to done as the signal that a configuration has been
matched, all tracking mechanisms must provide the TCS with up-to-date position and velocity
information. The position events will look just like the position demand events coming from the TCS
except that that timestamp will be the actual time that the mechanism’s encoders were read and will
therefore be some (typically short) time in the past.

The TCS uses the velocity information to extrapolate the position to the times for which the TCS is doing
its pointing calculations so that if required the actual position can be compared with the demand.
In addition, as for all mechanism devices, a “within tolerance” status must be available at all times. This
within tolerance status will be monitored by the TCS at all times as a health check. Note that this status
does not duplicate the information provided by the state transitions from running to done etc. Consider
the case where a mechanism is tracking perfectly well but then can no longer keep up with the TCS
demands. This might happen for example to the azimuth axis if it is trying to track too close to the zenith.
In this case there is no start command nor any change in the track identifier so the configuration state is
always idle. The within tolerance status should be set to false however so that the TCS or OCS can take
action if required.
There is some ambiguity in whether the within tolerance status should be set false during a slew. If the
developer considers that the mechanism is following the trajectory provided by the servo then the within
tolerance parameter should be left as true. If however they consider that they haven’t matched the TCS
demand then it should be set false. The point of view adopted is at the discretion of the developer. What
is not in doubt however is at the end of the slew at the instant that the configuration state is set to done the
within tolerance status must also be true.
4.15 TELESCOPE AND SHUTTER ALIGNMENT

Early designs of the ATST required a co-rotating enclosure. It was essential therefore to drive the mount
and enclosure together at most elevations to avoid collisions between the two assemblies. The latest
design calls for the dome and mount to rotate and move independently [26] but there is still a requirement
to keep the mount and shutters aligned to avoid illuminating random parts of the telescope structure .
The first strategy that is employed is to simply reject configurations that would cause slews of the
telescope and enclosure unless one of the following holds
• The dark slide, M1 mirror cover and enclosure entrance aperture are all closed
• The time is between sunset and sunrise
• The mount and enclosure are already following and the current target and new demand are both
within 1.5 R○
This will prevent the beam from the entrance aperture accidentally sweeping over the telescope structure
but allow small slews once already tracking.
To ensure good alignment between the direction of the entrance aperture and the mount, a five parameter
enclosure pointing model will be allowed for. The five parameters will be the offset in x, y and z of the
center of rotation of the entrance aperture from the centre of rotation of the mount and the tilts north and
west of the enclosure with respect to vertical.
If we require to point to az, el with the mount and enclosure rotator centers is offset by dx, dy and dz then
the demands for the enclosure are
el ′ = tan −1 ( z ′, r ′)
az ′ = tan −1 (− y ′, x ′)
where

x ′ = x + dx = r ′ cos(az ′) cos(el ′)
y ′ = y + dy = −r ′ sin(az ′) cos(el ′)
z ′ = z + dz = r ′ sin(el ′)
and
x = r cos(az ) cos(el )
y = − r sin( az ) cos(el )
z = r sin(el )
If the tilts north and west are represented by an and aw, then the final demands are given by
⎛ x ′′ ⎞ ⎛ cos(an) 0 sin( an) ⎞⎛ x ′ ⎞
⎜ ⎟ ⎜ ⎟⎜ ⎟
⎜ y ′′ ⎟ = ⎜ − sin( an) sin( aw) cos(aw) cos(an) sin( aw) ⎟⎜ y ′ ⎟
⎜ z ′′ ⎟ ⎜ − sin( an) cos(aw) − sin( aw) cos(an) cos(aw) ⎟⎜ z ′ ⎟
⎝ ⎠ ⎝ ⎠⎝ ⎠
4.16 HANDLING THE ZENITH BLIND SPOT
Section 4.10.1.8 has described the origin and shape of the zenith blind spot. This section addresses the
strategies that could be used to handle this no-go area. There are three issues to deal with:
1) Mathematical difficulties with the pointing calculations in the presence of non-perpendicularities

in the mounting that make it impossible to view certain regions.
2) The inability of the mount to maintain tracking because of the high velocities and accelerations
required.
3) The possibility of parts of the telescope structure being illuminated by the Sun because of the
telescope and enclosure shutter becoming misaligned.
The TCSpk library implements a zenith avoidance strategy that handles (1) and the region of sky affected
(for any reasonable amount of misalignment in the telescope or instrument optics) is well inside the
region affected by (2). (2) is in itself not a problem other that observations have to be suspended when the
telescope is no longer tracking the target with required accuracy.
Whether or not (3) is a problem depends on the relative performance of the telescope and enclosure. If the
telescope is capable of higher velocity and/or acceleration than the enclosure carousel or shutter then
there could be a problem depending on the amount of misalignment that can be tolerated.
Possible options are:
• Design the enclosure performance to exceed that of the mount.
• Always close the shutters when about to track into the blind spot.
• Set the zenith no-go region (a TCSpk library parameter) large enough that the enclosure is never
requested to exceed its performance limits.

Whatever strategy is adopted, the TCS will raise an alarm to warn the user 15 minutes before the zenith
blind spot is entered and a further alarm when the blind spot is actually entered. For these purposes the
blind spot will be defined as the area within 0.5 degrees of the zenith to encompass the more complex
velocity and acceleration defined areas of avoidance.
5. DETAILED DESIGN
The preceding sections looked at some of the issues that the TCS must address in order to meet the
requirements of the ATST control system. This section looks at the detailed design of the TCS with
regard to the packages, devices and the commands that the TCS responds to.
5.1 LOADING AND INITIALIZATION

Startup and boot of the TCS is handled by an OCS Container Manager. A container manager will start the
TCS on the TCS CPU and the environment package on the weather server CPU. The container manger
will in turn use the services of the component loader to start each of the TCS controllers (those colored
blue in Figure 12)
The controllers once loaded will be in the loaded state. In this state they will do very little. There will for
example be no events generated by them nor will they subscribe to any events. What they will do is read
their default initialization parameters from the real time database e.g. the pk device will read such
parameters as the longitude and latitude of the site.
In this state the devices will only respond to the init, set and get commands. The table below shows the
actions that will be taken by each component when the init command is received.
Device Actions
tcs 1. Forward init command to ACS
thermal 1. Connect to all external event streams
2. Spawn background task to monitor events and run checks that thermal
environment is within specification
3. Raise alarms if thermal environment is out of specification
ems 1. Connect to weather server raw event streams
2. Spawn background task to read and smooth data appropriately for the TCS
pointing kernel
3. Publish event stream of smoothed data
pk 1. Connect to smoothed data stream of ems device
2. Spawn slow, medium and fast threads for each of the virtual telescopes
3. Publish event streams for use by TCS subsystems
seq 1. Forward init command to each TCS subsystem
The init command will be forwarded to each of the TCS subsystems by the appropriate TCS device. To
see what actions this will cause in these subsystems, refer to the relevant subsystem design document. In
the case of the M1CS it is expected that the system will already be initialized as it will be constantly
conditioning the mirror to maintain its temperature within 2° C below ambient.
In the above description it has been assumed that the init command was sent without an AttributeTable. In
practice this may or may not be the case. The TCS is required to be able to recover static information after
a restart or reboot. This static information may be of two types. The first is the truly static data that will
essentially never need to be changed. A good example of this is the latitude and longitude of the site
needed by the pk device. The second type is calibration data that may be regenerated each day. For this

type of data there will be both default values as well as what we will call the session values. The session
values are the values determined by regular calibrations. For this second type of data we need to provide
the option of initializing with the default values or the session values. This will be particularly important
if the TCS has had to be rebooted and we want to bring the TCS back to the state it was in prior to the
shutdown.
The TCS engineering screens will provide an option to set up a configuration that can then be sent with
the init command. Since the set of session parameters will be well defined, the way this will be done will
be to provide a check list of session parameters that can be restored. By default no session parameters will
be restored but by selecting the appropriate check boxes a configuration will be generated that restores
those selected. attributes.
5.2 STARTUP
Once initialized the next step will be for the OCS to issue a startup to the TCS. The purpose of the startup
command is to bring the TCS and all its subsystems into a state where they can accept functional
directives i.e. they can be sent configurations with a submit command. The main task for the TCS during
this stage is to simply forward the submit command to all its subsystems
5.3 OPERATIONAL STARTUP
Once all the subsystems have been brought to the running state, a first subsystem functional configuration
will be issued to the TCS by the OCS. A typical configuration might have the following components
Attribute Value Comment

atst.tcs.refsys HP This and next attribute could be any valid system and
atst.tcs.target 0.0, 0.0 target that specified the center of the solar disk
atst.tcs.wavelength 0.5 Nominal wavelength for ACS
atst.tcs.tracking On
atst.tcs.obsmode Disk
atst.tcs.focus coude1
atst.tcs.ecs.coolmode Ambient
atst.tcs.ecs.fanpos ?? This will be dependent on external conditions. It may
with experience be possible to generate a value
dependent on the external conditions
atst.tcs.ecs.ventpattern 0 Again the actual pattern in time should ideally be
derivable from the external conditions
atst.tcs.hsa.cooling On
atst.tcs.m1cs.thermalprofile ?? Will depend on model
atst.tcs.m1cs.thermalmodel On We expect the M1CS will run continuously and will
already have a thermal profile to follow and the model
will be switched on
atst.tcs.focs.airknife On
atst.tcs.focs.thermalControl ON
atst.tcs.agcs.camera RUNNING
atst.tcs.agcs.filter <Filter name>
atst.tcs.m2cs.thermalControl ON
Table 2 Attributes in the startup configuration

It can be seen from the above list that many of the attributes will simply be passed on to the TCS
subsystem devices. The ones that are intercepted by the tcs device however will cause the following
attributes to be added to the configuration passed on
Attribute Generated attribute Value Comment

atst.tcs.refsys, atst.tcs.target, atst.tcs.pk.coudevt.target Ψ,Φ
atst.tcs.wavelength
atst.tcs.pk.coudevt.refsys HP
atst.tcs.pk.coudevt.trackrefsys HP
atst.tcs.pk.coudevt.wavelength 0.5
atst.tcs.tracking atst.tcs.mcs.mountmode FOLLOW
atst.tcs.mcs.coudemode FOLLOW
atst.tcs.ecs.mode FOLLOW
atst.tcs.m2cs.mode FOLLOW
atst.tcs.m1cs.controlmode ACTIVE It is expected that in
practice this will already
be ACTIVE
atst.tcs.m1cs.controlmodel DEFAULT
atst.tcs.m2cs.
atst.tcs.focus atst.tcs.focs.focus COUDE
Table 3 Generated attributes
There are naturally some assumptions in this startup configuration, for example that the observing station
is coudé and not Nasmyth but this is easily handled by a change of attribute value.
5.3.1 Observing startup

Once the above configurations have been matched, the next stage is to bring the telescope into an
observing configuration. This involves opening the enclosure aperture, mirror cover and dark slide. It is
assumed that these operations will be under the control of the telescope operator and observatory scientist.
A simple configuration will be sent with the single attribute atst.tcs.ecs.coverpos set to OPEN. It will then
be verified that the ACS is indeed seeing the full solar disk and that the telescope is tracking the disk
center. Once this has been done another simple configuration will be sent but this time with the attribute
atst.tcs.mcs.m1cover.pos set to OPEN.
Once it is confirmed that the setup is correct then the dark slide can be opened and instrument setup can
be completed.
5.4 CONFIGURATIONS
The configuration package is responsible accepting desired configurations from the OCS or ICS,
verifying those configurations and then creating configurations for its subsystems such that the state of
the TCS as a whole will match the requested state in the configuration.
The major tasks of the configuration package are therefore

- verifying a configuration
- expanding a configuration into configurations for sub controllers
The class diagram below shows the major components of the configuration package

Controller
Sequence
1..* - _pauseFlags :HashMap = null
- _cancelFlags :HashMap = null
ConfigHandler - _seqMap:HashMap = null
- _currentPhase :HashMap = null
Interlock #doInit (att :IAttributeTable ):void

1..* + ConfigHandler (config :Configuration ):ConfigHandler
#doAction (config :IConfiguration ):String
+ addInterlock (interlock :Interlock ):void
#doPause (configID :String ):boolean
+ isInterlocked ():boolean
#doResume (configID :String ):boolean
+ getInvalidAttributes ():AttributeTable
#doCancel (configID :String ):boolean
+ getOutofRangeAttributes ():AttributeTable
- setPauseFlag(id :String ,pause :boolean ):void
+ conflictsExist ():String
- getPauseFlag (id :String ):boolean
+ selfConsistent ():String
- addPhaseMap (id :String ,map :HashMap ):void
+ setNewConfig (config :Configuration ):void
- removePhaseMap (id :String ):void
+ splitConfig ():HashMap
- cancelPhaseMap (id :String ):void
- setCancelFlag (id :String ,flag :boolean ):void
- getCancelFlag (id :String ):boolean
- setCurrentPhase (id :String ,no :int ):void
- getCurrentPhase (id :String ):int
- removeCurrentPhase (id :String ):void
1..*
Phase
- _name :String = ""
- config :IConfiguration = null
- cc:HashMap = null
+ add (att :IAttribute ):void

+ execute ():String
#issue (config :IConfiguration ,controller :String ,queue :IAttributeTable ):int
+ cancel ():void
- addToQueue (id :String ,queue :IAttributeTable ):void
- signalDone (id :String ,queue :IAttributeTable ):void
- signalAbort (id :String ,reason :String ,queue :IAttributeTable ):void
- checkAbort (queue :IAttributeTable ):String
+ queueFinished (queue :IAttributeTable ):boolean
Figure 19 Classes in the configuration package
The first task of the Configuration Handler is to check if is interlocked. The default assumption is that if
an interlock is present then all configurations are rejected. The exceptions to this rule are configurations
that consist solely of any combination of the following attribute / value pairs
- atst.tcs.mode halt
- atst.tcs.debugCategory Any category
- atst.tcs.debugLevel Any level
- atst.tcs.globalInterlock Off
- atst.tcs.mcsmountmode halt
- atst.tcs.mcscoudemode halt
- atst.tcs.mcsnasmythmode halt
The logic behind these exceptions is that in the presence of a global interlock any method that could
potentially stop a large moving mechanism should be permitted. In practice, it would be hoped that the
hardware safety systems will already have halted the main axes. The debug related attributes are allowed
as they may yield extra information about the cause of the interlock.
The globalInterlock attribute is allowed so that a previously manually set interlock from the TCS can be
cleared. If this were not permitted then after a manually set interlock the only way the TCS could recover
would be to be rebooted. Whether the GIS will drop its global interlock signal is another matter.

The next check by the handler is to make sure that all the attribute names within the configuration are
valid. Note that this only applies to the TCS specific attributes. For the subsystems, the check will only be
to the level of the subsystem name, anything below this will be the responsibility of the subsystem to
verify. For example if a client sent the attribute atst.tcs.mcs.ax.maxvel when what they had meant to send
was atst.tcs.mcs.az.maxvel then the TCS would accept this as a valid attribute and pass it on. If on the
other hand the attribute sent was atst.tcs.tricking when what was meant was atst.tcs.tracking then the
configuration would be rejected. Valid attributes for the TCS start with the following prefixes:
- atst.tcs.
- atst.tcs.mcs.
- atst.tcs.ecs.
- atst.tcs.m1cs.
- atst.tcs.m2cs
- atst.tcs.pac.
- atst.tcs.hsa.
- atst.tcs.wccs.
- atst.tcs.focs.
- atst.tcs.acs.
Now that all the attributes sent are known to exist, they are range checked using the property service
provided by the ATST common services.
The next step is to expand the attributes in the configuration and check for any conflicts. Some attributes
set for the TCS require multiple attributes to be set in one or more configurations that go to the
subsystems. It is possible therefore to create a configuration that contains conflicting demands. The
configuration handler goes through each attribute in turn and expands it into a new attribute table
containing the set of attributes that will be sent to the subsystems. If this expansion produces an attribute
that is already in the new table with a conflicting value then the configuration is rejected. The following
table shows some attributes and values that would produce conflicts
Attribute Value Conflicts

atst.tcs.tracking On atst.tcs.mode – any value other than follow
atst.tcs.mcsmountmode – any value other than follow
atst.tcs.mcscoudemode – any value other than follow
atst.tcs.mcsnasmythmode – any value other than follow
atst.tcs.tracking Off atst.tcs.mode – any value (tracking off requires a sequence)
atst.tcs.mcsmountmode – any value
atst.tcs.mcscoudemode – any value
atst.tcs.mcsnasmythmode – any value
atst.tcs.m1cover – open
atst.tcs.aperture – open
atst.tcs.mode Any atst.tcs.mcsmountmode – if value is not same as atst.tcs.mode’s
atst.tcs.mcscoudemode – ditto
atst.tcs.mcsnasmythmode – ditto
The outcome of the preceding checks will be a configuration that is internally self consistent. Before it
can be acted on however it must be verified that combining it with the current state of the telescope will
produce a consistent state. A simple example here would be if a valid RA was supplied but no
declination. Combining the RA with the current declination could produce a target below the current
elevation limit.

Assuming all the above checks are passed, the configuration handler splits the configuration into separate
configurations, one for each sub controller and then issues them in parallel to those sub controllers. It is a
requirement of the common services protocol that the controller issuing the configuration remains busy
until all the actions it has started are complete. This is handled by a queue. All submitted configurations
are added to a queue and the status of those configurations is saved as each one is either rejected or their
action completes. Once replies are received (or have timed out) from all sub controllers the final status of
the initial configuration is determined and passed back via the event service to the system that sent the
configuration.
5.4.1 Sequencing
Many attributes received by the TCS are simple in that they affect just one subsystem or can be matched
by successfully executing a single action. Others are complex in that they may require the successful
completion of actions in multiple subsystems and those actions may need to be ordered. Some examples
of these types of attributes are given in the following section. here we describe the sequence component
which will handle these complex attributes.
The sequence component is structured around “phases”. Each phase of a sequence can issue an arbitrary
configuration to an arbitrary number of subcomponents and each sequence can consist of an arbitrary
number of phases. The prototype of a Phase class is shown in Figure 19.
The key methods here are “execute” and the protected method “issue”. Execute creates a table of all the
sub controllers it must send configurations to along with the configurations themselves. It then calls
“issue” to submit those configurations in parallel. It then goes into a loop, waiting for each sub controller
to either reject the configuration or to end its action in either OK or error and then returns itself.
Once a phase is complete, the sequence controller will execute the next phase until all the phases are
complete. Setting up the configuration to send to the sequencer will proceed as follows:
• If an attribute is simple then insert it into phase1. For example the attribute atst.tcs.xxx would get
passed to the sequencer as the attribute atst.tcs.seq.phase1.atst.tcs.xxx. The sequencer would strip
of the atst.tcs.seq prefix and add the attribute atst.tcs.xxx to phase 1.
• If the attribute was complex then it would be split into its various stages and then passed to the
sequencer. For example under certain conditions (see 5.4.2.3) we expect to close the entrance
aperture before we slew the enclosure itself. If these conditions apply then on receipt of say
atst.tcs.ecsmode move we would construct a configuration
atst.tcs.seq.phase1.atst.tcs.ecs.coverpos Closed
atst.tcs.seq.phase2.atst.tcs.ecs.mode move
This would be passed to the sequencer which would wait for the aperture cover to close before
attempting the move. If the aperture cover failed to close then the move would not be issued. If a
pause was received before the move was issued then the sequence would pause after the
completion of phase 1 and would continue to the move only after receiving a resume.
Setting up the sequencer in this way opens the possibility of simple user defined sequences being
definable at the TCS level. The user interface could provide a means of explicitly adding arbitrary
configuration attributes to different phases.
5.4.2 Complex TCS attributes

In many cases attributes given in a configuration are simple. They specify one property or affect one
subsystem. Other attributes, typically those that attempt to define high level observing states for the
telescope are complicated. A single attribute specified by the OCS may require many attributes to be sent

to one or more TCS subsystems and it may be necessary to sequence how those attributes are set. This
section lists these complex attributes and defines how they operate.
Where there are multiple phases, then all the actions started in the preceding phase must complete without
error before moving on to the next phase.
5.4.2.1 ATST.TCS.TRACKING OFF
Phase 1 atst.tcs.wccs.activeoptics open

atst.tcs.wccs.fieldstab open
atst.tcs.wccs.adaptiveoptics open
Phase 2 atst.tcs.pac.darkslide In
atst.tcs.mcs.m1cover Close
atst.tcs.ecs.coverpos Closed
Phase 3 atst.tcs.mcs.mountmode halt

atst.tcs.mcs.coudemode halt (if focus is coude)
atst.tcs.mcs.nasmythmode halt (if focus is nasmyth)
atst.tcs.ecs.mode halt
atst.tcs.hsa.occultermode halt (if obsmode is corona)
5.4.2.2 ATST.TCS.TRACKING ON
If dark slide, M1 mirror cover and entrance aperture are all closed or the time is between sunset and
sunrise or we are already following and the current target and demand target are within 1.5R○ then
Phase1 atst.tcs.mcs.mountmode follow

atst.tcs.ecs.mode follow
atst.tcs.hsa.occultermode follow (if obsmode is corona)
atst.tcs.mcs.coudemode follow (if focus is coude)
atst.tcs.mcs.nasmythmode follow (if focus is nasmyth)
atst.tcs.wccs.activeoptics open
atst.tcs.wccs.fieldstab open
atst.tcs.wccs.adaptiveoptics open
5.4.2.3 ATST.TCS.ECSMODE
If the enclosure aperture is closed or it is open and the time is between sunset and sunrise then allow any
parameter to be sent
Phase1 atst.tcs.ecs.mode move | halt | service | datum | park | follow
If the enclosure aperture is open, the time is between sunrise and sunset, both current position and new
target position are within 1.5 R○ and the demand attribute is follow
Phase1 atst.tcs.ecs.mode follow
otherwise
Phase1 atst.tcs.ecs.coverpos Closed

Phase2 atst.tcs.ecs.mode move | halt | service | datum | park | follow
5.4.2.4 ATST.TCS.MCSMOUNTMODE
If the enclosure aperture is closed or it is open and the time is between sunset and sunrise then allow any
parameter to be sent
Phase1 atst.tcs.mcs.mountmode move | halt | service | datum | park | follow
If the enclosure aperture is open, the time is between sunrise and sunset, both current position and new
target position are within 1.5 R○ and the demand attribute is follow
Phase1 atst.tcs.mcs.mountmode follow
otherwise
Phase1 atst.tcs.ecs.coverpos Closed
Phase2 atst.tcs.mcs.mountmode move | halt | service | datum | park | follow
5.5 INTERLOCKS
The TCS is required to respond to interlock demands from the Global Interlock System (GIS). The TCS
design assumes that the TCS subsystems will also receive these interlock demands and that it therefore
has no role in passing such demands on to them. The reason for this is that the GIS constitutes the major
safety system both for personnel and equipment and that the introduction of a software system like the
TCS into the interlock path would substantially reduce its effectiveness.
In response to an interlock demand, the TCS will disable all commands within the configuration handler
with a few exceptions. The starting assumption will be that all commands will be disabled and then
individual commands and attributes will be looked at to see whether in fact they are safe to let through.
Any attribute that would result in mechanism movement will definitely be rejected. Any attribute that
stops a moving mechanism will be a candidate for acceptance. The one attribute that will be let through is
the globalInterlock attribute for the reasons given below. If the TCS does accept an attribute or command
in the presence of an interlock and passes this on to a subsystem, it will ultimately be the responsibility of
the subsystems to decide whether it is safe to take any action. Once the interlock is removed the TCS will
immediately revert to accepting commands and configurations again. No special action will be needed to
make this happen other than the removal of the interlock. I
For the same reasons that the TCS will not attempt to pass interlocks to its subsystems it also assumes that
it has no need to generate an interlock. The only cases where it might be appropriate for the TCS to raise
an interlock would be where the unsafe state came about from the combined configuration of two or more
of its subsystems. No such configurations have yet been identified but if they were then it would be better
to re-design the subsystems such that they could detect the condition and take action directly. Reliance on
a supervisory software system like the TCS in a safety critical situation is not appropriate.
In order to meet the requirements that the TCS generate a global interlock, it will have an attribute that
will allow an interlock to be generated manually. This will be something like the software equivalent of
the emergency stop button. If the TCS receives this attribute with a value of “On” then it will raise an

interlock and disable all its commands. It will then be the responsibility of the GIS to distribute this to
remainder of the observatory and the responsibility of the subsystems how they respond.
It was said earlier that all commands with the exception of stop and offline would be ignored when a
global interlock was in place, There is one exception to this rule. If the TCS has manually set an interlock
then a configuration with an interlock attribute of “Off” will be accepted and the manual interlock
cleared. This will prevent a deadlock situation where once an interlock has been set it can only be cleared
by a reboot.
5.5.1.1 INTERLOCK OVERRIDE

As there is no safety function that is the prime responsibility of the TCS and, apart from the interlock
system itself, it is not directly connected to any hardware, it will be possible to over ride an interlock from
the GIS. The main reason for permitting this is to simplify development. Without an over ride, any time
that the TCS is being tested standalone it would be necessary to provide a hardware clear signal to the
GIS input to prevent the interlock triggering.
The overall logic for the interlock signals will therefore be:
On initialization if digital i/o card not present

Set interlockOverride to True
If ManualInterlock is requested
Set interlockOverride to False
If interlockOverride is requested and ManualInterlock is set
Reject interlockOverride request
If GISInterlock is set or ManualInterlock is set and not interlockOverride
Disable all configurations
The first statements ensure that if the hardware card isn’t present then no attempt will be made to access
its inputs and the TCS will come up in an operational state.
The next “If” statements ensure that if the user requests a manual interlock then that is exactly what they
will get and that if an interlock has been explicitly set then it can’t be over ridden.
5.6 POINTING KERNEL

All the pointing and related calculations are performed by the atst.tcs.pk component which generates
demand trajectories for the mount, enclosure, rotators and other continuously tracking mechanisms. The
pk component will contain a number of sub-components but the hierarchy will not extend outside the
TCS. These sub-components will be tightly coupled with communication between them being through
shared memory and not through the common services. Event generation starts when the components enter
the online state and continue until they go off-line.
The pointing calculations are performed by three cooperating execution threads running at different
priorities:
• The “slow” thread calculates position independent refraction constants, the heliocentric Earth
ephemeris and the precession-nutation matrix required to track positions in the ICRS. This
executes once a minute at the lowest priority.
• The “medium” thread updates the solar ephemeris parameters for the current time and then
computes the basic ephemeris values, it re-computes the local telescope pointing model based on
the current azimuth and altitude of the mount and does other housekeeping tasks associated with

the pointing calculations. It runs every 10 seconds at a higher priority than “slow” but at a lower
priority than “fast.
• The “fast” thread runs every 50 milliseconds and generates the subsystem trajectories using the
pre-computed ephemeris data and the appropriate transformation functions to take the target in
heliographic, heliocentric or helioprojective into topocentric apparent place and hence through the
pointing model into azimuth, elevation and rotation demands.
The pointing kernel will be implemented with the tpk C++ class library currently being deployed on the
Large Binocular Telescope and the TCSpk and SLALIB/C libraries that support it.
5.6.1 Sub-components
5.6.1.1 ATST.TCS.PK.SITE
This component subscribes to events generated by the weather server component to obtain the current
atmospheric pressure, temperature and humidity.
Name Type Units Comment

delut float Seconds UT1 - UTC
delat float Seconds TAI - UTC
ttmtai float Seconds TT - TAI
elong float Degrees East longitude of observatory
lat float Degrees Latitude of observatory
hm float metres The elevation above sea level of observatory
xpm float arc-seconds The X component of the polar motion
ypm float arc-seconds The Y component of the polar motion
5.6.1.2 ATST.TCS.PK.COUDEVT
This component generates trajectories for the mount, enclosure and coudé room rotation when a coudé
instrument has control of the telescope.

target float, float degrees Target position as spherical coordinates
refsys choice HS | HG | ICRF Reference system of the target coordinates
trackrate float, float arcsec/second Target differential track rates
trackrefsys choice HS | HG | ICRF Track rates coordinate reference system
offset float, float arcsec Target offsets
offsetrefsys choice HS | HG | ICRF Offsets coordinate reference system
wavelength float microns Effective wavelength
po float instrument coordinates Pointing origin
pooffset float instrument coordinates Pointing origin offset
transform float x 6 Instrument to focal plane coordinate
transformation
ipa float degrees Instrument position angle
rotrefsys choice HS | HG | ICRF Coordinate reference system of the position
angle

iaa float degrees

pointmodel filename Coudé focus pointing model
The component will subscribe to the atst.tcs.mcs.coude.cpos event so that it can use the current position
of the coudé rotator in its pointing calculations.
5.6.1.3 ATST.TCS.PK.NASMYTHVT
This component generates trajectories for the mount, enclosure and Nasmyth image rotator when a
Nasmyth instrument has control of the telescope.

target float, float degrees Target position as spherical coordinates
refsys choice HS | HG | ICRF Reference system of the target coordinates
trackrate float, float arcsec/second Target differential track rates
trackrefsys choice HS | HG | ICRF Track rates coordinate reference system
offset float, float arcsec Target offsets
offsetrefsys choice HS | HG | ICRF Offsets coordinate reference system
po float instrument coordinates Pointing origin
pooffset float instrument coordinates Pointing origin offset
transform float x 6 Instrument to focal plane coordinate
transformation
ipa float degrees Instrument position angle
rotrefsys choice HS | HG | ICRF Coordinate reference system of the position
angle
iaa float degrees
pointmodel filename Nasmyth focus pointing model
The component will subscribe to the atst.tcs.mcs.nasmyth.cpos event so that it can use the current position
of the nasmyth rotator in its pointing calculations.
5.6.1.4 ATCS.TCS.PK.OCCULTER
This component generates a position trajectory for the prime focus occulting disk.

pointmodel filename Prime focus pointing model
transform float x 6 Occulter to focal plane coordinate
transformation
5.6.1.5 ACQUISITION AUXILIARY TELESCOPE
Generates WCS information for the display of and interaction with acquisition images and predicts
position of sun on detector for possible use as a guider.


pointmodel filename Acquisition telescope pointing model

transform float x 6 CCD camera to focal plane coordinate
transformation
5.6.2 Operating Modes
This section describes the various ways in which the telescope can be operated in respect of where signals
from the guider, correlation tracker and adaptive optics can be routed and what quantities are adjusted as a
result of these signals.
5.6.2.1 OPEN-LOOP TRACKING
Open loop tracking will be the mode used for seeing limited coronal observations (assuming there is
insufficient granularity in the 5 arcmin FOV for the trackers to lock on to). The pointing of the telescope
will be dependent on the accuracies of the ephemerides, the telescope pointing calibration and the
smoothness of the drives. The alignment of the optics will be dependent on pre-calibrated models.
5.6.2.2 OPEN-LOOP TRACKING + AO
In this mode, any DC tip/tilt that accumulates in the AO system must be off-loaded to the mount. This DC
tip & tilt can be caused either by imperfections in the mount pointing model or by the feature that the AO
system is locked on to wandering over the surface of the sun. The AO system is effectively in control of
the pointing of the telescope and adjustments to the mount virtual telescope are there just to maintain
proper world coordinate information. If the tip/tilt is assumed to be the result of the solar granularity
wandering then the target position should be adjusted, otherwise the pointing model is adjusted.
5.6.2.3 CORRELATION TRACKING
In this mode the correlation tracker tilts M2 or M6 and behaves like an autoguider in “hold-it-right-there”
mode. It is very similar to the open-loop + AO case but the effects of different effective wavelengths for
the correlation tracker and science detector have to be taken into account. This is done by feeding the
correlation tracker the expected image shift (it starts out as zero and then gradually changes as the amount
of dispersion changes).
The “guide” correction will be fed into adjustments to the target that the currently active mount virtual
telescope is tracking.
5.6.2.4 CORRELATION TRACKING + AO
This is identical to the correlation tracking mode. Any tip/tilt component of the wave-front error detected
by the AO is simply discarded.
5.6.2.5 LIMB GUIDING
The limb guider (if implemented) is treated just like a conventional auto-guider with the guiding
corrections being fed into the currently active mount virtual telescope pointing model.
5.6.2.6 LIMB GUIDING + CORRELATION TRACKING

This is just a combination of the correlation tracking and limb guiding modes. Corrections from the two
subsystems are fed into the target position and pointing model respectively.
5.7 POINTING UPDATE TOOL

The pointingUpdate tool will be a graphical tool to create a pointing map for the telescope. The tool will
be able to select a catalogue of pointing targets and then allow a number of strategies for selecting targets
from that catalogue. For example all the targets in a catalogue could be used or a random selection or a
user selected set etc. It will be possible to control whether the telescope immediately slews to the next
target once the current target is completed or whether this is under user control.
To give an idea of the type of interface that will be provided, the top level screen of the tool designed by
D. Terrett for Gemini is illustrated in the diagram below.
Figure 20 The Gemini TCS pointing model update tool
The main display is shown after a catalogue has been loaded. The orange dot shows where the telescope
is currently pointing (in this case to the zenith) and the white dots are the individual catalogue stars at
their current positions. The red circle presents the lower elevation limit of the telescope showing that
some targets in the catalogue are already below the horizon limit.
The user can select a star by clicking on it and then pressing the “Slew to target” button or a more
automated sequence can be chosen. Once the telescope has settled, the target will be adjusted onto a

fiducial on the context viewer and then the data logged. In the Gemini system the image display system is
separate from the pointing model update tool but this need not be the case for the ATST depending on
what facilities are provided to access the data streams from the context viewers. The ATST point update
tool will be implemented as an ATST component using either the Java Swing widget set or, depending on
the status of the Python port of the common services, Tkinter.
The logged data will be in the format required for TPOINT. This package provides comprehensive
facilities for displaying and analyzing pointing data but, more importantly, the TPOINT transformations
are built in to the pointing kernel. This means that any fits made with TPOINT can be implemented
immediately in the TCS simply by setting the relevant configuration parameters.
(Need to check what are the facilities provided/required to look at historical trends in pointing?)
5.8 ENVIRONMENT
The environment package reads and publishes on an event channel the following weather data
- a time stamp
- the air temperature (deg C)
- the atmospheric pressure (mbar)
- the relative humidity (0 – 1.0)
- the dew point (deg C)
- the wind direction (degs)
- the wind speed (km / hr)
- the total solar radiance (W / m2 )
In addition it may have to provide

- all sky camera images
- Solar differential image motion (SDIMM ?) estimates of r0
- Shadow Band Ranging (SHABAR) estimates of the low altitude seeing profile
These last three are currently poorly specified. They fall naturally into the environment package however
as they are data that will need to be collected even if the ATST itself is not functioning. An important
function of the environment package is to provide temperature, pressure and humidity measurements to
the TCS pointing kernel for its wavelength dependent refraction calculations.
In the worst case of observing is at an altitude of 10 degrees and a wavelength of 0.3μm. The sensitivities
to temperature, pressure and humidity fluctuations are 0.35 arcsec/hPa, 1.00 arcsec/degC and 0.01
arcsec/%.
In order not to degrade the absolute pointing by 0.5 arcsec which is 10% of the blind pointing error
budget then
• The pressure accuracy needs to be 1.5 hPa or better
• The temperature accuracy needs to be 0.5 deg C or better
• The relative humidity accuracy needs to be 50% or better
To match the 0.5 arcsec / hour tracking stability the drifts in the above readings must be less than one
tenth of the above figures again using 10% of the available error budget contribution.
To achieve these accuracies, the raw data from the sensors must be averaged over time and also over
sensors if redundant sensors are available. It is important that spurious data is not fed to the TCS from
noisy readings or faulty sensors. The sensor averaging will compute a running mean over a specified
number (N) of samples. The individual raw values will be flagged as bad and ignored if they differ by

more than n sigma from the current filtered value. If N samples in a row are bad then an alarm will be
raised.
5.9 THERMAL CONTROL PACKAGE

The main purpose of the thermal control package is to monitor the thermal state of all the TCS
subsystems and to place those subsystems in a safe state by removing the thermal load if those systems
exceed their thermal tolerances. The methods the TCS will use to remove the thermal load are
- To close the dark slide in the polarization and calibration unit

- To close the M1 mirror cover
- To close the enclosure aperture cover
Although each subsystem will monitor its own thermal load and would set its health to bad if it detected a
failure of its cooling system or an excessive rise in temperature, in general these subsystems do not have
the means to remove the thermal load.
The thermal monitoring function provided by the TCS should be considered as the equivalent of a soft
limit for a moving mechanism. Many of the thermal systems the TCS will be monitoring will be
connected directly to the GIS and this will trigger hardware interlocks under severe thermal overloads.
The TCS tolerances will be tuned where possible so that the system is placed into a safe state before the
hard limits of the GIS can be triggered.
The data that the TCS will monitor to decide whether to take action is as follows
Subsystem Signal Trigger Comment

Interlock?
TCS Ambient air Can we get ambient air temperatures close to each
temperature (°C) mechanism? If so we need each of those
ECS Air conditioning (on /
off)
ECS Skin cooling (on/off)
ECS Skin temperature(s)
(°C)
ECS Air flushing (on/off) Are there gradations or is it simply on/off
M1 Mirror cover state
(open/close)
M1 Aperture plate Are there any and if so are they part of M1??
radiation sensors
M1 Aperture plate cooling Yes
(on/off)
M1 Aperture plate
temperature(s) (°C)
M1 Mirror surface Yes The sensors are under the aperture plate stop
temperature (°C)
M1 Mirror backside Yes
cooling (on/off)
M1 Mirror backside Yes
temperature (° C)
M1 Mirror front side
heating (on/off)

M1 Mirror front side set

point (° C)
MCS Structure Yes
temperature(s)
HSA Heat stop cooling (on / Yes
off)
HSA Plume control (on/off)
HSA Coolant temperature Yes
(°C)
HSA Beam dump irradiance
(W / m2)
HSA Heat Stop irradiance Not sure if this exists
(W / m2)
M2 M2 Cooling (on/off) Yes
M2 M2 temperature (° C) Yes
FOCS M3 cooling (on/off) Yes
FOCS M3 temperature (° C) Yes
FOCS M3N cooling (on/off) Yes If observing at Nasmyth
FOCS M3N temperature (° C) Yes If observing at Nasmyth
FOCS M8 temperature (°C) Yes
Once the thermal load is removed from the TCS subsystems they will be able to restart operations when
initiated by the operator through the TCS. They will not need to be rebooted or re-initialized.

Only the data with a “Yes” in the column “Trigger Interlock?” will be used when deciding to remove the
thermal load and this in turn will depend on the observing mode the telescope is operating under. The four
modes are “Corona”, “Disk”, “Night” and “Engineering”. For each incoming signal a bit mask will be
provided consisting of three bits one for each of the mechanisms that can remove the heat load i.e. the
dark slide (bit 0), mirror cover (bit 1) and enclosure aperture (bit 2). A set bit will indicate the mechanism
is to be closed. There will be separate bit masks for the modes Corona/Disk and Night. Engineering mode
will use the masks for Night between sunset and sunrise. At other times it will use the masks for Corona
/Disk.
The thermal protection loop will operate as follows:

1. Each signal will be checked its validity. A cooling signal will be valid if the cooling is on, a
temperature signal will be valid if the temperature is within some offset from ambient.
2. If a signal is valid the bit mask used will be set to zero. If the signal is invalid the bit mask passed
on will be the one appropriate for the current observing mode and focal station. If the current
focal station is Nasmyth for example then the masks passed on for mirrors M3 to M13 will be
zero even if the cooling is off and the temperatures out of tolerance. Similarly if operating at
Coudé the masks for M3N to M5N will be zero.
3. All the bit masks will be or’ed to provide a single mask.
4. If bit 0 is set then the dark slide will be closed and a software interlock set to prevent it being
opened via the TCS
5. If bit 1 is set then the mirror cover will be closed and a software interlock set to prevent it being
opened through the TCS
6. If bit 2 is set then the enclosure aperture will be closed and a software interlock set to prevent it
being opened through the TCS.
7. If on a subsequent loop a bit in the final mask is clear then the software interlock for that
mechanism will be cleared so that the mechanism can again be opened by the operator.
The bit masks and tolerances for the temperature readings will be stored in the property database so that
the system can be re-configured without requiring a rebuild of the system. The bit mask settings in the
various modes and for the different signals are shown below. At this stage, a conservative approach is
adopted where all mechanisms are closed if any signal is invalid.
Signal Corona or Disk Night

Mirror cooling 111 000
Mirror temperature out 111 000
of tolerance
HSA Cooling 111 000
HSA temperature 111 000
MCS structure 111 000
temperature
Table 4 Bit masks for invalid signals
Although the main task of the thermal package is to monitor the thermal loads, the TCS will perform a
number of other important functions within the thermal control package as described in the sections
below.
5.9.1 Consolidate thermal data

The TCS will provide a point at which all the thermal information from the telescope is brought together
in a single location. This will allow the operators to see at a glance the thermal state of the observatory
without having to access a whole range of subsystem engineering screens. The preferred method of

presenting this will be a schematic of the main telescope mechanisms. Components will then flash yellow
or red when a mechanism is out of thermal tolerance or if flow rates are not correct etc. Either sub-
screens or pop-ups will then provide additional information on the nature of the problem when the
operator clicks or places a cursor over the symbol. The exact nature of the feedback will depend on the
facilities provided by the Common Services GUI tools.
5.9.2 Seeing reduction

As experience is built up with the how the seeing varies as a function of the temperatures of the telescope,
the wind direction and speed and the enclosure vent configuration it may be possible to react to
environmental state and set the fans and vents to minimize the seeing. These models would reside within
the thermal control package.
5.9.3 M1 Thermal Model

If a predictive or a reactive M1 thermal model is required then this will be monitored within the thermal
package. The purpose of the M1 model is to keep the M1 mirror surface temperature within 0-2° C below
the current ambient temperature. The predictive models will provide forecasts up to at least 2 hours in the
future.
It is not the job of the TCS to generate the forecasts although it is its responsibility to ensure they are sent
in a “timely” manner on a daily basis. To meet this requirement, the TCS will receive a configuration
containing the attribute atst.tcs.m1cs.thermalprofile from a component of the OCS which it will
immediately forward to the M1 control system. The TCS will note the time it has received the forecast
and will set a timer to expire in the shorter of 24 hours or the last time in the forecast profile. The start
time will also be recorded in the property database so that if the TCS is rebooted it can restart its timer for
the correct duration. If the profile is reactive then the timer will expire in 24 hours. A warning will be
raised 120 minutes before the timer expires to notify the operator that a new profile is required and an
error condition will be set if the timer actually expires.
In addition, the thermal package will monitor the events atst.tcs.m1cs.thermalState and mirrorTemps.
The TCS will take the following actions in response to the data contained in these events. Firstly for
thermalState:
1. The control attribute shows whether the cooling is on or off. This will be used by the thermal
overload code to determine whether the mirror cover etc. should be closed dependent on the
observing mode. This has been covered in Section 5.9.
2. The model attribute will be either “Predictive” or “Reactive”. This will simply be used for
information purposes on the thermal overview display screen.
3. The outofdate attribute will be true if the thermal profile supplied doesn’t encompass the current
time. In this case an alarm will be raised in the thermal overview screen. Outofdate will always be
false if the model is reactive.
In the case of mirrorTemps, the actions will be:

1. The attributes mirrortemp and airtemp will simply be used for displays
2. An alarm will be raised if difftemp is more than offset. Difftemp is the difference between the
mirror temperature and the ambient air temperature and offset is the target difference. Typically
offset will be -2.0. Depending on the settings of the signal masks (see section 5.9 above) an alarm
may also trigger the closure of the dark slide, mirror cover etc.
5.9.4 Thermal control

The TCS can operate its subsystems in a number of modes to achieve the desired thermal environment of
the telescope. The default behaviour will be to activate all cooling loops when the subsystems are brought

online. It will be up to the subsystem to decide what the set point of its coolant flows is in order to
achieve the desired effect of maintaining its mechanisms at or within 2° C below of the current ambient
air temperature.
The enclosure control system will have four operating modes depending on the external conditions these
are
Default – this will be the standard startup state when coming online. Skin cooling will be on in order to
keep the enclosure close to the ambient air temperature (Is the cooling split into zones, can we specify a
set point other than the ambient air temperature ?) and there will be passive dome flushing from the open
vent gates
Low wind – This is the same as default except that active air flushing is employed as well to increase the
flow of ambient air over the mirror and telescope (is flushing more than just on/off?)
High wind – for high wind conditions when it is necessary to close down the vents to prevent excess dust
and wind shake. Skin cooling is on, the vent gates are closed and active flushing is used.
Night time – at night the skin cooling system is switched off and the internal air conditioning is switched
on. The air conditioning is set to try and match the ambient air temperature when the enclosure is opened
in the morning.
6. COMPLIANCE MATRIX
The matrix below shows how each of the requirements in the ATST TCS Design Requirements [1] is
addressed in the design.
No. Requirement Reference Comment

4.4-0001 Principal System 2.1
4.4-0002 Subsystems master 2.1, 3.1, 4.6
4.4-0003 Operating modes 5.6.2, [15]
4.4-0004 Logging 4.8
4.4-0005 Common Services 2.3
4.4-0006 Operational 4, [15]
Concepts
4.4-0007 Global Interlocks 3.2,0
4.4-0008 Availability 4.2
4.4-0009 Perform pointing 4.10.1.3,
map 5.7
4.4-0010 Persistence of data 3.2, Error!
Reference
source not
found.
4.4-0011 Scanning 4.12,[15]
4.4-0020 Time 3.3,
4.10.1.6
4.4-0021 Solar Ephemeris 4.10.3, [25]
4.4-0022 Open-loop pointing 5.6.2.1
4.4-0023 Closed-loop 5.6.2
pointing

4.4-0024 Pointing map 4.10.1.3

4.4-0025 Sky coverage 4.10.1
4.4-0026 Zenith blind spot 4.10.1.8,
4.16
4.4-0027 Tracking 4.10.2
4.4-0028 Coordinate systems 4.10.2
4.4-0029 Target 5.6.1
4.4-0030 Offsets 5.6.1
4.4-0040 Wavefront Control [15]
4.4-0041 Wavefronts to M1 [15], [8],
[10]
4.4-0042 Wavefronts to M2 [15], [7],
[10]
4.4-0043 Wavefronts to 5.6.2
MCS
4.4-0044 Wavefronts to [10], [11],
FOCS [15]
4.4-0050 M1 Temperature 5.9.3, [8]
forecast
4.4-0051 Temperature set 5.9, [3] The set point attribute names are specified in the
points individual subsystem ICD’s
4.4-0052 Thermal status 5.9.1
4.4-0053 Thermal overloads 5.9
4.4-0054 Thermal recovery 5.9
4.4-0055 Enclosure 5.9.4, [5]
ventilation
4.4-0056 Weather station 5.7
4.4-0060 Sequencing 4.6
subsystems
4.4-0061 Enclosure [5]
4.4-0062 Mount [9]
4.4-0063 M1 Mirror [8]
4.4-0064 M2 Mirror [7]
4.4-0065 Feed Optics [11]
4.4-0066 Wavefront [10]
4.4-0067 Acquisition and [12] Guiding requirement no longer needed (I thought I
Guiding saw a reference to this on Wiki but can’t now find
it)
4.4-0100 Command Should not be a problem given the reported ICE
acceptance performance
4.4-0101 Boot time Not expected to be a problem for a Linux PC
system but will need checking
4.4-0102 Apply offsets 4.10.1.6 Kernel will run at 20 Hz
4.4-0103 No contribution to 4.10.3
error budget
4.4-0104 Computer resources Not expected to be a problem on Pentium level
Linux PC
4.4-0110 Open-loop Meeting this requirement depends on hardware
performance

4.4-0111 Closed-loop Meeting this requirement depends on hardware

performance
4.4-0112 Sky coverage 4.10.1
4.4-0113 Zenith blind spot 4.10.1.8,
4.16
4.4-0114 Nasmyth rotation 4.10.1
error
4.4-0115 Coudé rotation 4.10.1
error
4.4-0116 Pointing rate 20 Hz 4.10.1.6
4.4-0117 Pointing timestamp [9], [5]
4.4-0120 No additional delay Event streams go direct from WCCS to subsystems
4.4-0130 M1 temperature 5.9.3
forecast
4.4-0131 Thermal overload 5.9
response
4.4-0140 Never block Dependent on ATSTCS implementation
subsystem
4.4-0141 Atomic commands See Subsystem ICDs
4.4-0200 Time master 3.3
4.4-0201 Global interlocks 0
4.4-0202 Control LAN ICE is implemented over TCP/IP
4.4-0210 Common Services 2.5
4.4-0211 Containers & 2.5, 4.6
Components
4.4-0212 Config ids [15]
4.4-0220 Subsystem 4.5
commands
4.4-0221 Events See ICDs
4.4-0222 Mount trajectory [9]
4.4-0223 Enclosure [5]
trajectory
4.4-0224 Wavefront data [7], [8], [9]
stream
4.4-0230 Configurations 4.1
4.4-0231 Sequencing 4.6
4.4-0232 Commands 4.5
4.4-0233 Events [15]
4.4-0234 Telescope motion [15]
4.4-0235 Telescope [15]
information
4.4-0236 OCS Interface [15]
4.4-0237 GIS Interface
4.4-0300 Compliance matrix 6 Tests and results are cross referenced in the
Acceptance Test Plan [3]
4.4-0301 Test software [3]
4.4-0302 Test plan [3]
4.4-0303 Engineering display 2.2, 4.6,
[24]

4.4-0310 Final design See this document

4.4-0311 Public Interfaces See ICDs listed in Section 8
4.4-0312 Operator’s manual To be provided with the delivered software
4.4-0320 Secure comms 2.2
4.4-0330 Operating systems 2.3
4.4-0331 Different 2.3
architecture
4.4-0340 Resource 2.2
consumption
4.4-0341 Change of Reliant on operation of ATST CS
subsystem state
4.4-0342 Reboot and restart 2.2
4.4-0350 Source code 2.3
4.4-0351 Source 2.3
documentation
4.4-0352 Revision repository 2.3
4.4-0360 Respond to global 0
interlock
4.4-0361 Generate global 0
interlock
7. ACKNOWLEDGEMENTS
(Usually put onto a new page after the paper is finished).
8. REFERENCES
[1] Goodrich, B., ATST Telescope Control System Design Requirements, SPEC-0019, Rev. 1.0
[2] Wampler, W. & Goodrich, B., ATST Software Design Document, SPEC-0014, Rev. 0.3
[3] Greer, A. & Mayer, C., ATST TCS Acceptance Test Plan, SPEC-xxxx, Rev. A
[4] Kneale, R., ATST Glossary and Acronym List, SPEC-0012, Rev. D1
[5] Goodrich, B. & Mayer, C.J., The Telescope Control System to Enclosure Control System
Interface, ICD 4.4 / 5.7, Rev 1.0
[6] Mayer, C.J., The Heat Stop Assembly to Telescope Control System Interface, ICD 1.3 / 4.4, Rev.
1.0
[7] Mayer, C.J., The M2 Control System to Telescope Control System Interface, ICD 1.4.4 / 4.4, Rev.
1.0
[8] Mayer C.J., The M1 Assembly to Telescope Control System Interface, ICD 1.2 / 4.4, Rev. B1
[9] Mayer, C.J. & Goodrich, B., The Telescope Mount Assembly to Telescope Control System
Interface, ICD 1.1 / 4.4, Rev. A3
[10] Terrett, D. L., The Wavefront Correction Control System to Telescope Control System
Interface, ICD 2.3 / 4.4, Rev. 1.0
[11] Terrett, D. L., The Feed Optics Control System to Telescope Control System Interface,
ICD 1.5.4 / 4.4, Rev. 1.0
[12] Terrett, D.L., The Acquisition and Guiding Control System to Telescope Control System
Interface, ICS 1.8.2 / 4.4, Rev. 1.0
[13] Mayer, C.J., Polarization Analysis and Calibration to Telescope Control System
Interface, ICD 3.1.1/4.4 Rev. 2.0

[14] Anon, The Telescope Control System to Global Interlock System Interface, ICD 4.4 /
x.x.x, Rev. 1.0
[15] Mayer, C., Terrett, D., & Wampler, S., The Observatory Control System to Telescope
Control System Interface, ICD 4.2 / 4.4, Rev. 1.0
[16] Goodrich, B., M1 Control System Design Requirements Document, SPEC-0007, Rev. A
[17] Fränz, M. & Harper, D. 2002, Heliospheric coordinate systems, Planetary and Space
Science, 50, 2, 217-233
[18] Hapgood, M.A. 1992, Space physics coordinate transformations: a user guide, Planetary
and Space Science (ISSN 0032-0633), 40, 5, 711-717
[19] Moisson, X. & Bretagnon, P. 2002, Analytical Planetary solution VSOP2000, Celestial
Mechanics and Dynamical Astronomy, 80, 3-4, 205-213
[20] Seidelmann, P.K. (ed) 1992, Explanatory Supplement to the Astronomical Almanac,
ISBN 0-935702-68-7
[21] Thompson, W.T. 2002, Standardized coordinate systems for solar image data, in
Advances in Space Research, 29, 12, 2093-2098.
[22] Wallace, P.T. 2002, A rigorous algorithm for telescope pointing, Advanced Telescope
and Instrumentation Control Software II. Edited by Lewis, H., Proceedings of the SPIE, 4848,
125
[23] Wampler, S., Goodrich, B., & Tvedt, J., ATST Common Services Software Design
Document, SPEC-0022, Rev. A
[24] Greer, A., Java Engineering Screens User Manual, SPEC-????, Rev. 3.0
[25] Wallace, P.T., ATST Control System: Pointing and Tracking, ATST/PTW/001
[26] Warner, M., Telescope Mount Assembly to Enclosure Interface, ICD 1.1.5.0, Draft

9. APPENDICES
9.1 CONTAINER MANAGER

This section provides details of the Container Manager that can be used to control the TCS and its internal
subsystem simulators. The implementation is not specific to the TCS and so could be used for other
systems.
9.1.1 Overview
The Container Manager is an application that provides a GUI for controlling component/controller
lifecycles. It can be used to control a single component, or an application containing multiple
components and controllers. It makes use of the application database service to obtain information about
the applications.
9.1.2 Description
The container manager has four tabs. The first tab, “ATST Control” is the main tab where an operator
can manage all of the running applications. The other three tabs allow information relating to new
applications to be entered into the database as easily as possible. The three data entry tabs are explained
below first.
- Add Host. This tab simply allows a new host to be entered into the database. There is a list
displayed showing all of the hosts currently contained in the database. Underneath this list there
are two text entry boxes, one for a new host name and the other for a description of the host if
required. To add a new host fill in the text boxes and click on the “Insert into App DB” button.
- Add Container. This tab is for entering information about new containers. The tab contains a list
that shows all of the containers currently contained within the database. Below this are several
text entry boxes and a drop down list. The first box is for entering the name of the container.
Below this is the class box, enter the class of the container here, or if it is a standard container
click on the small button next to it to fill in the value automatically. Below this is a drop-down
box that contains all of the available hosts. Select the host that the container manager will
attempt to start the container on. Enter a description if required and a display if required. The
display is used if an application uses a GUI, to ensure the graphical components are displayed on
the correct machine. To confirm the container and add it to the database click on the “Insert into
App DB” button.
- Add Component. This tab is used to enter information about components, including initialization
and startup attributes. The name, class and description can be entered through the text boxes.
The container can be selected from the drop down box. To enter a new initialization or startup
attribute enter the name and value in the two text entry boxes, and then click on the relevant
button with the arrow “Æ”. Once all attributes have been entered as required click on the “Insert
into App DB” button. This will add the component into the database.
9.1.3 ATST Application Control

The remainder of this section will cover the use of the main tab. The application control tab contains 8
information boxes and a container management panel. When first started the only registered container
will be the CM, which is the container manager’s container. You should never shut this down unless you
actually want to shut down the container manager.
To load a container, select the container from the drop down box in the container management panel and
then click on the “Deploy” button. The components will all be loaded, and the time taken to deploy a
container depends on how many components there are. Once complete the container will appear in the
registered containers information box. Left clicking on the container name in this box will display
container information, container status and give a list of components that can be started. Clicking on one

of the components in the list will display information relating to that component, the components status
and any initialization and startup parameters. Right clicking on the component will open an action menu,
allowing the component to be initialized, started up, shutdown, un-initialized and reloaded.
Right clicking on it can shut down a container. Select shutdown from the menu that appears.

TCS Software Design Description: Authors

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

TCS Software Design Description: Authors

Încărcat de

Drepturi de autor:

Formate disponibile

Project Documentation

TCS Software Design Description

Advanced Technology Solar Telescope 950 N. Cherry Avenue Tucson, AZ 85719

1. Date: 16th December 2004

2. Date: 9th May 2006

3. Date: 11th September 2006

SPEC-0021 Draft of Rev C Page i

SPEC-0021 Draft of Rev C Page ii

4.13.2 Change of track identifier......................................................................................... 44

SPEC-0021 Draft of Rev C Page iii of 71

The intended audiences of this document are:

The layout of this document is as follows:

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

SPEC-0021 Draft of Rev C Page 1 of 71

Slew – a discontinuous change in position or velocity demand from the TCS.

The role of the TCS in this system is to

SPEC-0021 Draft of Rev C Page 2 of 71

The remaining packages in the diagram constitute the TCS itself.

environment tpk subsys

Figure 1 Top level TCS packages

SPEC-0021 Draft of Rev C Page 3 of 71

2.2 DEPLOYMENT DIAGRAM

<< component >>

Event & Command channel

TCS Controller Weather server

<< component >> << component >>

Figure 2 TCS Deployment Diagram

SPEC-0021 Draft of Rev C Page 4 of 71

2.3 IMPLEMENTATION LANGUAGE

2.4 SOURCE CODE

SPEC-0021 Draft of Rev C Page 5 of 71

2.5 USE OF ATST COMMON SERVICES

3.1 Context diagram

SPEC-0021 Draft of Rev C Page 6 of 71

DHS OCS ICS

Configurations Configurations TCS

ACS Status ECS

PAC M1CS M2CS FOCS HSA

Figure 3 TCS Context diagram

3.2 EXTERNAL INTERFACES

Subsystem ICD Reference

SPEC-0021 Draft of Rev C Page 7 of 71

The interactions described above are covered by the following ICDs

System ICD Reference

3.3 TIME SYSTEM

SPEC-0021 Draft of Rev C Page 8 of 71

The class diagram for a configuration is shown below.

<< interface >> AttributeTable

Figure 4 Class diagram for configurations

SPEC-0021 Draft of Rev C Page 9 of 71

Figure 5 Configuration states

SPEC-0021 Draft of Rev C Page 10 of 71

SPEC-0021 Draft of Rev C Page 11 of 71

There are a number of ways to deal with this

4.3 THE DEVICE MODEL

4.4 THE CONTROLLER MODEL

SPEC-0021 Draft of Rev C Page 12 of 71

<< interface >>

<< interface >> << interface >> << interface >>

<< interface >>

<< realize >>

<< realize >> ActionCallback