The TJO – OAdM robotic observatory: the scheduler

The TJO – OAdM robotic observatory: the scheduler
Josep Colomé*a, Kevin Casteelsa, Ignasi Ribasa, Xavier Franciscoa
a
Institut de Ciències de l’Espai (IEEC – CSIC)
ABSTRACT
The Joan Oró Telescope at the Montsec Astronomical Observatory (TJO – OAdM) is a small-class observatory working
under completely unattended control, due to the isolation of the site. Robotic operation is mandatory for its routine use.
The level of robotization of an observatory is given by its reliability in responding to environment changes and by the
required human interaction due to possible alarms. These two points establish a level of human attendance to ensure low
risk at any time. But there is another key point when deciding how the system performs as a robot: the capability to adapt
the scheduled observation to actual conditions. The scheduler represents a fundamental element to fully achieve an
intelligent response at any time. Its main task is the mid- and short-term time optimization and it has a direct effect on
the scientific return achieved by the observatory. We present a description of the scheduler developed for the TJO –
OAdM, which is separated in two parts. Firstly, a pre-scheduler that makes a temporary selection of objects from the
available projects according to their possibility of observation. This process is carried out before the beginning of the
night following different selection criteria. Secondly, a dynamic scheduler that is executed any time a target observation
is complete and a new one must be scheduled. The latter enables the selection of the best target in real time according to
actual environment conditions and the set of priorities.
Keywords: robotic observatory, telescope control system, unattended operation, software, scheduler
1. INTRODUCTION
The TJO – OAdM is a small-class observatory working under completely unattended control. It is located at an altitude
of 1570 m in the Montsec mountain range, 50 km south of the central Pyrenees and 50 km north of the city of Lleida
(Catalonia, Spain). It is endowed with a 0.8 m telescope, a classical 6.15 m dome, and a 2k × 2k back illuminated CCD
camera. It is also equipped with a set of sensors and support devices to continuously monitor the environment and the
system response. All this instrumentation is fully automated.
1
The observatory was designed to achieve a high level of robotic control. The latter is given by a reliable response to
environment changes and by low human interaction to control any routine process or possible alarms. These two points
establish the level of human attendance to ensure low risk at any time. Human attendance diminishes as robotization
level increases, and that includes all the processes involved in observatory operations. The logical and physical
architecture was designed and implemented to provide the capability of an automatic response to any triggered event. For
a detailed description of the architecture and the other important packages involved in the system control, we refer the
reader to the referenced documents1, 2.
The scheduler represents a fundamental element to fully achieve an intelligent response at any time. Its main task is the
mid- and short-term time optimization and it has a direct effect on the scientific return achieved by the observatory. In
the following sections we present a description of the scheduler developed for the TJO – OAdM as well as the most
important related packages.
2. GENERAL SCHEDULER DESIGN
Scheduling is a task allocation issue, where the execution is conditioned by one or more constraints. Research in this
field began in the mid-50s and has been developed in multiple areas3 given the horizontal nature of the applications. The
classic problem of scheduling is the job-shop problem (JSP), where N ideal tasks must be assigned to M identical
resources (machines, processors, etc.), while minimizing the total execution time.
* [email protected]
Studies on dynamic scheduling have been done in the recent years4. This case computes the best planning process while
introducing new tasks or new constraints and / or a change in the status of the initial constraints. In most cases there is no
single best approach to solve the planning system and, therefore, various mathematical algorithms should be considered5.
Astronomical observations require specific conditions for each particular case, such as the instrument to use, the sky
visibility or brightness conditions, the best time for the observation, etc. All this information, together with the scientific
objectives, is included in the proposals that astronomers submit to the observatories, for observation time requesting. A
priority is assigned to the approved proposals and this is used to select one of them in case other proposals could overlap
in time. Observations of the proposals must be scheduled for execution under the specified conditions, once accepted and
prioritized. This programming is carried out by the scheduler6, 7, this being a person skilled in the sorting criteria to
apply, an automatic system based on the use of computer algorithms or a combination of both.
Proposal scheduling for astronomical observations is an example of multi-objective problem, since different factors must
be optimized: to maximize the scientific return, minimize the time between executions, tune the exposure time for each
observation in terms of environmental conditions, etc. The solution to this problem is of inherent computational
complexity: the number of solutions grows exponentially with the number of targets and there is no algorithm that can
avoid the implicit or explicit enumeration of all solutions. Best scheduling of astronomical observations is included
within the class of problems NP-hard. There are many mathematical tools to solve the scheduling issue: from simple
heuristics to more complex genetic algorithms or neural networks. A.I.Gómez et al.8 published a good description of the
problem and possible solutions. A different approach to solving the problem is given by T.Granzer9, who analyzes
various solutions to use in robotic observatories. The advantages of using a dispatcher algorithm, based on the
calculation of the merit function for each observation, are presented in comparison with queue or optimal scheduling.
Dispatch scheduling is the one chosen to be used at the TJO – OAdM observatory for the short-term scheduling needs, as
described in section 6.
2.1 Scheduler features
The scheduler developed for the TJO – OAdM observatory has the following general features:
Scheduling cycle: long, mid and short term
Three scheduling levels are considered at the TJO – OAdM: long, mid and short term, the latter being responsible for the
dynamic response of the system. The problem to be solved by the scheduler can consist of thousands of observations per
cycle, although not all objects are visible at all times. The long-term planning defines the engineering tasks (maintenance
and calibration) and the selection of proposals for the entire cycle (six months), based on factors such as visibility above
the horizon or the moon phase, to compile the list of feasible operations to be executed. Oversubscription is permitted for
the full cycle in order to ensure the complete use of available time. We plan to develop a long-term scheduler to be
executed on simulation mode by the observatory staff and the TAC, although it is currently being performed by an expert
user that takes into consideration the TAC approved proposals and the observatory maintenance plan.
The mid-term scheduler selects the proposals suitable to be observed on the following night and it also performs an
ordered list of observation blocks, using queue scheduling algorithms.
The short-term or dynamic scheduler selects the next best candidate to be observed in almost real time. For a short-term
planning proposals are divided into blocks of observation (the sum of them complete the entire proposal) to be executed
during the actual night. The selection of an observation depends on external factors specified in the submitted proposal,
and it is the scheduler who decides the best observation based on immediate factors. Not all observations are executed
during the planned cycle as a consequence of using dynamic scheduling. The probability of a project to be carried out
depends on its scientific priority, but also the conditions for execution. Such priority may vary over time; it may be
greater as the conditions for observation become unfavorable.
An extended description of the mid- and short-term scheduling implemented is given in the next sections.
Fully integration of the scheduler in the general observatory control system
The nominal working flow of the TJO – OAdM control system1,2 implies processes with human intervention (submission
of proposals, proposal revision and verification, and data retrieval), and unattended ones. The unattended observation
operation includes: observatory startup and power down routines; selection of targets (described in this document);
hardware control for telescope, instrumentation and dome; data processing and storage; and, finally, housekeeping,
hardware and software application monitoring and control. Several software applications perform most of these
instrument and data flow control operations at the observatory. OpenROCS2 is the one that takes the role of the software
infrastructure and it also controls all the necessary routines that implement responses to identified events and alarms, as
well as all the applications running at the TJO – OAdM observatory. The software applications and OpenROCS compose
a software suite designed to reach the complete robotization of the observatory. The scheduler is integrated in this suite
and its routines are called every time their action trigger appears, according to the data flow management performed by
the OpenROCS software.
A particular software application, the proposal management tool, executes the storage in the database of all the proposal
constraints regarding the observation pattern definition and the results of the observations acquired (reduction, analysis
and quality control results, implemented in the data processing). It was designed and implemented in order to optimize
the execution of the scheduler selection algorithms, as can be seen in the following section.
Planning modes: manual, automatic and simulation
The optimal use of mid- and short-term schedulers is usually obtained when combined with unattended operation. Thus,
the sequence of tasks can toggle between observations of various proposals without the prejudice it would represent for
the astronomer if he/she was at the observatory. Under unattended control, dynamic schedulers maximize the efficiency
as the system response is faster and more standardized, optimizing the use of time of the observatory. Many robotic
observatories do not incorporate this feature in the control system and run a static sequence of observations, which is
aborted, but not modified, when environmental conditions change or there are errors in the system control. In this
scheme, a variable priority policy is not applied and this does not optimize the scientific return of the instrument. Two
examples of observatories that do apply dynamic schedulers are the Liverpool Telescope10 and the observatory
STELLA9. Mid- and short-term at the TJO – OAdM are also executed automatically and are included in the observation
manager module of the OpenROCS software suite. The use of dynamic schedulers opens also the possibility of
integrating the observatory into telescope networks, such as the Heterogeneous Telescope Network11, which will be
explored in the near future.
Simulation mode is also provided to users in order to check the observation patterns of their proposal, to compute the
required exposure time and evaluate its feasibility before submitting it to the observatory TAC.
Different observation types considered
The scheduler accommodates observations with a fixed starting time, as well as monitoring or periodic observations. It
also takes into account the observation of unexpected phenomena that can alter the short-term planning. The different
observation types considered are listed here:
Generic targets are those that can only be described in terms of astronomical characteristics or general location on the
sky. Separate targets should be defined and listed if the user plans to acquire observations at several locations within an
extended object. A generic target must be specified with its Equatorial coordinates. A Fixed target can be specified by its
name and coordinates, according to the catalogued values.
Time-Critical or Phase-Critical Observations: proposals may request that TJO – OAdM observations be made at a
specific date and time or phase, or within a range of specific dates or phases, when scientifically justified. Some
examples of such cases are: astrometric observations, observing specific phases of periodic variable stars, monitoring
programs, observations coordinated with observations by another observatory.
Special Calibration Observations: data from TJO – OAdM observations are normally provided to the Principal
Investigator (PI) after full calibration (raw images and master calibration frames are also supplied in case the PI
expresses the need to repeat the process). Baseline calibrations include bias, long exposure darks and flat images taken at
the beginning and at the end of the night. A set of standard stars is also observed on those nights in which a target that
requires such calibrations is likely to be scheduled. Projects may need to include special calibration observations if the
calibration requirements of the project are not addressed by the standard calibration program. A number of bias or dark
images can be specified for each observation and they will be taken just before or after the science image. And in case
predefined standard stars do not suit the user needs, different targets can be included as a proposal target. Any special
calibration observations required must be included in the total request for observing time, and must be justified
explicitly.
Observing time distribution based on the use of Observation Blocks and Target Groups
TJO – OAdM observing time is counted in terms of Observation Blocks (OBs). Each OB contains a series of one or
more exposures on a target, using the same or a different filter and following a defined sequence pattern. OBs are
grouped into larger units called Target Groups (TGs) that include all the OBs for a specific target according to the
number of iterations and the scheduling requirements. A specific target can have several TGs. Finally, a whole project is
composed of the sum of TGs for all targets in the proposal.
The processes in a target OB contain the following components: telescope pointing; dome pointing; target science
exposures; instrument overheads (i.e., the time required to read out the data); special calibration observations, which may
be required if the accuracy provided by the standard calibrations is inadequate for the goals of the project, etc.
OBs can be executed more than once towards the achievement of planned scientific objectives.
2.2 Block diagram
The scheduler package is integrated in the main data flow scheme (see Fig. 1), and needs to interact with several modules
in order to give a correct response any time it must compute a new planning.
Figure 1. Data flow at the TJO – OAdM
Once a user has entered the observation details in the database, through the web-based interface, and the observatory
staff has validated the data, the scheduler takes these data into consideration when selecting the targets suitable to be
observed during the coming night or when selecting the best target for the next image acquisition. The first process is
performed by the mid-term scheduler routine, whereas the second one is done by the short-term or dynamic scheduler.
Both mid- and short-term schedulers are described in the following sections.
The next step after the target selection is the execution of the observation process, which ends with the image processing
routines and the quality control. The latter decides whether the observation must be rescheduled or is deemed complete,
and updates the database accordingly.
Proposal and observation management, from the proposal submission to the data retrieval to user, including the scheduler
routines, compose the optimal set-up to achieve the unattended control optimization.
3. PROPOSAL MANAGEMENT
A description of how the system does the proposal management is given here: program preparation, databases, proposal
submission, etc. Several concepts used are inspired from other projects with advanced tools for similar purposes12, 13.
3.1 Program preparation
The following steps must be taken into account to calculate the resources required:
1. Define the pattern for an OB (instrument setup, number of exposures, exposure times, etc.) to execute on a
target
2. Define the number of iterations and the scheduling requirements for each OB
3. Repeat steps 1 and 2 for each target or for the same target if different OBs are required
4. Compute the time required for target acquisitions and instrument overheads
3.2 User interface for proposal submission and data retrieval
The only tool for the users to interact with the observatory is via a high-level software interface providing ways to access
the database. A web-based proposal management tool through which the users can propose their science programs (phase
1), prepare the observations if the program is approved (phase 2) and retrieve their data products upon successful
observation (phase 3) was designed and partially implemented. A short description is given below.
3.2.1 Users and calls for proposals
Scientists from research institutions around the world can submit a proposal to the TJO – OAdM's Time Allocation
Committee (TAC). There are biannual calls for proposals, which go out in March and September, four months before the
start of the semester in which the observations are to be taken. The TJO – OAdM semester dates are: 1st February to 31st
July (semester A) and 1st August to 31st January (semester B).
3.2.2 Phases for new proposal submission
A new proposal is submitted in two phases. In Phase 1, the proposers submit a scientific justification and observation
summary for peer review. The Telescope Allocation Committee (TAC) recommends a list of programs with associated
priorities to the TJO – OAdM observatory for preliminary approval and implementation. In Phase 2, investigators with
approved Phase 1 proposals must provide complete details of the observations in their proposed observing program. This
allows the TJO – OAdM to conduct a technical feasibility review, and to schedule and obtain the actual observations.
Programs are not approved fully until after submission of an acceptable Phase 2 program.
After submitting the proposal, the PI receives the automatically created proposal code and password. Using them, he/she
can access a specific web page which includes the information sent at this first phase and the submission status. The
proposer can use this page to track the evolution of the proposal (TAC considerations, Phase 2 data, etc.) and to access
the data and the images obtained. All this information is stored in the observatory database. This proposal web page is
accessed through the Status and Results section of the observatory web page.
Diagrams of the phase 1 and 2 roadmap submissions are shown in figures 2 and 3.
Phase1
A high level step-by-step guide to the Phase 1 proposal is explained below:
1.
Review the observatory constraints to determine if your observations are feasible (pointing constraints,
bright object constraints, etc.).
2.
Determine the required observing conditions to obtain the expected data precision. Sky brightness, seeing
and photometric conditions must be specified.
3.
Determine the observation type.
4.
Determine any observation constraints that could impact scheduling: flexible or observations that can be
carried out at any time during the semester when the conditions are appropriate; monitoring or observations
of an object required at a regular interval; fixed or observations only to be carried out at a specified time;
and, ephemeris or observation of a target at a particular phase of its periodic cycle.
5.
Determine the required exposure times to complete the observations for the proposal, taking into account
the following aspects: pointing and tracking performance of the TJO – OAdM; time required calculation,
using the TJO - OAdM exposure time calculator to determine the exposure time of each target and adding
the system overheads (acquisition time, time taken to slew the telescope and dome on target; readout time;
time to take special calibration images).
6.
Fill in the proposal information using the web page interface: general information, investigators, source
data (targets), observing conditions and observing time request.
7.
Submit the proposal.
Phase2
Phase 2 and a final revision by the TJO – OAdM staff is the last step before delivering the proposal data to the TJO –
OAdM scheduler system. Phase 2 is a transformation of an accepted Phase 1 proposal into a list of observations with the
detailed information needed for implementation and scheduling of the science program. Once submitted, the Phase 2
process follows the scheme shown in Fig. 3. The phase completion requires the fulfillment of Phase 2 proposal form,
using the user web page interface, according to the steps described below:
1.
2.
Fill in the remaining proposal information and the general observation constraints.
Define the observation strategy (or TG) for each target. A new TG code is generated every time a target is
selected. More than one strategy is possible for the same target, just selecting it again. A whole project is finally
composed of the sum of TGs for all targets in the proposal. Next steps specify a single TG:
a) Select a target from the list of objects submitted in Phase 1.
b) Select the instrument.
c) Define the list of observations included in the OB: it creates pattern specifications for the target
observation. It must include the following information for each entry: exposure, time, filter, binning,
repeats (number of exposures), and priority (to prioritize inside the same OB). A set like that shall be added
a non-limited number of times to complete all the required setups to fulfill the observations required. Once
the OB is completed the user must specify if it must be executed as a Non-interruptible Sequence OB,
which implies observations included in an OB must be done without gaps between them. Gaps between
exposures may still be necessary to allow time for activities which are necessary to set up for the next
exposure, such as readouts and reconfigurations.
d) Define the number of iterations: times the OB must be done.
e) Calibration images: the need of standard stars for absolute photometry must be also pointed out, in order to
include this requirement as a scheduling constraint. Extra bias and darks images are permitted. The number
of required images must be specified, and also the exposure time for the dark ones.
f) Priority: it compares the TG to prioritize inside the same proposal.
g) Define the scheduling requirements: no constraints, no scheduling constraints on the OB; between, range of
dates or phases that all exposures defined in the OB must be observed within (multiple Betweens are
possible); after observation by, any timing or phase requirements between OB and intended to capture
repeated visits with spacing of multiple minutes, hours, days or greater.
3. Define links with other TG to identify which TG must be scheduled if the current one is scheduled too. The
possible ways to do it are: non-Interruptible Sequence TG, once started it must continue until the last one is
done; after observation by, enter any timing requirements between TGs (during the same night, time interval);
no constraints.
Figure 2. Phase 1 scheme.
Figure 3. Phase 2 scheme.
3.2.3 Proposal validation
The observation data are validated by the observatory staff before being considered by the mid-term scheduler routine.
Validation includes the revision of the total time needed to perform all the TGs and other observation constraints defined
during the second submission phase that must agree with the proposal characteristics approved by the TAC.
3.2.4 Proposal data retrieval
All science and calibration data, as well as all the proposal related information, are placed in the TJO – OAdM database
and accessible through the observatory web page. Science data become immediately available to the proposal PI (Phase
3), who is notified automatically by e-mail. On average, the science data from TJO – OAdM flow through the production
pipeline and into the database within one day after observation by the telescope.
3.3 Proposal related data: storage in the observatory database
The TJO – OAdM database (DB) is structured using the relational model and is based on MySQL. Different levels are
defined according to the global control design and the specific applications that interact with each one. They are sorted
from high (Proposal and Project) to low (Selection and Observation) level of human interaction:
Proposal: it contains the general information of the proposal entered at the submission of Phase 1. Information
to be included: proposal identifier, PI data, list of targets and scientific justification, date of submission,
acceptance and finalization, and status. New entries are generated through the web user interface, a proposal
identifier is automatically created, the acceptance date is updated manually after the submission to the
observatory TAC and the date of finalization and status is updated automatically by the observatory control
system.
Project: specific information of the proposal entered at the submission of Phase 2 is entered on this level
through the web-based interface. It includes the detailed list of TGs and OBs and the number of present
successful observations. The latter is automatically updated by the observation manager, as described in the
following section.
Selection: table composed of a temporary list of targets extracted from the Project level according to their
possibility of observation following defined criteria (positive height above horizon at some point during the
night, night date included in the defined observation window, moon brightness fulfilling user requirements,
etc.). This list is generated by the mid-term scheduler application and is used as input information for the shortterm scheduler, the last step of the scheduling process.
Observation: the last level contains the entries generated by the application that manages Data Processing,
executed after each new observation. There is an entry per observation that includes: target identifiers, date and
time of observation, calibration and analysis status, storage directory and filenames, image quality report (file,
photometry, etc.), error flags and image quality code. This table is used for the observation manager to update
the level of a proposal completion and the status of each TG in the Proposal and Project levels, respectively.
A project is finished when the number of successful observations is equal to the number of the required iterations. When
all the projects included at the same proposal are executed, the proposal is considered as closed and a notification is
automatically sent to the proposal PI.
Several applications interact with the DB. In order to minimize errors while updating stored data, two mirrored DBs are
installed in on-site and off-site server computers. The on-site DB is only updated by the control system, whereas the offsite one is the only accessible by users for proposal submission and data retrieval. The detailed description of this logical
architecture is given in the referenced documents1, 2.
3.4 Proposal tool implementation
A web-based submission tool is implemented and running. It can be accessed through the observatory web page. It is
programmed using PHP, AJAX and MySQL queries for database interaction.
4. OBSERVATION MANAGER
The observation manager is the responsible for performing all the tasks related to scheduling and involved in the
observation process. It is invoked by two different applications (OpenROCS Events and Data Processing) and it executes
the automatic scheduler routines and the database update when necessary.
4.1 OpenROCS Events
The OpenROCS software manages the events generated by the system, including those controlling the routine
operations. Two of these event cases trigger the execution of the mid- and short-term schedulers. The first one is the
sunset time that is used as a reference to start several initialization processes. Actions triggered by this event are:
hardware initialization (telescope, dome and CCD), routine to register a set of calibration images and pre-selection of
science targets, performed by the mid-term scheduler. The event that triggers the execution of the short-term scheduler is
the end of an image acquisition, and starts the selection of the next observation (science target or calibration frame).
4.2 Data processing and database update
Data processing is executed any time a new image is acquired and the main purpose of the routine is reduction and
analysis of the image (based on the ICAT pipeline14) for photometric and astrometric data extraction, image quality
control, data archiving, final image storage and database registry (Observation level). The image quality control process
executes an evaluation of four different aspects for each image file: file quality (size, header keywords), image
photometric quality (star shape, instrumental magnitude, median FWHM), image astrometric quality (coordinate
solutions and pointing errors), observation pattern (fulfillment of user constraints) and environment quality (weather and
system conditions). Each one of the steps described is summarized in one digit and all together provide a four digit
binary code that is included in the image header as an image quality descriptor keyword. This code is then used for the
observation manager to modify the database, increasing the number of successful observations associated to the proposal
TG and updating the proposal completion level. If the image quality is not sufficient, image data are also stored in the
database, but the proposal information is not changed. The latter makes the scheduler routines take the proposal TG
again into consideration when computing the best observation.
5. MID-TERM SCHEDULER
The mid-term scheduler or pre-scheduler is responsible for selecting the TGs suitable for observation and also for
planning night observations before the night begins.
5.1 Pre-scheduler: selection criteria
The MySQL database (Project table) contains all TGs split in OBs, including both completed and pending ones. Those
TGs that have not been completed are selected by the pre-scheduler (see Fig. 4) and the rest are skipped. The calibration
frames are organized into a single proposal with three TGs, one for each image type (darks, bias, and flats in each filter).
This proposal is always active and defines the standard set of calibration images to acquire at the beginning and end of
the night. Additional calibration frames required by a particular proposal are treated in a different manner, as they are
considered together with the associated science targets of that proposal. Science targets are organized into individual
TGs based on project and OB definition (filter, exposure time, number of repetitions, etc.). Targets having fixed
observing times that fall between sunset and sunrise are selected by the pre-scheduler, as well as all the Flexible targets
(regardless of their visibility). Once selected, the list of targets is sorted to have a static queue that can be used any time
if the dynamic scheduler cannot be executed.
Figure 4. Interaction between the database (DB), the scheduler routines and the OpenROCS software.
5.2 Queue scheduling sorting factors and process
In order to compute the queue schedule above mentioned, the pre-scheduler applies several sorting criteria. Observation
window is the first computed parameter for the selection of TGs. Two different scenarios are considered:
Targets with fixed starting times are programmed first and checks are performed to see if they have the required
altitude and do not conflict with other fixed targets with the same priority. If there are conflicts, the first
programmed target is given priority and the conflicting target discarded.
Next, targets with flexible starting times fill in the gaps between the fixed targets. This part of the script starts at
the starting time (sunset) and steps up in 1 minute intervals, determining if any targets can be observed at the
given time and if they fit in the gaps between fixed targets. There are 10 priority levels and targets in level 10
are considered first.
This window must be computed for those proposals that require monitoring programs, based on time or phase intervals.
Airmass is another sorting factor. The altitude of each target is calculated at the current time step and at the end of its
observation period. The target is considered to be setting if the starting altitude is higher than the setting altitude. Thus,
targets which are setting at the beginning of the night are programmed first. Targets which are rising at the beginning of
the night are considered setting when they straddle their maximum altitude (because their setting altitude is just below
their rising altitude). Thus by considering setting targets first, most of the targets are programmed at their optimal
altitudes.
Next, the distance between the moon and the target is calculated and a determination of sky brightness is done based on
lunar phase and altitude. A decision whether to consider the target is made based on its altitude, lunar distance and sky
brightness compared to the user-defined requirements.
Once a target is considered, an attempt is made to insert it into the gaps between the already programmed observations. If
it is inserted successfully, the pre-scheduler goes on with the next target. If it cannot be inserted at the given time, an
attempt is made on all consecutive time steps while the user defined observing requirements are still met. If the current
time steps up to sunrise and the target still cannot be included, it is discarded.
After all the targets have been considered and the night observing list has been determined, a file containing the
observation sequence is generated fulfilling the TALON standard format and it is used to guide the unattended operation.
If there is enough time remaining before the start of the first target, the calibration images are programmed first. The
science targets are programmed next, followed by another round of calibration images at the end of the night.
5.3 Implementation at TJO
The pre-scheduler action is triggered by an OpenROCS event (a predefined time before sunset). The action consists of
three basic steps executed by the Python based pre-scheduler script (scheduler.py). The first step is reading the MySQL
database. The second step is the target selection and the queue scheduling computation. A second Python routine,
containing various astronomical and time-keeping calculations (astrocalc.py), is called many times by the pre-scheduler
routine to do various calculations. Finally, once the target list has been created, the pre-scheduler routine calls the
slsMaker2.3.c, the program that creates the telrun.sls file needed by TALON to execute the night observations in batch
mode. After the pre-scheduler has finished, OpenROCS detects a new telrun.sls has been created and proceeds to execute
the night observations.
6. SHORT-TERM SCHEDULER
6.1 Dynamic scheduler algorithm: dispatcher
The approach chosen to solve the dynamic selection of the observation to schedule is the use of a dispatcher6. This shortterm scheduling is executed each time a target observation is over and a new one must be scheduled. It is done in real
time according to current environment and user defined conditions. The application uses the observation list created by
the pre-scheduler as input information and executes an algorithm that calculates the figure-of-merit of each object. The
object with the highest merit value is then scheduled. A general definition of a merit function is:
where fi(t) functions and their associated weight describe the different effects that contribute to increase or reduce the
global merit m(t) per object. Among these effects, we consider:
Observation conditions: height above the horizon, moon brightness and distance from the moon, best
observation time in case observation is required not at the meridian crossing, required period between iterations,
distance from previous target, proposal priority.
Environment conditions: seeing, photometric quality.
Proposal history: term to ensure a balance between the observation time spent with different proposals that have
the same priority.
6.2 Sorting factors
The sorting factors used by the dispatch scheduler are very similar to those described in section 5.2 for the pre-scheduler,
with the addition of those factors that depend on the current observation conditions: seeing and photometric sky quality.
The current seeing is determined from two inputs: the on-image seeing determined from the mean FWHM of stars in the
previous images, and the direct seeing measurements obtained from the Robotic Differential Image Motion Monitor
(RoboDIMM15) located in the observatory. On the other hand, the on-the-fly data processing described in section 4.2
gives a determination of the current photometric sky quality for the previous images. The seeing and the photometric sky
quality values are compared with the user's requirements and a decision is made regarding whether to observe the target.
Targets that require very good seeing and/or photometric sky quality will be given higher priority when these measured
values fulfill the requirement.
6.3 Implementation at TJO
At the present time the short-term scheduling is handled by the same queue scheduling routine used by the pre-scheduler.
If for any reason the observations are interrupted throughout the night (due to weather, power cuts, etc.), the queue
scheduler routine can be called when OpenROCS determines that conditions are right to resume observations. The
MySQL database is then consulted and the rest of the night is planned based on the selection and sorting criteria
explained in section 5. This works fine at present, but has important limitations: it is time consuming to compute a new
schedule and the process does not take into account present seeing and photometric quality. Currently, the dynamic
dispatch scheduler is under development and will be implemented in the near future.
7. CONCLUSIONS
We have described the observation management performed at the TJO – OAdM through two main software packages:
the proposal management tool and the observation manager. Other applications strongly linked to the observatory task
planning have been briefly described: the OpenROCS control system, the data processing routine and the database. All
these software tools implement the necessary structure to have a correct system behavior when scheduling the tasks to
perform.
Both the mid- and short-term schedulers used, which are key elements of the observation manager package, have also
been described. The observatory is currently working with a simple queue scheduler for the dynamic response, which is
not the optimal solution. The observatory will start offering observation time to the international community in the
coming months and the number of submitted proposals can potentially grow fast. In this situation, the use of a queue
scheduler would represent a big drawback. Because of that, efforts towards the implementation of a dispatch scheduler
are ongoing.
Acknowledgments: We wish to thank all those who have contributed to the development of this project. The OAdM16
project is supported by the Catalan government and owned by its local official institution: the Consorci del Montsec.
Research institutes and universities have actively contributed with scientific and technical supervision and manpower to
the development of the project: the Institute for Space Studies of Catalonia (IEEC), the University of Barcelona (UB),
the Technical University of Catalonia (UPC), the Spanish Research Council (CSIC) and the Joan Oró Foundation (FJO).
REFERENCES
[1] Colomé, J., Ribas, I., Fernández, D., Francisco, X., Isern, J., Palau, X. and Torra, J., "OAdM robotic observatory:
solutions for an unattended small-class observatory," Proc. SPIE 7019, 70192K-1 - 70192K-12 (2008).
[2] Colomé, J., Francisco, X., Ribas, I., “The TJO – OAdM robotic observatory: the OpenROCS system and the dome
control”, Proc.SPIE, in press (2010)
[3] Verderame, P.M. et al.: “Planning and Scheduling under Uncertainty: A Review Across Multiple Sectors”,
Ind.Eng.Chem.Res., vol.49, p.3993-4017 (2010)
[4] Mora, M. et al.: “A survey on the dynamic scheduling problem in astronomical observations”,
https://csrg.inf.utfsm.cl/twiki4/pub/ACS/SchedulingPaperIfipai/mmora-msolar.pdf
[5] Pinedo, M.: “Scheduling: Theory, Algorithms, and Systems”, Prentice Hall, Englewood Cliffs (NJ); ISBN:
0137067577 (1995)
[6] Swanson, K., Bresina, J., and Drummond, M.: “Robust Telescope Scheduling”, Proc. In i-SATRAS 94 (1994)
[7] Johnston, M.D.: “Spike: AI scheduling for NASA's Hubble Space Telescope,” Sixth Conference on Artificial
Intelligence Applications, v.1, p.184-190 (1990)
[8] Gómez de Castro, A.I., Yáñez, J.: “Optimization of telescope scheduling: Algorithmic research and scientific policy”,
Astronomy & Astrophysics, v.403, p.357 – 367 (2003)
[9] Granzer, T.: “What makes and automated telescope robotic?”, AN, v.325, n.6-8, p.513-518 (2004)
[10] Fraser, S.N., Steele, I.A.: “Robotic telescope scheduling: The Liverpool Telescope experience”, Proc. SPIE, v.5493,
p.331-340 (2004)
[11] HTN: http://www.telescope-networks.org/wiki/index.php/Main_Page
[12] Liverpool Telescope: http://telescope.livjm.ac.uk/Info/PropInst/
[13] HST: http://www.stsci.edu/hst/proposing/docs/proposingOverview
[14] Colomé, J., Ribas, I., “ICAT: a General Purpose Image Reduction and Analysis Tool for Robotic Observatories”,
Astronomical Data Management, 26th meeting of the IAU, Special Session 6, (2006), SPS6, #11
[15] Aceituno, J.: “A new Robotic DIMM for Calar Alto Observatory”, CAHA Newsletter 04b, (2004)
[16] OAdM: http://www.oadm.cat