Observatory Monitoring System

This is a general description of the Observatory Monitoring System.

I. Overview
II. Observation Logs
III. Data Sources
IV. Data Products
V. Software
VI. Directory Structure
VII. OMS News
VIII. Staff Contacts
IX. OSB Home Page
I. Overview
The Observatory Monitoring System (OMS) is designed to monitor the engineering telemetry collected on board the spacecraft. In addition to the various temperatures, currents and voltages, this information pertains to the pointing and the status of the Fine Guiding System instruments. Information regarding the status of each instrument, counter and sensors, and mode switches are also available in this telemetry stream.
This time-tagged stream of engineering telemetry is correlated with scheduled events as determined from the Mission Schedule. This allows the OMS system to fine tune its monitoring algorithms. Thus, the expected status of an instrument for a particular operating mode can be compared to the actual status. If there is a difference, the OMS system can report the discrepancy.
The Mission Schedule information also allows OMS to report in more detail what the status of the instrument and the telescope was during a specific exposure. Thus the most recent acquisition of guide stars, the orientation of the telescope, and minute changes in the V2/V3 axes during the exposure are reported.
The OMS system consists of two major programs (MSCPARSE and OMSANAL), three major data sources (PDB, MSC, AEDP), and a host of output files. This manual describes each component of the system, giving examples of the inputs and outputs, and explaining how the system can be operated.

II. Data Sources
The Mission Schedule
The Mission Schedule is an elaborate file with information about each command sent up to the Space Telescope. The schedule itself goes through several iterations between SPSS and PASS where assumptions made regarding the actual time of events are checked against definitive orbit parameters. The final Mission Schedule is sent back to the Institute from PASS, and it is this product, with the definitive time stamps, which is used as input to the OMS system. Those Mission Schedules ordinarily cover an entire week of commands.
The first step in the OMS system is to reduce the information in the Mission Schedule file, and to convert that data into a more simple format. The MSCPARSE routine is designed to parse the mission schedule, and produce an 'event file' which details the particular commands which are of interest to the OMS system.
A brief segment of the EVT file produced by MSCPARSE is listed below:
```
	:		:
	:		:
1993.270:00:40:49.000  49257.02834 orbit EDF2OCLT
1993.270:00:40:49.000  49257.02834 S/C   PFHST2OC
1993.270:00:42:31.000  49257.02952 PCS   EOACQ1
1993.270:00:48:51.000  49257.03392 orbit EDF3OCLT
1993.270:00:48:51.000  49257.03392 S/C   PFHST3OC
1993.270:00:49:10.000  49257.03414 S/C   PMATNOOP
1993.270:00:49:35.000  49257.03443 orbit XSAA4
1993.270:00:49:45.000  49257.03455 SI    RECON- - ? -
1993.270:00:49:49.010  49257.03459 SI    WFPCWFC
1993.270:00:49:49.010  49257.03459 SI    WFPCMECHON
1993.270:00:49:50.010  49257.03461 SI    WFPCOPER
1993.270:00:50:43.000  49257.03522 S/C   PETRUSE
1993.270:00:51:10.000  49257.03553 orbit EODAY
1993.270:00:52:17.318  49257.03631 OBS   WFCBOO                                C
                                                         PROP  = 04848
                                                         PROG  = 1DK
                                                         OBSET = 2Z
                                                         ALIGN = 01
                                                         SI    = WFC
                                                         EXP # = 01
                                                         EXP TI=    500.00
                                                         TARGET= PARALLEL-F
                                                         SOGS #= W1DK2Z01
1993.270:00:51:59.000  49257.03610 S/C   PMAOFF
1993.270:00:52:48.000  49257.03667 OBS   FGS3BOO                               C
                                                         PROP  = 04892
                                                         PROG  = 1IT
                                                         OBSET = 0G
                                                         ALIGN = 01
                                                         SI    = FGS3
                                                         EXP # = 02
                                                         EXP TI=   1338.00
                                                         MAG   = 1.19799995
                                                         MODE  = TRANSFER
                                                         FILTER= F583W
                                                         TARGET= 4892_8
                                                         SOGS #= F1IT0G01
1993.270:00:53:49.000  49257.03737 orbit EDF1OCLT
1993.270:00:53:49.000  49257.03737 S/C   PFHST1OC
1993.270:00:55:02.000  49257.03822 S/C   PLGA2
1993.270:00:55:20.000  49257.03842 orbit EZOE
1993.270:01:00:37.318  49257.04210 OBS   WFCEOO
1993.270:01:01:01.000  49257.04237 orbit XZOE
	:		:
	:		:
```
```
	Here the fields are:
	1:	Calendar time
	2:	Modified Julian Date
	3:	Type of event
	4:	Event name
	5:	Event detail (variable)
```
AEDP Subset Files
AEDP produces two kinds of engineering telemetry files. The first, called 'Reconstructed' (or RECON) Engineering files, contain the raw Engineering data blocks (EDB) from the telescope. The second product, called 'Subset' Engineering files, contain the values of the engin- eering parameters after they have been converted to real engineering units (as specified in the PDB). Perhaps more importantly, this file represents "condensed" data: a parameter is only reported if its value has changed.
The advantage of using the AEDP data is that it combines into a single data stream both the real time engineering telemetry as well as the tape recorded engineering data. Thus we don't have two sources, and we don't have to worry about overlap.
The subset engineering files have header information (Figure 1) followed by densely populated binary data giving the tag value, the data type, and the data value for all the telemetry points. Depending on the telemetry format these files can be quite large: some exceed 50,000 blocks (25.6MB).
OMS_DATABASE.TBL
This ASCII file is produced from the PDB by the IMTOOL group. The input is the PDB files, plus the previous version of the OMS_DATABASE. The function of the IMTOOL program is to look up each mnemonic in the TDFD files to determine what its current tag value, spelling, and description are. These are then written into the new OMS_DATABASE which is used by the OMSANAL routine.
The header of this file contains the PDB version. When OMS is running, it checks that the AEDP Subset file and the OMS_DATABASE file agree (first two characters of PDB, not the whole thing). If they differ OMSANAL will not proceed.
```
C     OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS
C
C               File : OMS_DATABASE.TBL
C               File last revised on: 13-SEP-1993 14:29:32.12
C               Using PDB Version: 30AP
C
C     OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS OMS
C
 238    1 CHRSPP   C021 C          HRS Pri Power
 239    2 CHRSRP   C022 C          HRS Red Power
 240    3 CHRSRIPP C023 C          HRS RIU Pri Power
 241    4 CHRSRIRP C024 C          HRS RIU Red Power
 242    5 CFOSPP   C025 C          FOS Pri Power
 243    6 CFOSRP   C026 C          FOS Red Power
 244    7 CFOSRIPP C027 C          FOS RIU Pri Power
 245    8 CFOSRIRP C028 C          FOS RIU Red Power
	:		:
	:		:
4296  852 XOBETMP2 X114 R degC     OBE HK Temp 2                      
4297  853 XOBETMP3 X116 R degC     OBE HK Temp 3                      
4298  854 XOBETMP4 X118 R degC     OBE HK Temp 4                      
4299  855 XOBETMP5 X120 R degC     OBE HK Temp 5                      
4300  856 XOBETMP6 X122 R degC     OBE HK Temp 6                      
4301  857 XEBATMP7 X124 R degC     EBA Temp 7 Sink Snsr               
4302  858 XEBATMP8 X126 R degC     EBA HK Temp 8                      
	:		:
	:		:
```
The main function of this file is to link the current PDB telemetry tag to the OMS system "frozen" tag. This file must be generated by the IMTOOL group when a new PDB is to be installed in the operational system.
```
	1:	Current PDB tag
	2:	"frozen" tag
	3:	friendly mnemonic (PDB and yurintab)
	4:	shuttle mnemonic (ANNN) (Lockheed)
	5:	parameter type (C:character; R:real; I:integer)
	6:	units (from the PDB TDFD.DAT file)
	7:	description (from the PDB TDFD.DAT file)
```
LIMITS.DAT
OMS has been modified so that the limit information is now found in a table. Actually this file contains not only limits, but triggers to activate some analysis process, or to save a telemetry point to a save file.
If the parameter is already in the OMS_DATABASE.TBL then no changes to the code are required when this file gets updated. As an example, the current LIMITS file has records like:
```
		:		:
		:		:
FOC  Hold48   C  859 X128 Power               -21.74   -15.31    20.00    32.58
FOC  Hold48   C  868 X146 Power                 4.36     4.36     4.60     4.60
FOC  Hold48   C  869 X148 Power                 0.00     0.00     0.72     0.72
FOC  Hold48   C  870 X150 Power                 0.00     0.00     0.08     0.08
FOC  Hold48   C  871 X152 Power                 3.76     3.76     4.68     4.68
FOC  Hold48   S    9 C029 Power    On
FOC  Hold48   S   10 C030 Power    On
FOC  Hold48   S   11 C031 Power    On
FOC  Hold48   S   12 C032 Power    On
FOC  Hold48   S  247 M263 Power    ExI CmdI
FOC  Hold48   S  248 M265 Power    ExE CmdE
FOC  Hold48   S  249 M267 Power    ExE CmdE
FOC  Hold48   S  250 M269 Power    ExE CmdE
FOC  Hold48   S  251 M271 Power    ExE CmdE
		:		:
		:		:
```
The function of this file is to establish the legitimate range (or state) of a telemetry parameter, and to specify which parameters (tags) are to be written to the save files, and which are to be used as triggers. This file is not expected to change a lot, but can do so if required by the engineering staff.
```
	1:	Instrument (or blank for triggers)
	2:	Mode (or 'Save' or 'Trigger')
	3:	Type of Limit or Action*
	4:	"Frozen Tag"
	5:	Shuttle Mnemonic (ANNN)
	6:	Telemetry Subsystem Name (e.g. "Power")
	7:	Default State
	8:	Default Limits (e.g. rl,yl,yh,rh)

	[Types of Limit: C: Check Limits
			 S: Check State
			 Y: Check Yellow
			 L: Check LowLim
			 V: Check Value
			 P: Print String Value
			 W: Check Window
			 T: Trigger]
```
As an example of the 'SAVE' records, specifying which parameters get written into the SAVE files:
```
	FOC  Save     W  832 X076
	FOC  Save     W  833 X078
	FOC  Save     W  834 X079
	FOC  Save     W  849 X108
	FOC  Save     W  850 X110
	FOC  Save     W  852 X114
```
III. Data Products

Jitter File
OMS now produces a new file for each observation detailing the characteristics of that observation from an engineering point of view. Most critical for some observations is the 'jitter': variations in the pointing of the telescope while the observation is being taken.
The new file, 'ipppssoot.JIT', contains both an ASCII header in familiar keyword format, as well as the jitter data in ASCII appended to the header file. Figure 2 shows an example of the header, and a few lines of the jitter data. These files can be fairly large.
A more explicit definition of each keyword is contained in Section VI below.
Telemetry Exceptions.
The major purpose of the OMS system is to scan the engineering telemetry to determine if there are any problems with what is going on during the mission. Those "problems" are reported in the output file OMS_ERROR.OMS. An example of this report in included in Figure 3. The fields in this report are explained below:
S/C TIME
Spacecraft time from the OMS Subset file. Format is: YY:DDD:HH:MM:SS.S
ERROR:
Kind of error which was detected. For each instrument, and for each mode, each parameter can be checked against a "LOW RED", "LOW YELLOW", "HIGH YELLOW", "HIGH RED" limit. (Character parameters are checked against an expected "STATE").
When a parameter goes out of limit, it is subsequently checked when it goes back into limit. When this happens the report indicates that the parameter is now "OK".
The definition of what checks to make on what parameters, and what limits to check against, is the subject of the LIMITS.DAT file.
SYS - SUBSYS - MODE:
A description of which instrument (SYS), which subsystem, and what mode that instrument was in when the error was detected.
The subsystem is determined by the instrument engineers for each parameter, and is listed in the OMS_DATABASE.TBL file. The modes of the instruments are also determined by the engineering staff.
DESCRIPTION:
This is the description of the parameter which is contained in the Project Data Base. This is contained in the OMS_DATABASE.TBL file which is regenerated with each new PDB.
Sh Mnem:
This is the familiar telemetry mnemonic used by PODPS and is derived directly from the PDB.
VALUE:
There are a combination of things in this field:

(a) The Lockheed mnemonic used by the Instrument Engineers;
(b) the current value of the telemetry point;
(c) the limit with which this is being compared;
(d) the units of the measurement;
(e) and, optionally, the observation which was being taken at that time, if any.

The SAVE files
Each instrument engineer has defined a list of engineering telemetry points which should be extracted out of the telemetry on a daily basis and saved in an ASCII file. These files are used by existing programs to monitor critical changes, and to research anomolous events.
A fragment of a WFPC save file might look like:
: : : : 93.262:09:59:59.9 49249.41667 P003 No 93.262:09:59:59.9 49249.41667 P004 No 93.262:09:59:59.9 49249.41667 P005 Zero 93.262:09:59:59.9 49249.41667 P112 Zero 93.262:09:59:59.9 49249.41667 P114 RGA Only 93.262:09:59:59.9 49249.41667 P115 Dormant 93.262:09:59:59.9 49249.41667 P116 No 93.262:09:59:59.9 49249.41667 W718 19.77 93.262:09:59:59.9 49249.41667 W719 -37.95 93.262:10:00:00.1 49249.41667 W597 Clear 93.262:10:00:00.1 49249.41667 W598 Clear 93.262:10:00:00.1 49249.41667 W599 1.18 93.262:10:00:00.1 49249.41667 W600 9.88 93.262:10:00:00.1 49249.41667 W725 10.62 93.262:10:00:00.1 49249.41667 W726 9.37 : : : : The fields in these files are: 1: Calendar time 2: Modified Julian Date 3: Lockheed mnemonic 4: Telemetry Value
The engineering staff have COLPAR-like plotting tools to display these data, and some of those tools are windows based. We have developed an iraf script to produce a plot of any of these parameters. See the next section for more discussion of tools.
Mission List
As a byproduct of the Mission Schedule Parser, the MSCPARSE program produces a simple ASCII listing of the observations which are scheduled for the next week. A few sample lines of that listing are:
: : : : 1993.278:19:03 | FOC/96 | NGC1399 | X1DE0101 1993.278:19:47 | WFC | EARTH-CALI | W1FH1901 1993.278:19:54 | WFC | EARTH-CALI | W1FH1902 1993.278:20:02 | WFC | EARTH-CALI | W1FH1903 1993.278:20:04 | WFC | EARTH-CALI | W1FH1904 1993.278:20:34 | FOC/96 | NGC1399 | X1DE0102 1993.278:20:40 | WFC | HI-LAT | W1DGF801 1993.278:20:55 | FOC/96 | NGC1399 | X1DE0103 1993.278:21:24 | PC | EARTH-CALI | W1M20P01 1993.278:21:27 | PC | EARTH-CALI | W1M20P02 1993.278:21:37 | PC | EARTH-CALI | W1M20P03 1993.278:21:40 | PC | EARTH-CALI | W1M20P04 1993.278:22:16 | FOC/96 | NGC1399 | X1DE0104 1993.278:22:55 | PC | INTFLAT | W1IN0201 1993.278:23:05 | PC | INTFLAT | W1IN0202 1993.278:23:54 | FOC/96 | INTFLAT | X1I70101 1993.279:00:16 | FOC/96 | NGC188-54 | X1I70102 1993.279:00:35 | FOC/96 | NGC188-B96 | X1I70103 1993.279:03:49 | HSP/UV | NOVACYG | V1F30103 : : : : Where: 1: Calendar time 2: Instrument/Mode 3: Target name 4: IPPPSSOOT

Other Products
In addition to the files described above, OMS produces special purpose files for the analysis of specific problems, and for trending special telemetry patterns. While these are not usually of interest to the SOGS operations group, they are described here for completeness.

ACQ_TIMING
A lower level "autopsy" of all guide star aquisitions, including information on FGS mode, vehicle guiding mode(scheduled and actual), FGS search status and radius. It also contains information on all FHST updates, slews, and occultations. Generally speaking the ACQ_TIMING information is more engineering oriented.
AEDP_HEADER
One AEDP_HEADER file is produced for each engineering subset file that OMS reads. It provides information including but not limited to the time period covered by a given file, the subset AEDP data used to generate the file, the PDB AEDP used to generate the file, and the telemetry format.
EARTH_AVD
Contains the time from the moment when the FGS default status is turned ON or OFF to the moment when the vehicle enters or leaves the earth avoidance zone.
FGS_SAVE
Contains the PMT counts and the FGS star selector angles.
** NOTE: In the FN telemetry format, the star selector angles are sampled at 20Hz instead of the full 40Hz rate. This was done to avoid interpolating the time and problems with the compressed data.
GS_ACQ
A full "autopsy" of all guide star acquisitions and vehicle guidance including information on FGS mode, vehicle guiding mode (scheduled and actual), FGS search status and radius, guide stars (i.e. magnitude and count threshold), FGS usage, vehicle jitter, statistics on the jitter and PMT counts for each observation, loss of lock, and recentering. Generally speaking the GS_ACQ information is more observer oriented.
OMS_SUMMARY
A summary of guide star aquisitions including tracking mode, PMT count rate, guide star locations, and duration of acquisition. It also contains statistics on the jitter and PMT counts for each observation, and loss of lock. Vehicle slews, FHST updates, day/night transitions, and earth occultations are reported.
PMT_DARK_CNT
A one minute average of the PMT count rate as a function of the latitude and longitude of the vehicle when the FGS is not being using for guidance or astrometry is reported.
POWER
Reports on changes in the bus voltage, battery current, PDU current, and the trickle charge.
THERMAL
Selected temperature for the aft shroud, forward shield, light shield, primary mirror, seconday mirror, main ring, focal plane, and metering truss are reported on. This is not a "save" file. Maximums, minimums, and differences are calculated from equations provided by Lockheed.

IV. Software
The software associated with this system consists of two main modules (MSCPARSE and OMSANAL) accompanied by several utility and display programs.
MSCPARSE
This command allows one to parse the mission schedule file and create the event file. The output file will be written to the directory pointed by the logical name OMS_EVT_DIR. (See section V for a review of OMS logical names). The name of the output file is MSC_yydddhhmm_ yydddhhmm.EVT where yydddhhmm_yydddhhmm is the time of the first event and last event in a mission schedule. Note that these times may be different from the start and stop time specified in the mission schedule file header.
Each mission schedule usually has a header. If the header is not within the first 30 lines of the mission schedule, the processing will stop unless /IGNORE is specified.
Format: $ MSCPARSE [/ignore] infile Example: $ MSCPARSE BBB:[DAT.MSC]*.POD

OMSANAL
This package is a stand-alone version of the OMS analysis software. That system analyses the AEDP engineering subset data in conjunction with the mission schedule. Each engineering event is time stamped, thus one can correlate the uplinked commands (mission schedule) with the downlinked results (AEDP values).
The output of this system consists of a large number of ASCII files. These include the instrument specific 'SAVE' files, observation specific jitter and obs_log files, as well as several special purpose engineering analysis files.
At the end of each run the OMS system dumps a copy of its memory into a binary file. When you next start the OMS system you can elect to initialize memory to that state, or to start 'cold' with parameters initialized to zeros. The memory file contains the state of ALL OMS parameters.
This capability is important for the OMS system. One of it's major functions is to determined if any engineering parameters have changed their values significantly. If the system has no knowledge of the previous values, one can get a number of false warnings.
However, it is also a dangerous feature. You don't want to run the system with an irrelevant copy of the memory as an initial state. The system is designed to protect the user in this regard: if the initial memory is more than an hour old, OMS will be initialized without the memory copy.
Format: $ OMSANAL [/warm] FILENAME Example: $ OMS/WARM BBB:[DAT.SUB]S*.V*

TIMELINE
AEDP subset files are binary files, and not easily readable. This routine is designed to extract the beginning and ending time from a single, or a set of AEDP subset files. The output is saved in the file TIMELINE.REC in your default directory. An example of the output is:
------------------------------------------------------------------------------- AEDP FILE | JUL BEGIN | JUL END | CAL BEGIN | CAL END ------------------------------------------------------------------------------- SD6G2244W.VC0;1| 49154.94770| 49154.97312| 1993.167:22:44:40| 1993.167:23:21:17 SD6G2321W.VC0;1| 49154.97355| 49155.00685| 1993.167:23:21:54| 1993.168:00:09:52 SD6H0010W.VC0;1| 49155.00697| 49155.04464| 1993.168:00:10:02| 1993.168:01:04:16 SD6H0104W.VC0;1| 49155.04485| 49155.07632| 1993.168:01:04:34| 1993.168:01:49:54 SD6H0202W.VC1;1| 49155.08486| 49155.10301| 1993.168:02:02:11| 1993.168:02:28:20 SD6H0228W.VC2;1| 49155.10324| 49155.11618| 1993.168:02:28:39| 1993.168:02:47:18 SD6H0247W.VC3;1| 49155.11663| 49155.14396| 1993.168:02:47:57| 1993.168:03:27:17 SD8F2253W.VC0;1| 49214.95363| 49215.00188| 1993.227:22:53:14| 1993.228:00:02:42 Format: $ TIMELINE FILENAME Example: $ TIMELINE BBB:[DAT.SUB]S*.V*

V. Directory Structure.
The OMS system defines a logical directory structure so that it can be executed in several different environments.

oms_main_dir
This directory contains command procedures and log files. In particular this directory contains the OMS_SETUP.COM procedure which sets up all other logicals and commands required to run the OMS system.
oms_dbase_dir
This directory contains static reference files such as the OMS_DATABASE.TBL, and the LIMITS.DAT files described above.
oms_output_dir
This directory is the destination of all OMS products. Many of these products will be shipped automatically to the SESD division's computers by the SOGS daemon.
oms_daemon_dir
The daemon directory for shipping products outside of the SOGS environment. The destination of files placed in this directory will be the OMS cluster on the third floor.
oms_evt_dir
Event files which are then output of the MSCPARSE routine, and thus input to the OMS system, reside in this directory.
oms_pipeline_dir
Products which remain on the SOGS cluster get copied to this directory. This is to ensure that the oms_output_dir can be cleaned up efficiently, and that only specific products remain on the SOGS disks. Currently the files which remain in the system are the observation specific jitter files, and the OMS error log.
oms_init_dir
This directory contains initialization files for the MSCPARSE routine.

HST Observatory Monitoring System - 03/15/94 (perrine@stsci.edu)
Updated: December 01, 1995

Observatory Monitoring System

I. Overview

II. Data Sources

The Mission Schedule

AEDP Subset Files

OMS_DATABASE.TBL

LIMITS.DAT

III. Data Products

Jitter File

Telemetry Exceptions.

The SAVE files

Mission List

Other Products

IV. Software

MSCPARSE

OMSANAL

TIMELINE

V. Directory Structure.