Increasing complexities in satellite missions require the telecommand (TC) and telemetry (TM) transmission and the data structures within the telecommands and telemetries to be designed to meet the complex mission requirements. Building complex data structures yields a heavy work load on the development stage, while transmission of such data frames consumes a signi cant amount of time period of the available space link interval. In order to respond these challenges, a metadata model which is able to be generated through XML formation, together with the TC encoder, TM decoder (on the ground station), TC decoder and TM encoder (on the ight SW (FSW)) is developed in this work. This metadata model enables easy production of complex telecommands and telemetries composed of various combinations of eld types and nested structures. O zet. Uydu gorevlerindeki karmas kl klar n artmas , uzkomut ve uzolcum iletiminin ve uzkomut - uzolcum veri yap lar n n karmas k gorev gereksinimlerine de cevap verebilir sekilde tasarlanmas n gerektirmektedir. Karmas k veri yap lar insa etmek yaz l m gelistirme surecine ag r bir yuk getirmekteyken, bu tur veri paketlerinin iletimi de mumkun olan uydu baglant s suresinin ciddi bir k sm n tuketmektedir. Bu zorluklara cevap vermek uzere XML duzeni arac l g yla kodu uretilebilen bir meta-veri modeliyle birlikte yer istasyonunda uzkomut kodlay c , uzolcum cozucu, ucus yaz l m nda uzkomut cozucu, uzolcum kodlay c gelistirdik. Bu meta-veri modeli, veri tiplerinin cesitli kombinasyonlar ndan ve ic ice yap lardan olusan karmas k telekomutlar n kolayca uretilmesini mumkun k lmaktad r. Anahtar kelimeler: meta-veri uzkomut uzolcum cozucu uzay gorevleri.
kod
Space missions are getting more and more complex in the recent years, such that,
space missions pose hard challenges re ected through a multitude of dependent
parameters [
Satellite communication system SW design and implementation is a huge
work load, which should be based on modularity as much as possible for the SW
to be easily tailored for new satellite systems. The required modularity should
enable easy tailoring the SW system through the con guration les stored in
databases rather than making modi cations on the code itself [
In 2004, Simon et. al. published the XTCE - an XML based standard for the
mission operation databases - which constitutes a basis for our meta-data model
[
In this work, we propose a tailored version of the XTCE approach, which has a hierarchical architecture enabling code generation, to de ne the telecommands and the telemetries together with all the subcomponents. Once a TC or TM is de ned in XML format with respect to our metadata model, then the metadata code for the TC or TM can easily be generated. The modularity of this metadata structure enables quickness and easiness in populating di erent versions of telecommands and telemetries. This metadata model can easily be integrated with the TM and TC encoders and decoders to be used in FSW and ground station software (GSW). Telecommands and telemetries are called as \data frame" in next chapters for simplicity. 2
The metadata is built for all the data frame (TC and TM) structures in a hierarchical manner in XML formation for them to be programmatically populated. All the metadata are stored in both the onboard computer and the ground station. The metadata representing a TC is utilized by the encoder module of the GSW, which generates the bit stream. The generated bit stream is passed to the next layer to be transmitted to the satellite. Same methodology is applied for the TM delivery: The metadata representing a TM frame is used by the TM encoder module of the FSW, for the corresponding bit stream to be generated. Once the TM bit stream is generated, it is forwarded to the next layer to be transmitted to the ground. Decoding of a TM by the GSW, and a TC by the FSW are handled in a similar manner. 2.1
Field descriptions constitute the biggest part of the metadata. Field descriptions contains all the information related to the component it refers to. Each description consists of the following: { descriptionType: eld or array { isConditional: The ag that represents whether the existence of the related eld is dependent to a condition or not. { conditionDescription: Details of the condition on which the existence of the eld in question depends. { eldData: Includes the decription of a single element ( eld). o set: Number of bytes before this eld in the encapsulating structure in the metadata. nativeFieldType: Enumerator representing the primitive type of the eld in the output structure of the decoder or input structure of the encoder. encodedFieldType:Represents how the native eld is encoded (e.g. unsigned, twos complement, and etc.) eldBitLength: Size of the elds in bits eldEndianness: Represents the bit ordering of the eld. polynomialCoe cientsIndex: The index of the polynomial coe cients in the polynomial coe cients multidimensional array, to be applied on the raw eld value to obtain the corresponding engineering value. rangeIndex: The index of the range description in the range descriptions array, which enables range validation on the eld in question. Negative value is assigned to rangeIndex if there is no need for a range check. { arrayData: Includes the decription of an array. arrayStartO set: Number of bytes in the encapsulating structure before the rst element of this array isSizeFieldConstant: The ag which shows whether the array size is constant or located in a position in the metadata constantArraySize: If the isSizeFieldConstant ag is \True", then the array size is written in the constantArraySize eld. arraySizeFieldO set: If the isSizeFieldConstant ag is \False", arraySizeFieldO set shows from where to read the array size information in this metadata. arraySizeFieldO set is relative to the array level in which this array is nested, or absolute (relative to the start of the upper layer data frame structure) if there is no nesting. arraySizeFieldO set: The enumerator which represents the type of the array size eld. It is the same enumerator with the nativeFieldType of the eldData. arrayElementSize: Number of bytes allocated in the output structure of the decoder or input structure of the encoder per element of the array in question. arrayDescriptionSpan:Number of component descriptions for the array in question. It is used to understand where the descriptions of the next element of the data to be transferred begins in the metadata. Only one of the components eldData and arrayData can exist in a component description, since a component in the data frame can either be an array, or a single eld. But each element of array may contain another array together with a eld, which is called \nested array". 2.2
When the isConditional ag of a description is \True", the described element may or may not exist in the data frame bit stream depending on the condition. conditionDescription eld in the metadata describes how to apply a conditional check on the related eld or array. A conditionDescription is composed of the following components: { navigationParameters: A set of parameters through which the encoder or decoder module is supposed to compute the address of the eld value on which the condition check is going to be applied. { conditionFieldType: Primitive type of the condition eld { conditionValue: The value which will be used to determine the existence of the eld in question The pathway in applying a condition check on a eld is as follows: 1. Calculate absolute o set of the eld which is going to be checked, 2. Retrieve value from the eld, 3. Apply equality check between the eld value and the conditionValue, 4. If values are equal, then the described component (array or eld) exists in the data frame bit stream, 5. If not, the described component is not present in the data frame bit stream. An important detail about retrieving a value by using the absolute and relating o set values is that the o setting should be related to a eld which is already parsed from the data frame bit stream (for decoding), or written to the data frame bit stream (for encoding). 2.3
Calibration is the conversion of a raw value to its corresponding engineering
value. This is generally needed when it is more e cient to send the raw value
together with the calibration parameters when compared to sending the resulting
engineering value [
All the coe cients are stored in a single array. The eld which will be calibrated has the index (stored in polynomialCoe cientsIndex )for the polynomial coe cients table. If no calibration is to be applied, polynomialCoe cientsIndex is set to a negative number. The polynomial coe cients table is an array of polynomialCoe cients elements. Each polynomialCoe cients element is composed of: { A variable for the number of coe cients, { A pointer for the reaching the rst polynomial coe cient on the coe cients array.
Once the calibration parameters are accessed, then the engineering value is computed simply as in the following: e = n 1 X c[i]ri i=0 where; n is the number of polynomial coe cients associated with the eld in question, c is the array of polynomial coe cients, r is the raw value, e is the engineering value. 2.4
Range check is a protective process before encoding or decoding a data frame. Range check is applied on a eld in the data frame if its description indicates a range check necessity (i.e., rangeIndex has a non-negative value in the related eld description). Range descriptions array is composed of RangeDescription objects. A RangeDescription object has the following attributes: (1) { rangeType: Type of the range check to be applied (e.g. lower limit check, upper limit check and etc.) { rangeOperationParameters: The parameters of the range check operation like the lower and upper limits, or the primitive type of the limit parameters.
A eld, value of which is 20, should pass the range test given on Table 1: When the range test of any eld of the data frame fails, the overall data frame is discarded and some alert mechanisms speci c to the application should be initiated. An array description is followed by its elements' description(s) in the metadata. Elements of an array may be of primitive types, structured types, or combinations of primitive and structured types. Figure 1 demonstrates a single level (array composed of non-array elements) array description. Each element of the given sample array is a structured type, which is composed of two primitive type elds. It is also worth emphasizing that any integer element of the array which is encoded in the data frame bit stream with n bits, may be represented with m bits signed integer position in the upper layer structure (output of the decoder or input of the encoder), where m is larger than n. If any sub- eld of an array is also an array, this architecture is called \nested array". The metadata structure we propose provides a exible nested array definition. Before giving an example of nested array description, it is needed to mention the \array level info" table. When decoding or encoding an array, the information necessary to use with the o set values to compute the absolute location of any eld in the higher level structure are kept in a table called \array level info". Number of entities in this structure gives the array level in which the encoding or decoding process is being carried on.
A graphical representation of a nested array description is given in Figure 2. Each element of the outer array consists of a 16 bits signed integer and an array. The inner array consists of unsigned integers (encoded with 8 bits in upper layer structure). The eld descriptions metadata is provided to the encoder or decoder within a codec table. One can de ne the codec table as the metadata of the eld descriptions metadata. Components of the codec table is given below: { Number of eld descriptions & eld descriptions array, { Number of range descriptions & range descriptions array, { Number of polynomial coe cients & array polynomial coe cients, { Byte parsing direction.
Finally, considering the TC transmission; a TC bit stream is transmitted from GS to the FSW together with the codec table for the FSW to decode the TC bit stream. Similarly, GS utilizes the codec table to encode the upper layer TC structure to the TC bit stream with the minimum number of bits to represent the whole data. Block diagrams of TC encoding in GS, and TC decoding in FSW are given in Figure 3 and Figure 4, respectively. The opposite direction of the same pathway is applied in TM transmission.
In this work, we developed a metadata structure which guides the GSW and the
FSW through the encoding and decoding of data frames. The proposed
metadata structure minimizes the bit length of the transmitted data frame, reducing
the bandwidth needed per data frame, which is a critical parameter especially
for the LEO satellites [