STO Automatic Observation Strategy
Table of Contents
STO Automatic Observation Strategy ............................................................................................ 1
0
Document Version Control ..................................................................................................... 1
1
Scope ....................................................................................................................................... 1
2
Design ..................................................................................................................................... 2
2.1 Problem Definition ........................................................................................................... 2
2.2 Types of Observing Programs .......................................................................................... 3
3
Baseline Mission Observing Program .................................................................................... 3
4
Automated Observing Program Implementation .................................................................... 4
4.1 Implemented Observing types .......................................................................................... 4
4.2 Observing Table Definition .............................................................................................. 5
4.3 Observing Table Upload and Modification ...................................................................... 8
4.4 Reference Observations Table Definition ........................................................................ 9
4.5 Algorithm to determine which observation to do next ................................................... 10
0 Document Version Control
Revision #
0
1
2
3
Date
6/01/11
6/15/11
8/04/11
6/19/15
Issued by
Pietro Bernasconi
Pietro Bernasconi
Pietro Bernasconi
Pietro Bernasconi
Description
Document generation
Revision 1
Revision 2
Updated section 4.3
1 Scope
This document describes the implementation of the Observation schedule into the Autonomous
Control Executive (ACE) code.
2 Design
2.1 Problem Definition
The STO automated observing program needs to be able to conduct all the STO observations to
meet the science goals in an automated way, virtually without intervention from the ground.
This automated requirement is dictated by two conditions:
1. The uplink telemetry when the payload is beyond the line-of-sight (LOS) region is
considerably lower than when the payload is within LOS. It will allow uploading a series
of commands only about once every 15 minutes.
2. There will be a considerable time lapse between the time the commands are sent and
when they are received by the gondola. This time lapse is on the order of several
seconds. Finally dropouts in telemetry can be expected. This problem is particularly
serious if the payload drifts close to the South Pole above 85 degrees latitude S.
Hence the need for on-board the Command and Control System to operate autonomously without
constant human intervention.
To develop an automated program there are a number of issues that the code/algorithm needs to
be able to solve independently:
1. Not all the defined targets are visible at any given time during the flight. The constraints
for observability of a certain target are the following:
a. The target must lie within > 0 deg and < 58 degrees in elevation
b. The target must not be within 20 degrees of the Sun
The automated algorithm therefore must determine if a target is visible before observing
it.
2. Certain targets are within the above mentioned observability constraints only for a certain
period of time during the mission. For example a target may not be visible at the
beginning of the mission but 1 or two weeks into the mission it becomes observable.
3. The exact launch date is not determinable until the payload is actually launched.
Depending on points 1 and 2 above the observing schedule needs to be flexible enough to
allow an optimal observing strategy independent of when the payload is launched.
4. Certain targets have higher priority than others and therefore observed before others.
Always within the observability constrains.
5. Some fault protection mechanisms may trigger the temporary interruption of the
observing sequence, which will be resumed as soon as the fault was solved. This must
happen completely autonomously. For example the instrument may be observing a target
that is located in the sky such that the solar arrays can not provide 100% of the needed
power to operate the gondola. In this case when the battery capacity is depleted below a
threshold level the gondola fault protection system will command to interrupt the
observations and change the azimuth in such a way that positive power margin is
achieved. In such situation the automated observing program needs to be able to switch
target so that the new target enables a gondola attitude such that positive power margin is
maintained.
Additionally, the automated observing program must allow to be modified from the ground on a
regular basis. This is to accommodate unplanned changes in instrument performance, or changes
in science priority while the mission is flying.
2.2 Types of Observing Programs
There are two main modes of observation that will allow accomplish the scientific objectives
2.2.1 On-The Fly mapping (OTF)
This technique consist of performing with the telescope a drift scan of a region of the sky at a
constant drift rate while the spectrometer continuously takes spectra (as well as calibration
measurements). At the beginning and the end of the scan reference spectra are taken in “empty”
regions of the sky nearby.
To create a 2D map the scanning is repeated several times with every new scan offset by some
amount (0.5 to 1 times the beam width) thus covering a 2D region in the sky.
2.2.2 Position-Switching (PS)
The position-switching technique consists in taking spectra at a specific point source in the sky
and then shifting the field of view by some amount (typically 0.5 to 1 degree off source) and take
off source (reference) spectra. This on-source-off-source switching can be repeated several
times.
3 Baseline Mission Observing Program
The following is a possible baseline observing program as presented in the document “STO
Observation Scheduling: Constraints and Implications”:
1. b-strips and Galactic Plane Survey (GPS) have the highest Priority
2. The Galactic Plane survey is mapped uniformly to a [CII] depth of 2x10-5 erg s-1 cm-2
sr-1 w/in the first 7 days (for PDRs), and then “no uniformly mapped” to the target
sensitivity of 7x10-6 erg s-1 cm-2 sr-1 (for CNM clouds, etc). The full 35 square degrees
are completed in 3 weeks.
3. At 2 weeks time, mapping on rho Oph begins.
4. At the 3 week mark, b-strip extensions, pointed observations of [13CII], and mapping of
eta Carina begins.
5. At the end of week 4, the flight is terminated.
To acquire the GPS maps and the b-strips the technique consist in taking several on-the-fly
(OTF) map scans across the region of interest. The GPS map is composed of several scans
merged together to compose a single large map of the galactic plane, whereas b-strips consist on
either a single or at most a few scans across a specific region of the sky.
A possible approach to perform the GPS is shown in Figure 1. The region of sky to be observed
is subdivided into several sections. To cover each section, the instrument/gondola system will
acquire a number of scans across the section. Another possibility to accomplish the GPS is to
define a long series of scans that will cover the entire region. The autonomous observing
program can accomplish the GPS in both ways or in an hybrid form where some parts of the
galactic plane observation are defined as sections and other parts as a long independent series of
scans. This gives flexibility to the scientists to choose whichever best method can provide the
best coverage throughout the mission.
Pointed observations are instead accomplished using the position switching technique.
4 Automated Observing Program Implementation
The automated observing program basic design relies on the ACE process to read from an
observing table (OT) information about the location of the targets, the type of observation to
perform, the priority of the observation and the number of times to repeat it. The information in
the OT is fed into an algorithm that based on the visibility of the targets, their priority and the
repeats left determines which is the next target.
4.1 Implemented Observing types
There are two main observing types that are implemented:
1. On-The-Fly mapping (OTF). This observing type is divided into two sub types:
a. Single OTF: where a single scan is performed. This is a 1D map
b. Region OTF: where a 2D region is defined and several subsequent scans are
performed with small offsets as to cover the entire region. Figure 1
demonstrates how the GPS survey would be accomplished by using this
observation type.
2. Position-Switching (PS)
These Observing types are entered in a slightly different way into the OT so that the ACE when
it reads the OT can determine what observing type to perform as shown in the different examples
in Table I.
Figure 1: Example on how to perform the GPS mapping using the observing type 1b (Region OTF
mapping). Top Image shows in light green the location of the Galactic Plane Survey. The GPS is
subdivided into several regions. Each Region represents an observation entry in the observing table
used by the ACE to carry out the automatic observations. The bottom figure shows the different
parameters defining each region.
4.2 Observing Table Definition
Each observation is defined by a number of parameters that are entered in one single row of the
OT. There is in theory no limit on the number of observations that can be listed in the OT. The
OT is originally uploaded into the ACE at boot time before the beginning of the flight. It can be
manually modified in-flight with a series of operator command described in Section 4.3.
Table I: Observation T (OT) able for the STO automated observation program. This table is
uploaded into the ACE computer before flight and can be modified in-flight with a simple command.
The upper part of the table describes the various column parameters. It also shows an example of
entry for an on-the-fly map observation. The lower portion shows an example of entry in case of a
position switch observation. In this case the Sector End columns are not used as well as the Scans
Offsets column. When the code reads this kind of entry and sees that the type is PS it will disregard
columns # 7, 8, and 10.
The Observing Table is shown in Table I.
The meaning of the columns entries for the Observing Table varies slightly depending on the
type of observation. This is described below.
4.2.1 Columns definition for OTF Type
The following description is for the OTF maps. The numbering refers to the column number:
1. Observation Number: Each observation entry is assigned a unique observation number
or ID that can be used to determine what observation the ACE is executing or also to
identify which observation needs to be modified/updates in-flight.
2. Observation Type: The type of observation can be either
1 = On-The-Fly map
2 = Position Switch.
3. Input Coordinate Type: Allows choosing from two celestial coordinate types. It can
be:
1 = Right Ascension (deg) and Declination (deg) using the J2000 Equinox.
2 = Galactic latitude (b) and longitude (l) coordinates.
The ACE computer uses this information to convert the given coordinates in current
equinox Ra and Dec.
4. Scan 1 Start first coordinate: The Scan 1 is the first scan in the observing section (see
bottom panel in Figure 1). The Scan 1 Start is where the first scan begins. The first
coordinate depending on what was selected in Column 3 can be either Right Ascension
J2000, or Galactic longitude (l).
5. Scan 1 Start second coordinate: The second coordinate of Scan 1 Start.
6. Scan 1 End first coordinate: The Scan 1 End is where the first scan ends. The first
coordinate depending on what was selected in Column 3 can be either Right Ascension
J2000, or Galactic longitude (l).
7. Scan 1 End second coordinate: The second coordinate of Scan 1 End. Depending on
what was selected in Column 3 can be either Declination J2000, or Galactic longitude (l).
8. Section End first coordinate: The section end coordinates define where the sector ends
and thus the ACE stops doing scans (see bottom panel in Fig. 1). The first coordinate
depending on what was selected in Column 3 can be either Right Ascension J2000, or
Galactic longitude (l). If the observation is only of 1 scan and not an entire section then
this column is ignored, in which case any value can be given to it. In the example 2 on
Table I the value 0 is given.
9. Sector End second coordinate: The second coordinate of Section End. Depending on
what was selected in Column 3 can be either Declination J2000, or Galactic latitude (b).
As in Column 9 if the observation refers to a single scan rather than a section then this
column is ignored and any value can be give to it (e.g. 0).
10. Scans Offsets: This parameter tells the ACE by how much in arcsecs the subsequent
scans need to be shifted in order to eventually cover the entire section. Since the beam
size is about 50 arcsecs and a typical scan offset is ½ the beam size, typically this
parameter is around 25 to 30 arcsecs. If the observation type is only 1 single scan then
this parameter must be given the value 0. Then the ACE recognizes that this is a single
scan and not a region scan. It will then ignore the information input in Columns 8 and 9.
11. Scan Rate: How fast the telescope must drift to go from Start to End. From this
information the ACE computer determines how long the scan takes and the needed speed
in azimuth and elevation needed to do the scan.
12. # Repeats: This parameter indicates how many times this sector must be redone
throughout the entire mission. The repeats are not necessarily done sequentially one after
another. After the observation is finished (either the section scan is completed or the
single scan is done) the ACE decreases the # Repeats by 1 and then selects another
observation depending on visibility, priority and # Repeats. When this number is 0 the
ACE ignores this observation entry. This can be modified using the commands described
in Section 4.3.2
13. Priority: A number indicating the priority of the observation. The higher the number
the lower the priority. The highest priority assignable is 0. By default every entry has
priority 0. This information is used by the ACE computer to determine the sequence in
which the observations are automatically performed. Multiple entries can have the same
priority level, in which case the ACE will decide which to do first depending on the
visibility of the targets, the number of repeats that need to be done. The algorithm to do
the selection is described in Section 4.5.
4.2.2 Columns Definition for PS Type
The following description is for the PS observations. In this case Colum 2 has the entry “PS”
and the ACE code will interpret the meaning of the columns in the entry in a slightly different
way. Below are only discussed the entry interpreted differently from the OTF type:
4. SRC first coordinate: This column gives the first coordinate of the Source (target in the
sky). The first coordinate depending on what was selected in Column 3 can be either
Right Ascension J2000, or Galactic latitude (b).
5. SRC second coordinate: The second coordinate of the source. Depending on what was
selected in Column 3 can be either Declination J2000, or Galactic longitude (l).
6. REF first coordinate: The first coordinate of the Reference target. Depending on what
was selected in Column 3 can be either Right Ascension J2000, or Galactic latitude (b).
7. REF second coordinate: The second coordinate of the reference. Depending on what
was selected in Column 3 can be either Declination J2000, or Galactic longitude (l).
8. Blank: This column is disregarded for PS observations. Enter 0
9. Blank: This column is disregarded for PS observations. Enter 0
10. Integration Time: How long to stay on the source or the reference to take the
observations.
11. # on-offs: During a single observation sequence how many times to switch between
source and reference before ending the observation. In the example (example 3 in Table
I) is given the value of 3. This means that the ACE will observe the source than go to the
reference and then go back to the source for a total of 3 time taking measurements at the
source and 3 times at the reference.
4.3 Observing Table Upload and Modification
4.3.1 Observing Table Upload
The observing table is uploaded into the ace before flight. It should contain all the observations
needed to cover the full mission. There could be several observing tables uploaded into the ACE
at the same time but the ACE is instructed using an nvRam Parameter which observing table to
use. This parameter can be changed in-flight to instruct the ACE to use a different observing
table. The command to change observing table is the following:
nvRamUseOT(<table_name>)
where <table_name> is a string with the name of the observation table in the ACE file system to
be used. If the ACE cannot find the given table name it replies with an error message and
continues to use the current observation table.
At startup time the ACE uploads the observing table pointed by the nvRam and creates an
internal Observing Table structure that is used to access the table parameters.
During normal operations the OT structure is automatically modified for example when an
observation entry was completed and the #Repeats is reduced by 1 unit. After each modification
of the table the ACE saves a new ASCII table in its file system.
If an ACE reset event occurs in-flight at the new startup the ACE will upload the latest version of
the OT and continue the observation from where it stopped before the reset event.
4.3.2 Commands to Visualize & Modify the Observing Table
Sections of the current OT can be visualized. It cannot be completely visualized since it will
probably a very long table so the number of entries that can be viewed with one command are
limited to one full screen equivalent to TBD screen lines. The command to visualize the OT is
the following:
OTShow(<start obs. number>, <number of lines>)
where <start obs number> is the observation number (or column number in the OT) of the first
entry to be visualized, and <number of lines> is the number of observations to be visualized
following <start obs. number>. The <number of lines> value is limited to a maximum of TBD.
Entries in the current observing table can be changed in-flight from the ground using the
following commands:
Command to completely modify an existing table entry or add a new entry at the end of the table:
newOTEntry(<Obs. Number>, <Obs Type>, <Coord Type>, <Xs>, <Ys>, <Xe>, <Ye>,
<Xse>, <Yse>, <Scan Duration>, <Scans Offset>, <Priority>, <#
Repeats>, <Repeats Done>)
If <Obs. Number> is given the 0 value it is regarded as a completely new entry and added at the
end of the table and assigned a corresponding Obs. Number.
Command to modify a specific column entry for a specific observation entry:
OTParamSet(<Obs. Number>, <Colum Number>, <Entry Value>)
where <Entry Value> is given as a STRING and then the ACE will convert it to the correct type
depending on the column number.
If the specific column entry needs to be modified for a range of rows the following command is
used:
OTParamRngSet(<Start Obs. Number>,(<End Obs. Number> ,
<Colum Number>, <Entry Value>)
4.4 Reference Observations Table Definition
For OTF mapping prior to initiate a scan and after finishing a scan the instrument must take
reference spectra in regions on the sky next to
the galactic plane that are sufficiently clean.
To do that a second table is uploaded to the
ACE with coordinates of regions above and
below the galactic plane that satisfy the
cleanliness requirement. The table is shown
in Table II.
Before taking a scan the ACE will search the
table to find a reference region closest to the
starting point of the scan. It moves the
Table II: Example of Reference Table
telescope to that spot and commands the
spectrometer to take a reference spectrum. At
the end of the scan it looks again in the table to find another clean region and moves to that
region to take a post scan reference spectrum.
4.5 Algorithm to determine which observation to do next
The algorithm for now is still under development. Its main design is to base the selection of the
next observation in the OT to be performed upon the targets visibility, the observation priority
and the number of repeats left.