Flags are used to transfer information from one instrument to
another, on the same platform, to enable immediate modifications to be made
to operations, in a pre-programmed manner.
The exchange of information on board is much faster than the sum of
the downlink, manual decision and uplink times, and
thus the use of a flag system can allow the efficient
observation of a whole class of transient solar phenomena.
The operation of the coronal payload on SOHO will be performed in three layers.
Standard operations will involve planning sessions at the EOF with targets
and operating sequences fixed one or more days prior to the operation. This is
adequate for most solar targets.
The second layer involves developments in solar activity that
may demand changes in operation overriding previous planning, and this can
be done by commanding from the ground
during real time passes. For the shortest time-scale transient
activity, such as the
build-up of a bright point, the onset of a flare or eruption, the
EOF real-time interruption is not
quick enough. Therefore, the third layer of operation requires the use of an
inter-instrument flag.
Multiple Flag Policy
The operation of the SOHO scientific payload is extremely flexible and the
likely solar targets are many. This demands the use of multiple flags. Such a
system dictates a great need for care in planning, operation and responses
to flags as the potential for error is great. We avoid much complexity
and potential clashes by enabling only one flag at a time.
Thus, at any one time,
only one pre-defined instrument may flag an event in response to a specified
observation, and this will only have one potential reaction by the
receiving instruments. The ``flag enabled'' instrument will be known as the
Master and the receiving instruments known as the Receivers. Not all
experiments will want to receive a particular flag. Thus, for each flag-type
there will be a differing number of Receivers. The contents of the flag message
will include the co-ordinates of the solar event and some identification
data. The Master and Receivers are assigned from the ground, an individual
experiment cannot define its own role.
On receiving a flag, an instrument in
a Receiver status will terminate the current
operating sequence and run a new, pre-defined sequence centred on the
co-ordinates given. An instrument may choose to ignore the flag if the
co-ordinates are inappropriate (e.g., require significant re-pointing).
One issue that must be addressed is the flexibility of the order of the
flag receivers. It is useful to have differing orders for different flags
since particular flags will be of greater interest to different experiments.
The Inter-Instrument Process
The Inter-Instrument Data Exchange Protocol is described in Section 3 of the
SOHO EID A (Page 92, 25 March 1991). The flag data exchange will be
controlled in a cyclic manner by a COBS software task running in the
On Board Data Handling (OBDH). Two 16 bit words will be
sampled every 16 seconds from the Master. The words contain a validity bit
which, if set to 0, dictates that the X,Y solar co-ordinates of the solar
event be sent by block command to each Receiver. From the acquisition of the
flag from the Master, it takes 2 seconds to be relayed to the first
Receiver, another 2 seconds to the next and so on.
The OBDH block header 16 bit word is defined as follows. Bits 2-5 are the
destination address as defined in the table below. Bits 6-10 are the command
identifier where 00100 corresponds to Master/Receiver Selection, and
00110 corresponds to Inter-Instrument Data Exchange. If the command
identifier is 00100 the block length, given as bits 11-15, is 00010 since
the data field will only contain the mode selection word and the checksum
dat word (defined in the EID A). The mode selection word is
0000 0000 0000 0000 for Standy by, 1111 1111 1111 1111 for Master mode, and
1010 1010 1010 1010 for Receiver mode.

Instrument Identification Codes

If the command identifier is 00110 the block length is 00011. This is
followed with the two 16 bit words from the Master and the checksum
data word from the OBDH. In the first
word, bits 1-4 are the instrument ID, bit 5 is set to 0, and bits 6 to 15 are
the X co-ordinate of the solar event. For the second word, bits 1-4 are the
solar event ID, bit 5 is set to 1, and bits 6-15 are the Y co-ordinate of the
solar event. Bit 0 is the validity bit for both words, set to 0 for a
valid message and 1 for an invalid message.
The inter-instrument communication process can be in an active or disabled
state. In the latter, all instruments are set to the stand-by flag state.
Event Identification
.25cm
The first problem is the identification of a solar event to be flagged. Such
an event would presumably be identified by a change of circumstances, be it a
significant rise or fall in brightness at a specific wavelength or a
Doppler shift. A Doppler shift can be thought of as a brightening if one is
monitoring intensities just off line-centre from a specific spectral line.
A further event-type would be transverse motion which would have to be
identified through differencing of successive images.
An example of a flag is given below, along with a method
of identification, the Master and Receiver instruments and
event ID for use in the flag word (see above).
Solar Event: Flare
cm

Event ID: 0001
cm

Master(s): EIT/CDS/SUMER
cm

Receivers: CDS/SUMER/UVCS/LASCO/MDI
cm

Method for Event Recognition: Identify excessive brightenings
either in the EIT image or in a hot CDS(NIS)/SUMER spectral line (e.g.
Fe XVI 335.40Å, 360.76Å or Si XII 520.67Å) during a large raster scan
over an active region. The intensity threshold must be set to a relatively
high level.
cm
Other potentially useful flags are, e.g.,
Bright Point,
Microflare,
High Velocity Events,
Tranverse Velocity Events,
Activated Prominence,
Eruptive Prominence,
Coronal Mass Ejection, and
Precursor Activity.
cm
Many flags can only be set through experience. For example, the setting of
thresholds must remain flexible since we do not have an accurate feeling for
expected intensities for some events. Furthermore, while the crossing of
intensity thresholds is clear cut, the idenitication of transverse motions
through image comparisons, on board, is not straightforward and may require
much development and tuning. As a result, we cannot expect to
have a complete, finely tuned system from day one.
Schedule
The mechanism for the flag generation and processing should be set up as the
OBDH and instrument CDHS systems are developed. That is, the instruments
should adhere to the instructions in the EID-A as described above.
Specific codes should be written into the instrument CDHS for each potential
Master and Receiver to generate and respond to flags 0001 and 0010 as
described above. These are the simplest flags. Threshold figures should be
estimated.
The flag system will not be among the highest priority operations at the
start of the mission and will most likely not be used for some weeks after
arriving at the L1 point. Initial scientific operations will include the
onset of basic synoptic programmes and ``look and see'' spectral scans and
rasters. However, it is recommended that the flag system be brought into
operation within a month of the start of scientific operations at the L1
point.
Once the go ahead is given to initiate the flag campaigns, the
experience gained will be used to adjust the flag thresholds and to fine tune
the responses to the flags. And later, more complex flags will be implemented.