Skip to content
Andrea Bulgarelli edited this page Jul 26, 2013 · 8 revisions

PacketLib

Introduction

The equipment to support the test and calibration of scientific payload requires tailor-made software applications which are similar in overall design and func- tionality but are different in details. These applications must work with CCSDS satellite telemetry. The telemetry (TM) and telecommand (TC) packets are usu- ally divided into two sections: (i) the Header section, which is the only manda- tory part of a packet and contains the packet identifier, the packet length, and the Source Sequence Counter, and (ii) the Data Field section containing either the TM scientific and house-keeping data or the TC data. Although the CCSDS standard does not specify the Data Field internal structure, usually it contains an Header which precedes the data. In turn, the data are are grouped according to a logical sequence of bits which represent well defined information. Based on these considerations, we have designed PacketLib, a C++ software library running on Unix platform which can be used as the basis for building applications able to handle the source packets, down to the level of the single logical structure contained in the data field. The PacketLib1 is aimed at providing a reusable software library for satellite telemetry production and processing and a rapid development for Test Equipment (TE), Electric Ground Support Equipment (EGSE) and Ground Segment applications. It has been developed in the context of the Italian Space Agency (ASI) AGILE space mission (Tavani et al. 2001).

The Architecture

PacketLib is structured into two main layers: the Telemetry Management layer, which interfaces the application, and the I/O Abstraction layer, which interfaces the Operating System. The former allows the application to address the various elements forming the packet data stream, without having to deal with the specific structure. The latter abstracts from the specific input and output mechanisms (e.g., sockets, files, and shared memories). This approach allows a more rapid development of the user applications without having to deal with the kind of input and output sources, which could be changed at run time. Indeed the library could be used either to process or to generate a telemetry stream. PacketLib abstracts the byte stream and all the details characterizing a given packet structure by means of the Object Model represented in the simpli- fied UML class diagram shown in Figure.

packetlib class diagram

In particular, for each kind of packet stream, the library requires one ASCII file containing the description of the overall stream, and a set of ASCII files containing all the parameters defining the various packets, one for each kind of packet identifier. At run time, PacketLib loads these files and builds the representation of the stream and the packets structures into memory.

An Example

The real functioning of the library can be easily understood with the following little coding example:

1. InputPacketStream ips;

2. char* parameters; //set the parameters of input

3. Input *in = new InputSocket(parameters);

4. in.open();

5. ips.createStreamStructure("conf.stream");

6. ips.setInput(in);

7. Packet* p = ips.getPacket();

8. cout << "The value of field 4 of header is " << p->header->getFieldValue(4) << endl;

9. cout << "The value of field 2 of source data field is " << p->dataField->sourceDataField->getFieldValue(2)<< endl;

Line 1 instantiates the object that represents the input byte stream, and line 5 loads the configuration files and creates into memory the byte stream structure and the packets structure (header, data field and fields). Lines 2, 3, and 4 create a telemetry input source and open it. To change the input source without modifying the rest of the code, it is only necessary to modify the line 3 by instantiating another type of input (e.g., InputFile instead of InputSocket), and opening it with the correct parameters. Line 6 links the input byte stream with the input source, and the remaining code extracts the required packet information from the input stream. In particular, line 7 reads a complete packet, whereas lines 8–9 print the value of the various fields. Summarising, lines 2–4,6 provide the I/O Abstraction layer, while lines 1,5,7–9 are related to the Telemetry Management layer. This example demonstrates that with a few lines of code it is possible to connect the application with an input byte stream and to obtain an object representing a packet with all the field value decoded. The library is able to manage either big-endian and little-endian format. For a full comprehension of how the library works, it is necessary to under- stand how the input is processed. After having read the packet Header (which is of fixed length), the library knows the length of the subsequent Data Field. The actual structure of the Data Field is derived by its identifier which consists of one or more fields containing some predefined values. Typically, the APID field of CCSDS standard is used, but the library has not limitation, and allows identifiers which include others fields (e.g., in the AGILE case the Type/Subtype fields of the Data Field Header). The identification of the various packets is performed by looking in the packets for one of the possible identifiers defined in the *.packet ASCII files. Identified packets are unpacked and the various fields are read into the packet structure defined in the *.packet files, where can be directly addressed as shown in lines 8–9. In the negative case, an object representing a generic not recognized packet is created, where the Data Field byte sequence is copied without any structure.

Clone this wiki locally