Environmental Engineering Reference
In-Depth Information
2.1.6 Downlinked Data Capture
Capture of downlinked telemetry data is rather straightforward and highly
standardized. This ground system function will become steadily more auto-
mated via COTS tools.
2.1.7 Performance Monitoring
Monitoring of spacecraft performance and H&S by checking the values of
telemetry points and derived parameters is a function that is currently shared
between flight and ground systems. While critical H&S monitoring is an on-
board responsibility (especially where triggers to safemode entrance are con-
cerned), the ground, in the past, has performed more long-term nonrealtime
quality checking, such as hardware component trending and accuracy analysis,
as well as analysis of more general performance issues (e.g., overall observing
eciency).
2.1.8 Fault Diagnosis
Often the term “FDC” has been used in connection with spacecraft H&S
autonomy. Such terminology tends to conceal an important logical step in the
process, which in the past has been exclusively the preserve of human systems
engineers. This step is the diagnosis of the fundamental cause of problems
based on measured “symptoms.”
Traditionally, prior to launch, the systems and subsystem engineers would
identify a whole host of key parameters that needed to be monitored on-
board, specify tolerances defining in-range vs. out-of-range performance, and
identify FSW responses to be taken in realtime and/or FOT responses to be
taken in near-realtime. But what has actually occurred is that the engineers
have started with a set of failure scenarios in mind, identified the key param-
eters (and their tolerances/thresholds) that would measure likely symptoms
of those failures, figured out how to exclude possible red-herrings (i.e., differ-
ent physical situations that might masquerade as the failure scenario under
consideration), and (in parallel) developed corrective responses to deal with
those failures. So the process of transitioning from the symptoms specified by
the parameters to the correction action (often a static table entry) that con-
stitutes the diagnosis phase conceptually actually occurs (prelaunch) in the
reverse order and the intellectual content is sketchily stored rigidly onboard.
In the postlaunch phase, the systems engineers/FOT may encounter an
unanticipated problem and must perform a diagnosis function using the
telemetry downlinked to the ground. In such cases, operations personnel must
rely on their experience (possibly with other spacecraft) and subject matter
expertise to solve the problem. When quick solutions are achieved, the pro-
cess often used is that of pattern recognition (or, more formally, case-based
