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
Client
:The component that is responsible for collecting and forwarding the telemetry data. TelemetryItem
:The abstract interface that characterizes a component that can collect and format a single telemetry item. ConcreteTmComponent
:Component implementing interface TelemetryItem
that represents a specific and concrete component that provides a single telemetry item.
Collaborations
The typical operational scenario for this design pattern is:
- a client component is configured with a list of telemetry items components and, when it is activated, it goes through the list and retrieves the telemetry items one by one and uses them to assemble the telemetry frame.
Consequences
-
Clients are decoupled from the format and content of the telemetry items: they only see components of
abstract
TelemetryItem
type. Changing the content or layout of single items has no impact on the component that processes the telemetry data. - It is necessary to create a concrete class for each telemetry item. This may lead to a proliferation of classes.
Applicability
This design pattern is useful when:
- the telemetry data are best conceptualized as a sequence of independent bytes and there is a need to decouple their management from their content and layout.
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:
- TelemetryItemabstract interface -->
TelemetryPacket
,StructuredTelemetryPacket
,PUSTelemetryPacket
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