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.