Internal Technical Memorandum ITM-1999-04
Making SMOVs Easier: Proposal Changes to
Minimize Special SQL
M. Reinhart and G. Chapman
April 23, 1999
ABSTRACT
The use of Standard Query Language (SQL) bypasses some of the normal proposal processing
(with the corresponding safety checks) and requires additional work by everyone involved in the
preparing a proposal for execution (the PI, the PC, the CS, Commanding and Scheduling). Review
of SQL usage revealed 10 cases where it has been commonly invoked in order to overcome various
implementation process and/or ground system deficiencies. Reducing special SQL usage by eliminating these deficiencies would simplify SMOV proposal implementation and reduce the work
load on operations personnel (i.e. another small step towards “cheap ops.”).
This document examines why SQL is necessary and should be minimized, describes the cases
where SQL is used to solve an implementation problem and recommends ways the ground system
could be modified to eliminate that SQL.
1. Introduction
Special SQL modifies the Proposal Management Database (PMDB) to properly and safely execute
those proposals (or visits) not fully supported by the entire ground/flight systems (i.e., it can’t be
specified in the proposal via the proposal instructions so that the ground systems properly react).
We examined the special SQL done for SMOV2 and Cycle 7 proposals and investigated the possibility of implementing these “special” proposals without SQL if enhancements were made to the
proposal instructions and various parts of the ground system.
2. Why Minimize the Use of Special SQL?
Special SQL is a proposal specific program that requires the following steps for successful
implementation:
• Determine the requirements
• Design and write the code
• Review and test the code
• Execute the code
• Maintain the code for the lifetime of the proposal
1
Internal Technical Memorandum ITM-1999-04
Usually, one to three additional individuals who do not write the actual code must be involved in
determining the requirements, helping with the design and conducting reviews of the code. For
many proposals, special SQL is a significant percentage of the proposal preparation effort.
Special SQL (or in some situations, the lack thereof) *can be* inherently dangerous. Using it
bypasses many of the safety checks that are built into the ground system. If the SQL has errors or
is improperly designed, then it may change things in an unexpected way. A worst case of this
would be when the database must then be reloaded from the previous night’s backup tape with the
resulting loss of all work done since the time of that backup (this has actually occurred at least
once since launch). A more typical result is several hours to days of intensive manual effort to
repair any damage. There has also been at least one case where incorrect special SQL was applied
to the PMDB and resulted in a spacecraft safing.
3. Special SQL Statistics
We were able to determine a lower bound of SQL usage for SMOV2/Cycle7 proposals (some simple special SQL that affects only scheduling may have been done interactively and so has not been
captured by this study).
Out of 143 SMOV2 and 648 Cycle 7 proposals, 103 required special SQL. Of those 103, 60 were
SMOV2 and 43 were Cycle 7 proposals. Of the 43, 17 were STIS Cals. So, if one smooths the
SMOV2 numbers out evenly through the SMOV/non-SMOV cycles (assuming 3 years between
servicing missions) and assumes an occurrence rate of ~25 special SQL proposals per cycle, then
this implies on the average over three cycles (assuming a cycle is ~1 year) that 40-45 proposals per
cycle (roughly 5% of the total using the above numbers) will require special SQL (given the current state of the ground/flight systems).
Although it is a small percentage of the total number, it consumes a much larger fraction of the
work and time devoted to preparing all the proposals for flight readiness.
4. Possible Modifications to Reduce the Special SQL.
With a few modifications and some creative use of merging Special Requirements (SR), approximately 99% of the Cycle 7 special SQL could have been eliminated. For SMOV, this would
eliminate approximately 50%+ of the special SQL.
4.1 Attaching a Special Instruction
The Problem
One of the main reasons for needing SQL is to invoke special commanding. Since all special
instruction names are specified in the exposure comments, this special SQL should not be
necessary.
The Recommendation
Enhance the current SR SPEC COM by the addition of an optional argument that specifies the
instruction name, SPEC COM [INST <name>], where name is a1-12 character instruction name.
This instruction name will be used to populate the qgactinst.instr_name field. If the [INST
<name>] parameter is missing, then an instruction name of UNKNOWN should be used to popu-
2
Internal Technical Memorandum ITM-1999-04
late qgactinst.instr_name. This provides a safety valve since an SMS error will result if the
instruction name is missing.
If there is a need to control various internal component times of an exposure, a possibility would
be to have the presence of the SR SPEC COM enable special optional parameters through which
the instruction name, overhead times, special qesiparms and so on could be specified.
This change would be very beneficial for SMOV, special engineering and non-standard calibration
proposals.
The Usage
There were 48 proposals that could have used this enhancement.
4.2 Using a Particular Guide Star Pair
The Problem
Many CAL and SMOV proposals have a requirement for a specific guide star or guide star pair.
This is generally specified in the visit comments.
The Recommendation
Create a new USE GS <pairid> SR. This SR is probably best done at the exposure level, but allowing only one to be specified in the obset (like the SR OBSET ID). If the gs acquisition is for a pair,
then <pairid> is the full 24 character gs pair id desired. If the gs acquisition is for single star, then
<pairid> is the 12 character gs id desired.
Implementation of this SR will require SPSS and NGSS changes. Two new fields will be required
in qbs_obset (which Trans will need to populate). Suggested names are gs_pair_id and
use_gs_pair_id. gs_pair_id will be a char24 field that will contain the <pairid> listed in the USE
GS SR. use_gs_pair_id will be a char1 Y|N flag that will indicate if the pair contained in
gs_pair_id is to be enforced or not (this allows toggling the feature on and off for testing purposes
without losing the initial population information). If the use_gs_pair_id field is a Y, then the pair in
gs_pair_id will need to be passed to NGSS. If the <pairid> forms a legitimate pair in NGSS, then
that will be the only pair passed back into the PMDB. If it does not form a legitimate pair, then no
pairs would be passed back into the PMDB.
This should be a Restricted and PC Only SR.
This change would be very beneficial for SMOVs and many FGS calibrations.
The Usage
There were as many as 50 proposals that could have used this enhancement.
4.3 Real-Time Uplink Comments
The Problem
When we moved from RPSS to RPS2, any R/T Uplink alignments (except for INT ACQs) require
special SQL to properly specify PSTOLs and comments in qacomments.
3
Internal Technical Memorandum ITM-1999-04
The Recommendation
It needs to be determined if this is still a requirement or not (the same information must be specified in the OPS Request for the uplink, so a more general, less rigid format description in
qacomments may be sufficient). We need to devise a way to specify these comments in the proposal so that they can be properly parsed and inserted into the PMDB without special SQL.
This change would be very beneficial for SMOV proposals.
The Usage
There were at least 20 proposals that could have used this enhancement.
4.4 Special STIS Calibrations
The Problem
Several STIS CAL proposals require non-standard settings of the STIS mechanisms to accomplish
their goals. As a result, special commanding and a lot of SQL combined with creative use of merging SRs must be done on these proposals.
The Recommendation
Come up with a way to deal with these non-standard STIS Calibrations as part of the supported
ground system.
This problem is being investigated by a separate group
The Usage
There were at least 17 proposals that could have used this enhancement.
4.5 Moving Target TRACK/NOTRACK Flag
The Problem
Currently, some engineering programs and GO/GTO programs observe fast moving targets requiring special obsets that just point the telescope at the moving target, but not track it. For example,
fast moving comets usually require a quick guide star acquisition to zero the pointing uncertainty
prior to a gyro obset that acquires the data. This quick gs acq obset should be done without tracking as the ramp-up, track and ramp-down of the vehicle for the tracking slew is unnecessary wearand-tear on the pointing control system as well as wasted spacecraft time.
The Recommendation
Create a new NOTRACK exposure level SR. The default would be to track the moving target, so
exposures with and without the NOTRACK SR would need to be merged into separate alignments
(merging SRs would take care of further breakup into obsets). Any alignment that contains an
exposure with SR NOTRACK would get the PMDB field qalignment.pointing_mde = ‘F’. When
doing the requirements analysis, we should remember to look into the other moving target fields
and see if they should be done differently for this SR.
This should be a Restricted and PC Only SR.
This change would be useful for SMOV proposals.
4
Internal Technical Memorandum ITM-1999-04
The Usage
There were at least 2 proposals that could have used this enhancement.
4.6 Moving Target PARALLAX Flag
The Problem
To fully implement the observations of close moving targets, we need to allow control of the obset
level parallax correction flag. For example, the Comet Hyakutake observations required a quick gs
acq to zero out the pointing uncertainty prior to the gyro obsets that acquired the data. Since NGSS
(then GSSS), SPSS and PASS (particularly PASS) in their GS/FHST computations do not account
for parallax, no parallax correction must be done for this quick gs obset. The Comet Hyakutake
observations required special SQL and SMS edits to correctly implement. The gyro moon observations had similar difficulties that required special SQL.
The reason that we have to specially handle close moving targets differently is due to the fix-point
nature of the DF-224 computer onboard HST. It appears that these limitations will be lifted by the
new 486 computer to be installed during SM3, thus, after that we should be able to do onboard parallax correction for any target that HST can track.
The Recommendation
The following assumes that the new 486 computer is operating onboard HST and there are no
longer any restrictions on distance for onboard parallax correction.
Create a new exposure level PARALLAX NO SR that can be specified only once in the obset. NO
would set the qbs_obset.parallax_fl to ‘N’ and would imply that no parallax correction is to be performed in SPSS, SCS, PASS or onboard the vehicle. The default would continue to be to set the
qbs_obset.parallax_fl to ‘Y’ which implies that the parallax correction is to be performed onboard
the vehicle. The parallax correction currently done by the commanding during SMS generation if
the qbs_obset.parallax_fl = ‘N’ would need to be removed.
This should be a Restricted and/or PC Only SR.
The Usage
There was at least 1 proposal that could have used this enhancement.
4.7 Using the FGS Internal Test Source
The Problem
CAL and SMOV proposals from SMOV2 to the end of the mission will be using the FGS Internal
Test Source (ITS) to set and monitor the Fold Flat Mirror. This is currently done via S/C exposures, use of merging SRs and a lot of SQL.
The Recommendation
Create a new ITS mode for the FGS (this is more properly a mode because ITS exposures must be
externally pointed).
When designing the rules for the ITS mode, it needs to be remembered that ITS exposures have a
set exposure and alignment time of 342 seconds. ITS exposures MUST occur after ALL other FGS
5
Internal Technical Memorandum ITM-1999-04
activities are done (this includes any FGS HOME). ITS exposures currently use special instruction
EFGSITS. This instruction requires the qesiparm FGS to have a value of the FGS (1|2|3) in which
the ITS observation is to be performed. Again ALL ITS exposures MUST use an external target
for pointing (NEP is a legitimate target for stand-alone ITS visits).
This should be a Restricted mode.
This change would be very beneficial for SMOV and some special FGS calibration proposals.
The Usage
There were at least 4 proposals that could have used this enhancement.
4.8 Spacecraft Non-OTA Aperture Pointings
The Problem
A number of proposals need to point the vehicle without taking any data. Nominally, this is
accomplished by means of a S/C exposure. Unfortunately, the only aperture that can be used is V1
(which maps to the OTA coord_id). This means that if one needs to point somewhere on the fieldof-view other than the boresight, then one must determine the V2/V3 position of the reference
pixel of the desired coord_id and put this into the proposal as a POS TARG offset from V1 (this is
labor intensive and produces an incorrect pointing after FOV realignments).
The Recommendation
Allow any legal coord_id to be specified as an aperture for the S/C exposure.
Another possible way to do this would be to have a POINT ONLY SR which would tell Trans to
set up the pointing based upon the aperture/config/filter given on the exposure line, but set up the
commanding as if it were a S/C config. Thus, Trans would compute the coord_id instead of figuring it out by hand.
The Usage
We could find no proposals in the study group that could have used this enhancement. However, at
least two Cycle 6 proposals could have used this capability.
4.9 Using the Same Guide Star Pair Between Visits
The Problem
At times, some proposals have a requirement to use the same guide stars between visits. This is
generally requested via a visit comment.
The Recommendation
Create a new SAME GS AS <visit> SR. This SR is probably best done as a visit level SR. Unfortunately, to implement this will require a very large infrastructure to be developed not unlike what
was done to support save and use offset (i.e., this would be another way to link visits together).
At this point, it is not clear if such a generic capability is really needed. It is likely that the recommendation for ‘Using a particular GS Pair’ above may be sufficient to support what is needed
albeit with a little manual work (but considerably less than what is being currently done with
SQL).
6
Internal Technical Memorandum ITM-1999-04
The Usage
There were at least 2 proposals that could have used this enhancement.
4.10 Non-Standard Bright and Dark Earth Avoidance Angles
The Problem
Some proposals have a need to use non-standard bright and dark earth avoidance angles. This is
currently accomplished in one of two ways: override the Trans tunable constants for the entire proposal or via SQL override in the PMDB on an alignment by alignment basis.
The Recommendation
If done as a SR, it would need to be at the exposure level. This means that it will definitely affect
merging since only like avoidance angles could be merged into a single alignment. Also, sanity
checks would need to be done such that the angles didn’t drop below the FGS angles if under FGS
control. Also, there are SI specific checks. For example, STIS cannot look closer than 2.0 degrees
to the bright earth. RPS2 may need to be able to model the various avoidance angles.
At this time, there are no real suggestions for the name of the SRs (BEA ANGLE?, DEA
ANGLE?). Also, it is not clear if there would be enough use of this feature to warrant the implementation effort.
This should be a Restricted and/or PC Only set of SRs.
The Usage
There were at least 3 proposals that could have used this enhancement.
5. Summary
Given the amount of usage that each type of special SQL saw in SMOV2 and Cycle 7, the recommendations in the sections listed below should be considered for implementation:
• 4.1 Attaching a Special Instruction
• 4.2 Using a Particular Guide Star Pair
• 4.3 Real-time Uplink Comments
• 4.4 Special STIS Calibrations
The rest are worth documenting but would seem to be a lower priority depending upon available
resources.
We would like to acknowledge feedback provided by the following people in the preparation of
this document: Vicki Balzano, Mike Boyer, Andy Gerb, John Isaacs, Bev Owens, Tony Roman,
Scott Speck, Scott Stallcup and Peg Stanley.
7