# Solar Orbiter -- Payload Working Group

## Action Completion Form

***[Action ID Number:]{.underline}*** 10.7 (Target Recognition)

***[Responsible Working Group Member:]{.underline}*** Louise K. Harra /
J-F Hochedez

***[Date of Completion:]{.underline}*** 13-Sep-02

***[Action:]{.underline}*** Initiate target recognition, automated
pointing study to assess fully how we cope with this for Orbiter. List
what targets could be selected and the responses. What timing
constraints exist for what targets? What mode changes could be
envisaged? Will require image/data on board inspection and reaction.

***[Report:]{.underline}***

1\. Solar Orbiter context, and general motivations

The Solar Orbiter (S.O.) is a "high resolution mission to the Sun and
inner heliosphere". There are therefore several large-format imaging
devices anticipated onboard. Small phenomena are expected to be highly
dynamical, and high cadences are consequently requested. The associated
scientific observational needs, and data production potentials are thus
huge.

S.O. is also an Encounter Mission. The amount of time spent at
perihelion or at high latitudes is limited and needs to be optimised.
Additionally, the Sun is non-stationary: interesting events are
sporadic.

Finally, a last crucial ingredient to the mission fulfilling strategy is
the intermittent contact, and rather low telemetry. Around perihelion,
or when hidden by the Sun itself, S.O. has no contact with Earth. A
large solid-state memory (240 GB) is foreseen and meant to record the
observations during this recurrent phase. At other moments, the contact
with Earth is established at a variable rate depending on orbital
configurations and data loss policy. Tele-commands can then be sent, and
the memory buffer can be dumped. The cumulated downlink capability is
however changing by a factor 7 from SO-orbit to SO-orbit.

In the next section, we study how these goals and restrictions can be
made more consistent by appropriate use of data processing and
singularly of target recognition.

2\. Automated pointing

The operations are assumed to be organized as Joint Operation Programs
(JOPs). With mission focus on high resolution, and given the limited
fields of view of some instruments, several JOPs are expected to deal
with small objects such as spicules, individual loops, blinkers,
explosive events, brightenings or coronal hole boundaries. Since these
have vertical extensions, and lifetimes of the order of hours or even
minutes, their exact location cannot be known from Earth when S.O. is
out of the Sun-Earth line, and cannot be relayed to S.O. in any case
during the out-of-contact encounter periods. Thus, on-board target
recognition would be extremely valuable. Pointing through a concentric
target recognition scheme (e.g. FSI-\>VIM-\>HRI-\>EUS) would optimise
the JOP target selection, but a simple location hint from either FSI or
VIM would already provide immense benefits. Other positional information
from spacecraft such as STEREO should also be further evaluated. After
target selection, the tracking could be left to orbital and nominal
solar rotation considerations, or alternatively assigned to an imager
through a closed loop if the altitude is high and unknown.

3\. Flags, and JOP triggering

The implementation of lookout procedures from large field of view
instruments such as FSI and VIM will enhance the mission scientific
return. Some solar phenomena are somewhat infrequent: flares, CMEs,
prominence eruptions, acoustic waves, Moreton waves, active region
morphological reconfigurations, etc. There is little chance that a CME
or a flare be well observed if its passing through the instrument field
of view is left entirely to luck. Interesting objects with related JOPs
should be triggered by simple yet robust algorithmic watching schemes.
Their respective priority will be made a function of the observations
already made, so that only certain levels of interest interrupt more
deterministic/synoptic JOPs. In this way, it allows S.O. to grab
intermittent events with negligible statistical drawback on other
systemic goals. Currently, robust algorithms are in place to search for
flares, and the brightest region in a field of view. Many other
potential targets were studied during the flag implementation of SOHO.

4\. A posteriori data selection

To cope with the memory and telemetry limitations, data
selection/filtering can be foreseen. The memory buffer size will be
fixed, but the telemetry will vary across orbit cycles. The bottleneck
can potentially be in memory and in the telemetry dumping at different
times.

It is recommended that the first problem be solved by fast in-line
selection of the data during the encounter phase. Such an automated
procedure would aim at having the memory filled by the most valuable
data just before the new telemetry contact period is established.
Another advantage of this is the non-causal recording, i.e. the
possibility to keep and downlink the observations ahead of the event of
interest. Insights on flare or CME initiation will be gained. Note that
in this case (memory bottleneck), additional observations can be done
and downlinked during the following non-encounter stage since there is
an excess of telemetry relative to memory.

If on the contrary, the telemetry is short, additional processing time
will be dedicated to select onboard S.O. the most valuable data. This
screening can be done with more advanced algorithms as compared to the
in-line filtering, since there is more time and less data to consider.

5\. Autonomy in the onboard software

Recent techniques in software have been developed in order to make
onboard software systems safe but yet extremely flexible. The
flexibility allows the user on the ground to effectively upload their
own software, instead of only changing variables within the existing
software, as is generally the case. It is a major extension to the idea
of a deferred command store containing time tagged observation sequences
designed on the ground and then uploaded. A 'virtual CPU' is effectively
implemented onboard. Flexibility then comes from designing or adapting
sequences on the ground during flight. These are then fully checked out
on a simulator before uploading them to the instrument. This approach is
used by some instruments on-board SOHO.

6\. Reliability

The above \'virtual CPU\' is considered to be inherently reliable yet
flexible because of its design philosophy. The on-board code is
relatively simple and easy to check out prior to launch. The potentially
complex command sequences can be checked out thoroughly on the ground
before upload. They can also be designed or refined once the mission has
started and the necessary knowledge for optimal observing has been
acquired.

The long out-of-contact periods that S.O. will encounter has
implications for ground testing. In particular, it will not be practical
to perform a realistic \'soak test\', where the software is left running
for an operationally significant number of days looking for \'bugs\'
that only emerge after a period of time e.g. counters overflowing,
obscure \'race conditions\'. A possible solution to this problem is to
deliberately \'reboot\' the software at a convenient moment (e.g. at the
end of an exposure) - and thus resetting all counters etc to their
initial values. This reduces the time for a \'soak test\' to be of the
order of the longest possible exposure.

It would be good practice to run the observation control software on a
separate CPU to that of any software of a more \'bookkeeping\' nature,
in order to keep the level of interconnection down between these two
functions, with the consequent reduction in potential \'crash\'
conditions

7\. Error Correction

In view of the extreme environment to which the instrument will be
subjected, it is likely that the data will be subject to noise
corruption. It will therefore probably be necessary to have some form of
forward error correction. This is where the data is split up into k-bit
blocks, and (n-k) check bits are added to each block. These check bits
are then used on reception to detect and correct any corruption.
Commercial cards are likely to be available for this type of correction.

All instruments will be subject to this problem. It would therefore seem
sensible if such error correction for the transmitted data was added by
the spacecraft rather than by each instrument separately.

However, assuming that it will not be economic to have the ideal
quantity of radiation hard memory on-board, it will be necessary for
each instrument to have some error correction check bits embedded in all
memory resident data/code. It would then be necessary to have a small
piece of code (resident in radiation hard memory) to sweep the
tables/code and repair any damage.

It should be noted that there are limitations to this process. It would
seem intuitive that as the more check bits are added it should be
possible to correct more and more errors. However, because of the
increase in bandwith, the probability of error increases i.e. the check
bits are themselves subject to error. Therefore it becomes more
difficult (and presumably expensive) to design good codes to deal with
the increasing probability of error.

8\. Feasibility issues

The feasibility is twofold:

\* Can reliable software be implemented onboard and on-ground to fulfil
the above requirements and,

\* Are the spacecraft pointing capabilities (reaction time, safety
issues) compatible with the above requirements?

There is no answer to the first issue yet, because each specific solar
event category needs an adequate algorithm. The feasibility of its
implementation will then depend on the CPU available on S.O. We are
confident that the most basic flags (flare detection) can be built in SO
in a straightforward way.

The second issue will require evaluating the attitude control with
respect to the typical event durations. Can the spacecraft be repointed
autonomously in a few minutes?

9\. Actions

\- determine from the scientific requirements what flags will be
required and determine algorithms for these.

\- investigate the spacecraft pointing capabilities

\- investigate a flexible onboard software system

\- investigate the type of error correction that would be suitable for
the orbit of Solar Orbiter.

***[Conclusion:]{.underline}***

The invaluable profit of autonomous target recognition onboard SO has
been demonstrated. The feasibility cannot be insured as long as target
recognition tests have not been made on systems with equivalent
processing power. The attitude control parameters need also to be known.

A general word of caution is given about the safety issues related to
self-pointing of the spacecraft, which will occur whether target
recognition is implemented or not.

***[References:]{.underline}***