Telemetry Item Design Pattern

Intent

Decouple the collection of a set of Telemetry Items from the content of these Telemetry Items.

Based On

This is pattern is based on the principle of abstract coupling.

Motivation

Virtually all on-board systems generate telemetry data. The telemeterable design pattern proposes a solution to the problem of telemetry collection that is suitable for the case where telemetry is seen as made up of a set of telemetry images generated by the various objects that make up the on-board software. In that case, the problem of telemetry management is the problem of managing these telemeterable objects in an application-independent manner.

In some on-board applications (especially in those that have a low level of complexity), however, the telemetry data are best conceptualized as a sequence of independent words where each word carries some specific and self-contained information. In this case, the problem of telemetry management is the problem of assembling and collecting the telemetry items in an application-independent manner. The telemetry item design pattern addresses this second problem.

Dictionary Entries

The following abstractions or domain-wide concepts are defined to support the implementation of this design pattern:

Structure

This design pattern is built around an abstract interface to represent the telemetry item abstraction. The TelemetryItem interface represents an object that is capable of collecting and assembling the information that goes into an individual telemetry item. This interface defines two key operations. Operation update directs the telemetry item to collect the telemetry information for which it is responsible and to internally assemble it in a format suitable for inclusion in the telemetry stream. Operation getItem returns the telemetry information that was thus constructed. An additional operation isValid is provided to ask the telemetry item component to verify whether the telemetry information it stores is valid.

The TelemetryItem interface serves as a generic interface through which a client component can control the telemetry data acquisition process in an application-independent manner. The client maintains a list of TelemetryItem objects and, when it is activated, it goes through the list, asks each object to update its telemetry item and acquires the telemetry item and writes it to the telemetry channel. The list of TelemetryItem objects is set up as part of the configuration process during application initialization.

Participants

Collaborations

The typical operational scenario for this design pattern is:

Consequences

Applicability

This design pattern is useful when:

Implementation Issues

How is a "telemetry item" to be represented in practice? In many cases it could be a primitive type - an integer, a short integer or a byte - which is returned by method getItem. However, it could also be an instance of a complex type in which case a means must be provided to serialize it to allow its being written to the telemetry channel (that is often byte-oriented). If this complex type becomes very elaborate, then this pattern becomes identical to the telemeterable pattern.

OBS Framework Mapping

The implementation of this design pattern in the OBS Framework is supported by the following classes:

Sample Code

Consider a simple application where a telemetry frame consists of four words. Each word represents a telemetry item. This application would need to define four concrete classes implementing the TelemetryItem interface. Their structure could be as follows:

    class Word_1: TelemetryItem {

        unsigned short tmWord;

        void update() {

        . . .  // acquire data that go into TM Word 1 and store them
        . . .  // in tmWord according to specified layout

        }

        short getItem() {
            return tmWord;
        }


        bool isValid() {
            return true;  // no validitiy check is performed
        }

    }
The above implementation assumes that a telemetry item consists of an unsigned 16-bits integer and that no validity check is performed upon it.

Remarks

None

Author

A. Pasetti (P&P Software)

Last Modified

2003-06-20

Contact Us | The OBS Framework Project