DesignFest Home

Event Logging

A Flight/Ground/Test Event Logging Facility


[ Home | Problem Collection | Results for this problem ]

Prepared by

Daniel Dvorak (Jet Propulsion Laboratory, California Institute of Technology)


Domain Description

Desired Program

Terminology

Detailed Requirements

Non Requirements

Use Cases


Domain Description

The onboard control software for spacecraft such as Mars Pathfinder and Cassini is composed of many subsystems including executive control, navigation, attitude control, imaging, and telecommunications. The software in all of these subsystems needs to be instrumented for several purposes: to report required telemetry data to Earth, to report warnings and errors, to verify internal behavior during system testing, and to provide ground operators with detailed data when investigating in-flight anomalies. These reportable events can range in importance from purely informational events to major errors. It is desirable to provide a uniform mechanism for reporting such events and controlling their subsequent processing.

In the domain of deep-space missions there are practical limits to how much event data can be saved and transmitted. First, radiation-hardened flight processors are several years behind the speed and memory of their commercial cousins, with most of the memory intended for science data. Second, downlink rates from deep space to Earth can be very low (e.g., ~300 bps from Pluto using X-band transmission from a 2-meter spacecraft antenna), so it's impractical to send everything. Third, the new breed of semi-autonomous spacecraft may contact Earth only once a week, so the least important data may have to be deleted to make room for more important data, particularly data from science instruments.

The relative importance of any particular event depends on several factors. Program context, such as the distinction between a warning and an error, will rank some events as inherently more important than others. Some faults can cause an event to recur at a high rate, but this must not be allowed to flood the memory pool. Some events may be of low importance when first reported but suddenly become more important when a subsequent error event gets reported. Some events may be so routine that they need not be saved and reported unless specifically requested by ground operators.

When an event is downlinked to Earth, it will be processed automatically for display, archiving, possible alerting, and possible historical summary or other analysis. As such, an event should be represented in a way that facilitates automated processing rather than manual inspection.

The Desired Program

Your task is to design an object-oriented event logging facility (ELF) that spacecraft programmers will use to instrument flight code, that ground operators will control during mission operations to select different levels of logging, and that system test tools will connect to in order to monitor and audit test results. As such, you are designing a facility that spans the flight, ground, and test domains. There are five main elements to be designed:

You may assume that a Data Transport subsystem exists for uplinking commands from ground to spacecraft and for downlinking data from spacecraft to ground. You may also assume that a Data Management subsystem exists for saving data products such as events and making them available to other subsystems (such as Data Transport) as needed.

Terminology

An event is any noteworthy state, as determined by a system engineer or designer or developer. For example, a bus voltage below 22 volts or a memory pool over 98% full might be considered noteworthy states. An event is said to have occurred (in a software sense) when it is detected in a conditional statement and can therefore be acted upon. An event occurrence is said to have been signaled when an Elf signaling mechanism has been called. A signaled event is said to have been logged if an event record is created, submitted to Data Management, and accepted, subject to an "entry policy". A data product is a transportable object that can be stored by Data Management and downlinked by Data Transport. An event object is a data product containing information describing the occurrence of a particular event. An event type or event class is a data type that specifies the kinds of data that describe an event occurrence. An event identifier is a label for a kind of event. (An event identifier is useful in distinguishing among different kinds of events that use the same event type.) An event severity is a measure of the level of importance of an event occurrence. An entry policy controls what signaled events are logged. As an example, a policy may control entry based on event type, event severity, event identifier, frequency of event occurrences, and equality to the previous event of this type. A retention policy controls how long a logged event is retained. As an example, a policy might depend on factors such as age and number of currently retained events.

Detailed Requirements

Non Requirements

  1. There is no limit on the number of event types that may be defined.
  2. There is no requirement for a signaling interface that can be conditionally compiled down to zero run-time overhead, i.e., compiled out of existence.
  3. The preceding requirements deliberately do not prescribe or constrain how exceptions might be used to signal errors. The use of exceptions for error handling is considered an orthogonal issue.
  4. There is no requirement for Elf to maintain statistics such as the number of times that an event condition has been checked.
  5. There is no requirement for Elf to provide a way to force the occurrence of an event, such as for testing purposes.

Use Cases

  1. A programmer defines an application-specific event class.
  2. A programmer instruments source code to signal an event if it occurs.
  3. A running application program signals occurrence of an event.
  4. An Elf signaling mechanism checks the entry policy.
  5. Data management accepts an event object for logging.
  6. A ground program tabulates events as they arrive, sorting them by severity.
  7. A ground operator adjusts the tunable parameters of a specific policy.



Last updated by Torsten Layda, SWX Swiss Exchange, DesignFest® Webmaster.