Svc::TlmChan Component

1. Introduction

The Svc::TlmChan Component is used to store telemetry values written by other components. The values are stored in serialized form. The data is stored as a set of telemetry channels in a table. The data can be individually read back or periodically pushed to another component for transporting out of the system. Svc::TlmChan is an implementation of the Svc::TlmStore component in the Svc/Tlm directory.

2. Requirements

The requirements for Svc::TlmChan are as follows:

Requirement	Description	Verification Method
TLC-001	The Svc::TlmChan component shall provide an interface to submit telemetry	Unit Test
TLC-002	The Svc::TlmChan component shall provide an interface to read telemetry	Unit Test
TLC-003	The Svc::TlmChan component shall provide an interface to run periodically to write telemetry	Unit Test
TLC-004	The Svc::TlmChan component shall write changed telemetry channels when invoked by the run port	Unit Test

3. Design

3.1 Context

3.1.1 Component Diagram

The Svc::TlmChan component has the following component diagram:

3.1.2 Ports

The Svc::TlmChan component uses the following port types:

Port Data Type	Name	Direction	Kind	Usage
Svc::Sched	Run	Input	Asynchronous	Execute a cycle to write changed telemetry channels
Fw::Tlm	TlmRecv	Input	Synchronous Input	Update a telemetry channel
Fw::Tlm	TlmGet	Input	Synchronous Input	Read a telemetry channel
Fw::Com	PktSend	Output	n/a	Write a set of packets with updated telemetry

3.2 Functional Description

The Svc::TlmChan component has an input port TlmRecv that receives channel updates from other components in the system. These calls from the other components are made by the component implementation classes, but the generated code in the base classes takes the type specific channel value and serializes it, then makes the call to the output port. The Svc::TlmChan component can then store the channel value as generic data. The channel values are stored in an internal double-buffered table, and a flag is set when a new value is written to the channel entry.

When a request is made for a nonexistent channel, the call will return with an empty buffer in the Fw::TlmBuffer value argument. This is to cover the case where a channel is defined in the system, but has not been written yet. If the channel has not ever been defined, there is no way to programmatically determine that from the TlmGet port call.

The implementation uses a hashing function that is tuned in the configuration file TlmChanImplCfg.hpp. See section 3.5 for description.

3.3 Scenarios

3.3.1 External User Option

This diagram shows the scenario where telemetry packets are generated for an external user:

3.3.2 Telemetry Database Option

This diagram shows the scenario where telemetry packets are stored and retrieved as a database:

3.4 State

Svc::TlmChan has no state machines.

3.5 Algorithms

In order to speed up lookups for storing and reading telemetry channels, a simple hash function is used to select a location in an array of hash table slots. A configuration value in TlmChanImplCfg.h defines a set of hash buckets to store the telemetry values. The number of buckets has to be at least as large as the number of telemetry values defined in the system. The number of channels in the system can be determined by invoking make comp_report_gen from the deployment directory. The number of has table slots TLMCHAN_NUM_TLM_HASH_SLOTS and the hash value TLMCHAN_HASH_MOD_VALUE in the configuration file can be varied to balance the amount of memory for slots versus the distribution of buckets to slots. See TlmChanImplCfg.h for a procedure on how to tune the algorithm.

4. Dictionaries

TBD

5. Module Checklists

Checklist
Design
Code
Unit Test

6. Unit Testing

To see unit test coverage run fprime-util check --coverage

7. Change Log

Date	Description
6/23/2015	Design review edits
7/22/2015	Design review actions
9/28/2015	Unit Test Review additions