SIST EN 16603-50-03:2015
(Main)Space engineering - Space data links - Telemetry transfer frame protocol
Space engineering - Space data links - Telemetry transfer frame protocol
This Standard contains the definition for Telemetry Transfer Frames which are fixed-length data structures, suitable for transmission at a constant frame rate on a space data channel.
The Telemetry Transfer Frame provides a standardized data structure for the transmission of space-acquired data over a telemetry space data link.
Usually, the source of the data is located in space and the receiver is located on the ground. However, this Standard may also be applied to space-to-space telemetry data links.
Further provisions and guidance on the application of this standard can be found, respectively, in the following publications:
- The higher level standard ECSS-E-ST-50, Communications, which defines the principle characteristics of communication protocols and related services for all communication layers relevant for space communication (physical- to application-layer), and their basic relationship to each other.
- The handbook ECSS-E-HB-50, Communications guidelines, which provides information about specific implementation characteristics of these protocols in order to support the choice of a certain communications profile for the specific requirements of a space mission..
Users of this present standard are invited to consult these documents before taking decisions on the implementation of the present one.
This standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS-S-ST-00.
Raumfahrttechnik - Telemetrieübertragungs-Rahmen-Protokoll
Ingénierie spatiale - Liaisons des données spatiales - Protocole trame de transfert de télémesure
La présente norme contient la définition des trames de transfert de télémesure, qui sont des structures de données de longueur fixe, convenant à la transmission de trames à vitesse constante via un canal de données spatial.
La Trame de Transfert de Télémesure fournit une structure de données normalisée permettant de transmettre des données acquises dans l'espace via une liaison spatiale de données de télémesure.
En règle générale, la source des données est située dans l'espace et le récepteur se trouve au sol. Toutefois, la présente norme peut également être appliquée aux liaisons de données de télémesure entre engins spatiaux.
Les publications suivantes contiennent, respectivement, des dispositions et des préconisations supplémentaires concernant l'application de la présente norme :
• la norme mère ECSS-E-ST-50, « Communications », qui définit les principes des protocoles de communication et des services connexes pour toutes les couches de communication spatiale (de la couche physique à la couche applicative), et décrit leurs relations de base ;
• le manuel ECSS-E-HB-50, « Communications guidelines », qui fournit des informations sur les caractéristiques de mise en œuvre de ces protocoles afin d'orienter le choix d'un profil de communication donné compte tenu des exigences particulières d'une mission spatiale.
Les utilisateurs de la présente norme sont invités à consulter ces documents avant de prendre toute décision quant à sa mise en œuvre.
La présente norme peut être adaptée aux caractéristiques et contraintes spécifiques d'un projet spatial, conformément à la norme ECSS-S-ST-00.
Vesoljska tehnika - Vesoljske podatkovne povezave - Okvirni protokol za prenos telemetrijskih podatkov
Ta standard vsebuje definicijo za okvire prenosa telemetrijskih podatkov, ki so podatkovne strukture fiksne dolžine, primerne za prenos pri stalni hitrosti na vesoljskem podatkovnem kanalu.
Okvir prenosa telemetrijskih podatkov zagotavlja standardizirano podatkovno strukturo za prenos v vesolju pridobljenih podatkov prek telemetrijske vesoljske podatkovne povezave.
Običajno se vir podatkov nahaja v vesolju, sprejemnik pa se nahaja na tleh. Vendar se lahko ta standard uporablja tudi za telemetrijske podatkovne povezave v vesolju.
Dodatne določbe in smernice o uporabi tega standarda je mogoče najti v naslednjih publikacijah:
– v standardu višje ravni ECSS-E-ST-50 (Komunikacije), ki določa glavne značilnosti komunikacijskih protokolov in z njimi povezanih storitev za vse ravni komunikacije, pomembne za vesoljsko komunikacijo (od fizične do aplikacijske ravni), in njihove osnovne medsebojne povezave,
– v priročniku ECSS-E-HB-50 (Komunikacijske smernice), ki zagotavlja informacije o posebnih značilnostih vpeljave teh protokolov za podporo pri izbiri določenega komunikacijskega profila za posebne zahteve vesoljske misije.
Uporabniki obstoječega standarda so vabljeni k ogledu teh dokumentov, preden sprejmejo odločitve o izvajanju trenutnega standarda.
Ta standard se lahko prilagodi posameznim lastnostim in omejitvam vesoljskega projekta v skladu s standardom ECSS-S-ST-00.
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Vesoljska tehnika - Vesoljske podatkovne povezave - Okvirni protokol za prenos telemetrijskih podatkovRaumfahrttechnik - Telemetrieübertragungs-Rahmen-ProtokollIngénierie spatiale - Liaisons des données spatiales - Protocole trame de transfert de télémesureSpace engineering - Space data links - Telemetry transfer frame protocol49.140Vesoljski sistemi in operacijeSpace systems and operations33.200Daljinsko krmiljenje, daljinske meritve (telemetrija)Telecontrol. TelemeteringICS:Ta slovenski standard je istoveten z:EN 16603-50-03:2014SIST EN 16603-50-03:2015en01-januar-2015SIST EN 16603-50-03:2015SLOVENSKI
STANDARD
SIST EN 16603-50-03:2015
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 16603-50-03
September 2014 ICS 49.140
English version
Space engineering - Space data links - Telemetry transfer frame protocol
Ingénierie spatiale - Liaisons des données spatiales - Protocole trame de transfert de télémesure
Raumfahrtproduktsicherung - Telemetrieübertragungs-Rahmen-Protokoll This European Standard was approved by CEN on 11 April 2014.
CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels © 2014 CEN/CENELEC All rights of exploitation in any form and by any means reserved worldwide for CEN national Members and for CENELEC Members. Ref. No. EN 16603-50-03:2014 E SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 2 Table of contents Foreword . 4 1 Scope . 5 2 Normative references . 6 3 Terms, definitions and abbreviated terms . 7 3.1 Terms from other standards . 7 3.2 Terms specific to the present standard . 7 3.3 Abbreviated terms. 8 3.4 Conventions. 8 3.4.1 bit 0, bit N, bit N−N . 8 3.4.2 most significant bit. 8 3.4.3 use of capitals for the names of data structures and fields . 8 4 Overview . 9 4.1 General . 9 4.2 Physical channel . 9 4.3 Master channels and virtual channels . 10 4.4 Sharing transmission resources . 10 4.5 Data fields in the frame . 10 5 TM Transfer Frame . 11 5.1 General . 11 5.2 Transfer Frame Primary Header . 13 5.2.1 General . 13 5.2.2 Master Channel Identifier . 14 5.2.3 Virtual Channel Identifier . 15 5.2.4 Operational Control Field Flag . 15 5.2.5 Master Channel Frame Count . 15 5.2.6 Virtual Channel Frame Count . 16 5.2.7 Transfer Frame Data Field Status . 16 5.3 Transfer Frame Secondary Header . 19 5.3.1 General . 19 SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 3 5.3.2 Transfer Frame Secondary Header Identification . 20 5.3.3 Transfer Frame Secondary Header Data Field . 21 5.3.4 Extended virtual channel frame count . 21 5.4 Transfer Frame Data Field . 22 5.4.1 Overview . 22 5.4.2 General . 22 5.4.3 Packet processing and extraction functions . 23 5.4.4 Asynchronously inserted data . 26 5.5 Operational Control Field . 27 5.5.1 General . 27 5.5.2 Type Flag . 27 5.5.3 Type-1-Report . 27 5.5.4 Type-2-Report . 28 5.6 Frame Error Control Field . 28 5.6.1 General . 28 5.6.2 Frame Error Control Field encoding procedure . 29 5.6.3 Frame Error Control Field decoding procedure . 30 Annex A (informative) Frame error control . 31 Annex B (informative) Changes from ESA-PSS-04-106 . 33 Annex C (informative) Differences from CCSDS recommendations . 36 Annex D (informative) Mission configuration parameters . 37 Bibliography . 42 Figures Figure 3-1: Bit numbering convention . 8 Figure 5-1: TM Transfer Frame format . 13 Figure 5-2: Format of Transfer Frame Primary Header . 14 Figure A-1 : Encoder . 31 Figure A-2 : Decoder . 32
Tables Table 5-1: Major fields in a TM Transfer Frame . 11 Table B-1: Differences in names from ESA-PSS-04-106 for fields in a Telemetry Transfer Frame . 35 Table B-1 : Differences in names from ESA-PSS-04-106 for fields in a Telemetry Transfer Frame . 35
SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 4 Foreword This document (EN 16603-50-03:2014) has been prepared by Technical Committee CEN/CLC/TC 5 “Space”, the secretariat of which is held by DIN. This standard (EN 16603-50-03:2014) originates from ECSS-E-ST-50-03C. This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by March 2015, and conflicting national standards shall be withdrawn at the latest by March 2015. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights. This document has been prepared under a mandate given to CEN by the European Commission and the European Free Trade Association. This document has been developed to cover specifically space systems and has therefore precedence over any EN covering the same scope but with a wider domain of applicability (e.g. : aerospace). According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.
SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 5 1 Scope This Standard contains the definition for Telemetry Transfer Frames which are fixed-length data structures, suitable for transmission at a constant frame rate on a space data channel. The Telemetry Transfer Frame provides a standardized data structure for the transmission of space-acquired data over a telemetry space data link.
Usually, the source of the data is located in space and the receiver is located on the ground. However, this Standard may also be applied to space-to-space telemetry data links.
Further provisions and guidance on the application of this standard can be found, respectively, in the following publications:
• The higher level standard ECSS-E-ST-50, Communications, which defines the principle characteristics of communication protocols and related services for all communication layers relevant for space communication (physical- to application-layer), and their basic relationship to each other.
• The handbook ECSS-E-HB-50, Communications guidelines, which provides information about specific implementation characteristics of these protocols in order to support the choice of a certain communications profile for the specific requirements of a space mission. Users of this present standard are invited to consult these documents before taking decisions on the implementation of the present one. This standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS-S-ST-00. SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 6 2 Normative references The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revisions of any of these publications, do not apply. However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references the latest edition of the publication referred to applies.
EN reference Reference in text Title EN 16601-00-01 ECSS-S-ST-00-01 ECSS system – Glossary of terms EN 16603-50-01 ECSS-E-ST-50-01 Space engineering – Space data links – Telemetry synchronization and channel coding EN 16603-50-04 ECSS-E-ST-50-04 Space engineering – Space data links – Telecommand protocols, synchronization and channel coding
CCSDS 133.0-B-1
Space Packet Protocol – Blue Book, Issue 1, September 2003
CCSDS 135.0-B-3
Space Link Identifiers – Blue Book, Issue 3, October 2006
SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 7 3 Terms, definitions and abbreviated terms 3.1 Terms from other standards For the purpose of this Standard, the terms and definitions from ECSS-ST-00-01 apply. 3.2 Terms specific to the present standard 3.2.1 idle data data which carries no information, but is sent to conform to timing or synchronization requirements NOTE
The bit pattern of idle data is not specified. 3.2.2 mission phase period of a mission during which specified telemetry characteristics are fixed NOTE
The transition between two consecutive mission phases can cause an interruption of the telemetry services. 3.2.3 octet group of eight bits NOTE 1 The numbering for octets within a data structure starts with 0. NOTE 2 Refer to clause 3.4 for the convention for the numbering of bits. 3.2.4 packet variable-length data structure consisting of higher layer user data encapsulated within standard header information 3.2.5 static unchanged within a specific virtual channel or within a specific master channel NOTE
This Standard contains requirements on the invariability, throughout one or all mission phases, of certain characteristics of the data structures specified in it. SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 8 3.3 Abbreviated terms For the purpose of this Standard, the abbreviated terms from ECSS-ST-00-01 and the following apply: Abbreviation Meaning ASM attached sync marker CCSDS Consultative Committee for Space Data Systems FECF Frame Error Control Field MSB most significant bit TM Telemetry
3.4 Conventions 3.4.1 bit 0, bit N, bit N−N To identify each bit in an N-bit field, the first bit in the field to be transferred (i.e. the most left justified in a graphical representation) is defined as bit 0; the following bit is defined as bit 1 and so on up to bit N-1.
Figure 3-1: Bit numbering convention 3.4.2 most significant bit When an N-bit field is used to express a binary value (such as a counter), the most significant bit is the first bit of the field, i.e. bit 0 (see Figure 3-1). 3.4.3 use of capitals for the names of data structures and fields In this Standard initial capitals are used for the names of data structures and fields.
This enables field names to be easily identified in the surrounding text. For example, the field Transfer Frame Data Field is easier to see than transfer frame data field in text containing words such as frame and data and field. It also prevents ambiguity over where the name begins and ends. For example, there are fields Transfer Frame Secondary Header and Transfer Frame Secondary Header Length. The capitals help the reader to distinguish between the Transfer Frame Secondary Header length (meaning ‘the length of the Transfer Frame Secondary Header’) and the Transfer Frame Secondary Header Length (meaning the field of that name). SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 9 4 Overview 4.1 General The Telemetry Transfer Frame is a fixed-length data structure that provides an envelope for transmitting data units of several types over a telemetry space link. The frame is compatible with the ECSS standard for telemetry synchronization and channel coding defined in ECSS-E-ST-50-01. The telemetry transfer frame protocol can operate in various configurations of the telemetry space link, depending on the telemetry channel coding scheme and security options selected. The correct operation of the protocol can only occur if a high-quality data channel is provided between the peer entities of the protocol. NOTE 1
The Standard for telemetry channel coding, ECSS-E-ST-50-01, defines the coding mechanisms for a high-quality data channel, including frame synchronization and randomization. CCSDS 350.0-G-2 describes the security options. NOTE 2
In this Standard the terms TM Transfer Frame and Telemetry Transfer Frame are used interchangeably, i.e. they are synonyms and have the same meaning as. NOTE 3 Annex D describes the mission configuration parameters within the scope of this Standard. 4.2 Physical channel A data channel carrying a stream of bits in a single direction is referred to as a physical channel. For the TM Transfer Frame specified in this Standard, the value of the Transfer Frame Version Number is constant for all frames of a physical channel. The length of the frames for a given physical channel is fixed for a mission phase. SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 10 4.3 Master channels and virtual channels The TM Transfer Frame supports the division of the physical channel into master channels and virtual channels by means of identifier fields in the frame header. A master channel is identified by the values of the Transfer Frame Version Number and the Spacecraft Identifier. Within a given physical channel, a master channel consists of all the frames that have the same Transfer Frame Version Number and the same Spacecraft Identifier.
For a typical space mission, all the frames on a physical channel have the same value for the Spacecraft Identifier, so in this case there is one master channel on the physical channel. However, multiple master channels can share a physical channel, which, for example, can be the case when one spacecraft is transporting another spacecraft such as a probe. A master channel is divided into virtual channels using the Virtual Channel Identifier field. This is a 3-bit field and therefore supports up to eight virtual channels on a master channel. 4.4 Sharing transmission resources Virtual channels enable one physical channel to be shared among multiple higher-layer data streams, each of which can have different characteristics. The mechanisms and parameters for sharing access by the virtual channels to the physical channel are implementation dependent and not within the scope of this Standard. 4.5 Data fields in the frame Every TM Transfer Frame contains the Transfer Frame Data Field, which is the main data-carrying field in the frame. Within a virtual channel, the length of the Transfer Frame Data Field is static during a mission phase. There are status fields in the frame header that are related to the use of the Transfer Frame Data Field. The Transfer Frame Data Field carries packets or other data units. Additionally to the Transfer Frame Data Field, the TM Transfer Frame has two optional fields for carrying data:
• The Transfer Frame Secondary Header, used to carry fixed-length mission-specific data.
• The Operational Control Field, used to carry status information to control the operation of the telecommand space link or other spacecraft activities.
SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 11 5 TM Transfer Frame 5.1 General a. The TM Transfer Frame shall encompass the major fields, positioned contiguously if present, in the sequence shown in Figure 5-1. NOTE 1 Figure 5-1 shows the format of the TM Transfer Frame. NOTE 2 In the case that TM Transfer Frames are directly submitted to telemetry channel coding, the start of the TM Transfer Frame is always signalled by the attached sync marker (ASM) which immediately precedes the TM Transfer Frame. The ASM is specified in ECSS-E-ST-50-01.
When the TM Transfer Frame is embedded in a Reed-Solomon codeblock or turbo codeblock, the ASM signals the start of both. Table 5-1: Major fields in a TM Transfer Frame Field Presence in TM Transfer Frame Length in bits Transfer Frame Primary Header always present 48 Transfer Frame Secondary Header optional 16, 24, . or 512 Transfer Frame Data Field always present variable Transfer Frame Trailer optional 16, 32 or 48
b. The maximum length for a TM Transfer Frame shall be 2048 octets. c. The TM Transfer Frame shall be of constant length throughout a specific mission phase. NOTE
Because a change of frame length also changes the time interval between the start of successive frames, it can result in a loss of synchronization at the data capture element. SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 12 d. The TM Transfer Frame length shall be in conformance with the specifications contained in the standard for telemetry channel coding, ECSS-E-ST-50-01. NOTE
For some coding schemes, ECSS-E-ST-50-01 limits the TM Transfer Frame length to certain specific values. e. TM Transfer Frames shall be transferred over a physical channel at a constant rate. f. In order to assure correct decoding at the receiving end, the same telemetry channel coding options shall be applied to all TM Transfer Frames of a physical channel. g. At the receiving end, TM Transfer Frames containing detected errors need not be delivered.
h. The handling of TM Transfer Frames containing detected errors shall be specified for each mission or mission phase. NOTE
Depending on the coding scheme in use, errors in a TM Transfer Frame can be detected during the telemetry channel decoding at the receiving end (see ECSS-E-ST-50-01). The Frame Error Control Field specified in clause 5.6 can be used to detect errors in TM Transfer Frames. i. All TM Transfer Frames with the same Master Channel Identifier on a physical channel shall constitute a master channel. NOTE 1 The Master Channel Identifier is defined in clause 5.2.2. NOTE 2 In most cases, the master channel is identical to the physical channel. However, if the physical channel also carries TM Transfer Frames with other Spacecraft Identifiers, a distinction between the master channel and physical channel is made. In this case, multiplexing of TM Transfer Frames with different Spacecraft Identifiers is performed by multiplexing the different master channels on the same physical channel. j. A master channel shall consist of between one to eight virtual channels. k. On a physical channel that carries TM Transfer Frames, all the frames shall have the same Transfer Frame Version Number. NOTE
The TM Transfer Frames specified in this Standard do not share a physical channel with other types of frame.
SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 13
Figure 5-1: TM Transfer Frame format 5.2 Transfer Frame Primary Header 5.2.1 General a. The Transfer Frame Primary Header shall always be present in a TM Transfer Frame. b. The Transfer Frame Primary Header shall consist of six fields, positioned contiguously, in the following sequence: 1. Master Channel Identifier
12 bits 2. Virtual Channel Identifier
3 bits 3. Operational Control Field Flag 1 bit 4. Master Channel Frame Count
8 bits 5. Virtual Channel Frame Count
8 bits 6. Transfer Frame Data Field Status 16 bits NOTE 1 All six fields are always present in a Transfer Frame Primary Header. NOTE 2 Figure 5-2 shows the format of the Transfer Frame Primary Header. NOTE 3 The Transfer Frame Primary Header covers the following main functions: • to identify the data unit as a TM Transfer Frame; • to identify the master channel and virtual channel to which the frame belongs; • to provide a counting mechanism for the virtual channels and the master channel; • to provide status fields related to the data in the Transfer Frame Data Field. SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 14
Figure 5-2: Format of Transfer Frame Primary Header 5.2.2 Master Channel Identifier 5.2.2.1 General a. The Master Channel Identifier shall always be present in a Transfer Frame Primary Header. b. The Master Channel Identifier shall be contained within bits 0-11 of the Transfer Frame Primary Header. c. The Master Channel Identifier shall consist of two fields, positioned contiguously, in the following sequence: 1. Transfer Frame Version Number
2 bits 2. Spacecraft Identifier
10 bits NOTE
Both fields are always present in a Master Channel Identifier. 5.2.2.2 Transfer Frame Version Number a. The Transfer Frame Version Number shall always be present in a Master Channel Identifier. b. The Transfer Frame Version Number shall be contained within bits 0-1 of the Transfer Frame Primary Header. c. The Transfer Frame Version Number shall be set to ‘00’. NOTE
This is the value defined in CCSDS 135.0-B-3 for the Transfer Frame Version Number of a TM Transfer Frame. 5.2.2.3 Spacecraft Identifier a. The Spacecraft Identifier shall always be present in a Master Channel Identifier. b. The Spacecraft Identifier shall be contained within bits 2-11 of the Transfer Frame Primary Header. c. The Spacecraft Identifier shall provide the identification of the spacecraft which is associated with the data contained in the TM Transfer Frame. SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 15 NOTE 1 The Secretariat of the CCSDS assigns Spacecraft Identifiers according to the procedures in CCSDS 320.0-B-4. NOTE 2 Different Spacecraft Identifiers can be assigned for normal operations and for development vehicles using the ground networks during pre-launch test operations, and for simulated data streams. d. The Spacecraft Identifier shall be static throughout all mission phases. 5.2.3 Virtual Channel Identifier a. The Virtual Channel Identifier shall always be present in a Transfer Frame Primary Header. b. The Virtual Channel Identifier shall be contained within bits 12-14 of the Transfer Frame Primary Header. c. The Virtual Channel Identifier shall provide the identification of the virtual channel to which the TM Transfer Frame belongs. NOTE
The order of occurrence of TM Transfer Frames belonging to different virtual channels on a master channel can vary. 5.2.4 Operational Control Field Flag a. The Operational Control Field Flag shall always be present in a Transfer Frame Primary Header. b. The Operational Control Field Flag shall be contained in bit 15 of the Transfer Frame Primary Header. c. The Operational Control Field Flag shall indicate the presence or absence of the Operational Control Field, as follows: 1.
‘1’ Operational Control Field is present; 2.
‘0’
Operational Control Field is not present. d. The Operational Control Field Flag shall be static in the associated master channel or virtual channel throughout a mission phase. NOTE
See clause 5.5.1. 5.2.5 Master Channel Frame Count a. The Master Channel Frame Count shall always be present in a Transfer Frame Primary Header. b. The Master Channel Frame Count shall be contained within bits 16-23 of the Transfer Frame Primary Header. c. The Master Channel Frame Count shall contain a sequential binary count (modulo 256) of each TM Transfer Frame transmitted in a specific master channel. NOTE
This field provides a running count of the frames transmitted through the same master channel. SIST EN 16603-50-03:2015
EN 16603-50-03:2014 (E) 16 d. The Master Channel Frame Count shall not be reset before reaching 255 unless there is a major system reset. NOTE
If the Master Channel Frame Count is reset due to a re-initialisation, the completeness of a sequence of TM Transfer Frames cannot be determined. 5.2.6 Virtual Channel Frame Count a. The Virtual Channel Frame Count shall always be present in a Transfer Frame Primary Header. b. The Virtual Channel Frame Count shall be contained within bits 24-31 of the Transfer Frame Primary Header. c. The Virtual Channel Frame Count shall contain a sequential binary count (modulo 256) of each TM Transfer Frame transmitted through a specific virtual channel of a master channel. NOTE
This field provides individual accountability for the frames of each virtual channel. It can be used to detect gaps in the stream of data carried in the Transfer Frame Data Fields of the frames for a virtual channel. d. The Virtual Channel Frame Count shall not be reset before reaching 255 unless there is a major system reset. NOTE
If the Virtual Channel Frame Count is reset due to a re-initialisation, the completeness of a sequence of TM Transfer Frames in the related virtual channel cannot be determined. 5.2.7 Transfer Frame Data Field Status 5.2.7.1 General a. The Transfer Frame Data Field Status shall always be present in a Transfer Frame Primary Header. b. The Transfer Frame Data Field Status shall be contained within bits 32-47 of the Transfer Frame Primary Header. c. The Transfer Frame Data Field Status shall consist of five fields, positioned contiguously, in the following sequence: 1. Transfer Frame Secondary Header Flag 1 bit 2. Synchronization Flag
1 bit 3. Packet Order Flag
1 bit 4. Segment Length Identifier
2 bits 5. First Header Pointer
11 bits NOTE 1 All these five
...
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Vesoljsko inženirstvo - Vesoljske podatkovne povezave - Okvirni protokol za prenos telemetrijskih podatkovRaumfahrttechnik - Telemetrieübertragungs-Rahmen-ProtokollIngénierie spatiale - Liaisons des données spatiales - Protocole trame de transfert de télémesureSpace engineering - Space data links - Telemetry transfer frame protocol49.140Vesoljski sistemi in operacijeSpace systems and operations33.200Daljinsko krmiljenje, daljinske meritve (telemetrija)Telecontrol. TelemeteringICS:Ta slovenski standard je istoveten z:FprEN 16603-50-03kSIST FprEN 16603-50-03:2014en01-februar-2014kSIST FprEN 16603-50-03:2014SLOVENSKI
STANDARD
kSIST FprEN 16603-50-03:2014
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
FINAL DRAFT
FprEN 16603-50-03
October 2013 ICS 49.140
English version
Space engineering - Space data links - Telemetry transfer frame protocol
Ingénierie spatiale - Liaisons des données spatiales - Protocole trame de transfert de télémesure
Raumfahrttechnik - Telemetrieübertragungs-Rahmen-Protokoll This draft European Standard is submitted to CEN members for unique acceptance procedure. It has been drawn up by the Technical Committee CEN/CLC/TC 5.
If this draft becomes a European Standard, CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
This draft European Standard was established by CEN and CENELEC in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and shall not be referred to as a European Standard. CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels © 2013 CEN/CENELEC All rights of exploitation in any form and by any means reserved worldwide for CEN national Members and for CENELEC Members. Ref. No. FprEN 16603-50-03:2013 E kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 2 Table of contents Foreword . 5 1 Scope . 6 2 Normative references . 7 3 Terms, definitions and abbreviated terms . 8 3.1 Terms from other standards . 8 3.2 Terms specific to the present standard . 8 3.3 Abbreviated terms. 9 3.4 Conventions. 9 3.4.1 bit 0, bit N, bit N−N . 9 3.4.2 most significant bit. 9 3.4.3 use of capitals for the names of data structures and fields . 9 4 Overview . 10 4.1 General . 10 4.2 Physical channel . 10 4.3 Master channels and virtual channels . 11 4.4 Sharing transmission resources . 11 4.5 Data fields in the frame . 11 5 TM Transfer Frame . 12 5.1 General . 12 5.2 Transfer Frame Primary Header . 14 5.2.1 General . 14 5.2.2 Master Channel Identifier . 15 5.2.3 Virtual Channel Identifier . 16 5.2.4 Operational Control Field Flag . 16 5.2.5 Master Channel Frame Count . 16 5.2.6 Virtual Channel Frame Count . 17 5.2.7 Transfer Frame Data Field Status . 17 kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 3 5.3 Transfer Frame Secondary Header . 20 5.3.1 General . 20 5.3.2 Transfer Frame Secondary Header Identification . 21 5.3.3 Transfer Frame Secondary Header Data Field . 22 5.3.4 Extended virtual channel frame count . 22 5.4 Transfer Frame Data Field . 23 5.4.1 Overview . 23 5.4.2 General . 23 5.4.3 Packet processing and extraction functions . 24 5.4.4 Asynchronously inserted data . 27 5.5 Operational Control Field . 28 5.5.1 General . 28 5.5.2 Type Flag . 28 5.5.3 Type-1-Report . 28 5.5.4 Type-2-Report . 29 5.6 Frame Error Control Field . 29 5.6.1 General . 29 5.6.2 Frame Error Control Field encoding procedure . 30 5.6.3 Frame Error Control Field decoding procedure . 31 Annex A (informative) Frame error control . 32 Annex B (informative) Changes from ESA-PSS-04-106 . 34 Annex C (informative) Differences from CCSDS recommendations . 37 Annex D (informative) Mission configuration parameters . 38 Bibliography . 43
Figures Figure 3-1: Bit numbering convention . 9 Figure 5-1: TM Transfer Frame format . 14 Figure 5-2: Format of Transfer Frame Primary Header . 15
Figure A-1 : Encoder . 32 Figure A-2 : Decoder . 33
kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 4 Tables Table 5-1: Major fields in a TM Transfer Frame . 12 Table B-1: Differences in names from ESA-PSS-04-106 for fields in a Telemetry Transfer Frame . 36
kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 5 Foreword This document (FprEN 16603-50-03:2013) has been prepared by Technical Committee CEN/CLC/TC 5 “Space”, the secretariat of which is held by DIN (Germany). This document (FprEN 16603-50-03:2013) originates from ECSS-E-ST-50-03C. This document is currently submitted to the Unique Acceptance Procedure. This document has been developed to cover specifically space systems and will therefore have precedence over any EN covering the same scope but with a wider domain of applicability (e.g. : aerospace). kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 6 1 Scope This Standard contains the definition for Telemetry Transfer Frames which are fixed-length data structures, suitable for transmission at a constant frame rate on a space data channel. The Telemetry Transfer Frame provides a standardized data structure for the transmission of space-acquired data over a telemetry space data link.
Usually, the source of the data is located in space and the receiver is located on the ground. However, this Standard may also be applied to space-to-space telemetry data links.
Further provisions and guidance on the application of this standard can be found, respectively, in the following publications:
• The higher level standard ECSS-E-ST-50, Communications, which defines the principle characteristics of communication protocols and related services for all communication layers relevant for space communication (physical- to application-layer), and their basic relationship to each other.
• The handbook ECSS-E-HB-50, Communications guidelines, which provides information about specific implementation characteristics of these protocols in order to support the choice of a certain communications profile for the specific requirements of a space mission. Users of this present standard are invited to consult these documents before taking decisions on the implementation of the present one. This standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS-S-ST-00. kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 7 2 Normative references The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revisions of any of these publications, do not apply. However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references the latest edition of the publication referred to applies.
EN reference Reference in text Title EN 16601-00-01 ECSS-S-ST-00-01 ECSS system – Glossary of terms EN 16603-50-01 ECSS-E-ST-50-01 Space engineering – Space data links – Telemetry synchronization and channel coding EN 16603-50-04 ECSS-E-ST-50-04 Space engineering – Space data links – Telecommand protocols, synchronization and channel coding
CCSDS 133.0-B-1
Space Packet Protocol – Blue Book, Issue 1, September 2003
CCSDS 135.0-B-3
Space Link Identifiers – Blue Book, Issue 3, October 2006
kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 8 3 Terms, definitions and abbreviated terms 3.1 Terms from other standards For the purpose of this Standard, the terms and definitions from ECSS-ST-00-01 apply. 3.2 Terms specific to the present standard 3.2.1 idle data data which carries no information, but is sent to conform to timing or synchronization requirements NOTE
The bit pattern of idle data is not specified. 3.2.2 mission phase period of a mission during which specified telemetry characteristics are fixed NOTE
The transition between two consecutive mission phases can cause an interruption of the telemetry services. 3.2.3 octet group of eight bits NOTE 1 The numbering for octets within a data structure starts with 0. NOTE 2 Refer to clause 3.4 for the convention for the numbering of bits. 3.2.4 packet variable-length data structure consisting of higher layer user data encapsulated within standard header information 3.2.5 static unchanged within a specific virtual channel or within a specific master channel NOTE
This Standard contains requirements on the invariability, throughout one or all mission phases, of certain characteristics of the data structures specified in it. kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 9 3.3 Abbreviated terms For the purpose of this Standard, the abbreviated terms from ECSS-ST-00-01 and the following apply: Abbreviation Meaning ASM attached sync marker CCSDS Consultative Committee for Space Data Systems FECF Frame Error Control Field MSB most significant bit TM Telemetry
3.4 Conventions 3.4.1 bit 0, bit N, bit N−N To identify each bit in an N-bit field, the first bit in the field to be transferred (i.e. the most left justified in a graphical representation) is defined as bit 0; the following bit is defined as bit 1 and so on up to bit N-1.
Figure 3-1: Bit numbering convention 3.4.2 most significant bit When an N-bit field is used to express a binary value (such as a counter), the most significant bit is the first bit of the field, i.e. bit 0 (see Figure 3-1). 3.4.3 use of capitals for the names of data structures and fields In this Standard initial capitals are used for the names of data structures and fields.
This enables field names to be easily identified in the surrounding text. For example, the field Transfer Frame Data Field is easier to see than transfer frame data field in text containing words such as frame and data and field. It also prevents ambiguity over where the name begins and ends. For example, there are fields Transfer Frame Secondary Header and Transfer Frame Secondary Header Length. The capitals help the reader to distinguish between the Transfer Frame Secondary Header length (meaning ‘the length of the Transfer Frame Secondary Header’) and the Transfer Frame Secondary Header Length (meaning the field of that name). kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 10 4 Overview 4.1 General The Telemetry Transfer Frame is a fixed-length data structure that provides an envelope for transmitting data units of several types over a telemetry space link. The frame is compatible with the ECSS standard for telemetry synchronization and channel coding defined in ECSS-E-ST-50-01. The telemetry transfer frame protocol can operate in various configurations of the telemetry space link, depending on the telemetry channel coding scheme and security options selected. The correct operation of the protocol can only occur if a high-quality data channel is provided between the peer entities of the protocol. NOTE 1
The Standard for telemetry channel coding, ECSS-E-ST-50-01, defines the coding mechanisms for a high-quality data channel, including frame synchronization and randomization. CCSDS 350.0-G-2 describes the security options. NOTE 2
In this Standard the terms TM Transfer Frame and Telemetry Transfer Frame are used interchangeably, i.e. they are synonyms and have the same meaning as. NOTE 3 Annex D describes the mission configuration parameters within the scope of this Standard. 4.2 Physical channel A data channel carrying a stream of bits in a single direction is referred to as a physical channel. For the TM Transfer Frame specified in this Standard, the value of the Transfer Frame Version Number is constant for all frames of a physical channel. The length of the frames for a given physical channel is fixed for a mission phase. kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 11 4.3 Master channels and virtual channels The TM Transfer Frame supports the division of the physical channel into master channels and virtual channels by means of identifier fields in the frame header. A master channel is identified by the values of the Transfer Frame Version Number and the Spacecraft Identifier. Within a given physical channel, a master channel consists of all the frames that have the same Transfer Frame Version Number and the same Spacecraft Identifier.
For a typical space mission, all the frames on a physical channel have the same value for the Spacecraft Identifier, so in this case there is one master channel on the physical channel. However, multiple master channels can share a physical channel, which, for example, can be the case when one spacecraft is transporting another spacecraft such as a probe. A master channel is divided into virtual channels using the Virtual Channel Identifier field. This is a 3-bit field and therefore supports up to eight virtual channels on a master channel. 4.4 Sharing transmission resources Virtual channels enable one physical channel to be shared among multiple higher-layer data streams, each of which can have different characteristics. The mechanisms and parameters for sharing access by the virtual channels to the physical channel are implementation dependent and not within the scope of this Standard. 4.5 Data fields in the frame Every TM Transfer Frame contains the Transfer Frame Data Field, which is the main data-carrying field in the frame. Within a virtual channel, the length of the Transfer Frame Data Field is static during a mission phase. There are status fields in the frame header that are related to the use of the Transfer Frame Data Field. The Transfer Frame Data Field carries packets or other data units. Additionally to the Transfer Frame Data Field, the TM Transfer Frame has two optional fields for carrying data:
• The Transfer Frame Secondary Header, used to carry fixed-length mission-specific data.
• The Operational Control Field, used to carry status information to control the operation of the telecommand space link or other spacecraft activities.
kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 12 5 TM Transfer Frame 5.1 General a. The TM Transfer Frame shall encompass the major fields, positioned contiguously if present, in the sequence shown in Figure 5-1. NOTE 1 Figure 5-1 shows the format of the TM Transfer Frame. NOTE 2 In the case that TM Transfer Frames are directly submitted to telemetry channel coding, the start of the TM Transfer Frame is always signalled by the attached sync marker (ASM) which immediately precedes the TM Transfer Frame. The ASM is specified in ECSS-E-ST-50-01.
When the TM Transfer Frame is embedded in a Reed-Solomon codeblock or turbo codeblock, the ASM signals the start of both. Table 5-1: Major fields in a TM Transfer Frame Field Presence in TM Transfer Frame Length in bits Transfer Frame Primary Header always present 48 Transfer Frame Secondary Header optional 16, 24, . or 512 Transfer Frame Data Field always present variable Transfer Frame Trailer optional 16, 32 or 48
b. The maximum length for a TM Transfer Frame shall be 2048 octets. c. The TM Transfer Frame shall be of constant length throughout a specific mission phase. NOTE
Because a change of frame length also changes the time interval between the start of successive frames, it can result in a loss of synchronization at the data capture element. kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 13 d. The TM Transfer Frame length shall be in conformance with the specifications contained in the standard for telemetry channel coding, ECSS-E-ST-50-01. NOTE
For some coding schemes, ECSS-E-ST-50-01 limits the TM Transfer Frame length to certain specific values. e. TM Transfer Frames shall be transferred over a physical channel at a constant rate. f. In order to assure correct decoding at the receiving end, the same telemetry channel coding options shall be applied to all TM Transfer Frames of a physical channel. g. At the receiving end, TM Transfer Frames containing detected errors need not be delivered.
h. The handling of TM Transfer Frames containing detected errors shall be specified for each mission or mission phase. NOTE
Depending on the coding scheme in use, errors in a TM Transfer Frame can be detected during the telemetry channel decoding at the receiving end (see ECSS-E-ST-50-01). The Frame Error Control Field specified in clause 5.6 can be used to detect errors in TM Transfer Frames. i. All TM Transfer Frames with the same Master Channel Identifier on a physical channel shall constitute a master channel. NOTE 1 The Master Channel Identifier is defined in clause 5.2.2. NOTE 2 In most cases, the master channel is identical to the physical channel. However, if the physical channel also carries TM Transfer Frames with other Spacecraft Identifiers, a distinction between the master channel and physical channel is made. In this case, multiplexing of TM Transfer Frames with different Spacecraft Identifiers is performed by multiplexing the different master channels on the same physical channel. j. A master channel shall consist of between one to eight virtual channels. k. On a physical channel that carries TM Transfer Frames, all the frames shall have the same Transfer Frame Version Number. NOTE
The TM Transfer Frames specified in this Standard do not share a physical channel with other types of frame.
kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 14
Figure 5-1: TM Transfer Frame format 5.2 Transfer Frame Primary Header 5.2.1 General a. The Transfer Frame Primary Header shall always be present in a TM Transfer Frame. b. The Transfer Frame Primary Header shall consist of six fields, positioned contiguously, in the following sequence: 1. Master Channel Identifier
12 bits 2. Virtual Channel Identifier
3 bits 3. Operational Control Field Flag 1 bit 4. Master Channel Frame Count
8 bits 5. Virtual Channel Frame Count
8 bits 6. Transfer Frame Data Field Status 16 bits NOTE 1 All six fields are always present in a Transfer Frame Primary Header. NOTE 2 Figure 5-2 shows the format of the Transfer Frame Primary Header. NOTE 3 The Transfer Frame Primary Header covers the following main functions: • to identify the data unit as a TM Transfer Frame; • to identify the master channel and virtual channel to which the frame belongs; • to provide a counting mechanism for the virtual channels and the master channel; • to provide status fields related to the data in the Transfer Frame Data Field. kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 15
Figure 5-2: Format of Transfer Frame Primary Header 5.2.2 Master Channel Identifier 5.2.2.1 General a. The Master Channel Identifier shall always be present in a Transfer Frame Primary Header. b. The Master Channel Identifier shall be contained within bits 0-11 of the Transfer Frame Primary Header. c. The Master Channel Identifier shall consist of two fields, positioned contiguously, in the following sequence: 1. Transfer Frame Version Number
2 bits 2. Spacecraft Identifier
10 bits NOTE
Both fields are always present in a Master Channel Identifier. 5.2.2.2 Transfer Frame Version Number a. The Transfer Frame Version Number shall always be present in a Master Channel Identifier. b. The Transfer Frame Version Number shall be contained within bits 0-1 of the Transfer Frame Primary Header. c. The Transfer Frame Version Number shall be set to ‘00’. NOTE
This is the value defined in CCSDS 135.0-B-3 for the Transfer Frame Version Number of a TM Transfer Frame. 5.2.2.3 Spacecraft Identifier a. The Spacecraft Identifier shall always be present in a Master Channel Identifier. b. The Spacecraft Identifier shall be contained within bits 2-11 of the Transfer Frame Primary Header. c. The Spacecraft Identifier shall provide the identification of the spacecraft which is associated with the data contained in the TM Transfer Frame. kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 16 NOTE 1 The Secretariat of the CCSDS assigns Spacecraft Identifiers according to the procedures in CCSDS 320.0-B-4. NOTE 2 Different Spacecraft Identifiers can be assigned for normal operations and for development vehicles using the ground networks during pre-launch test operations, and for simulated data streams. d. The Spacecraft Identifier shall be static throughout all mission phases. 5.2.3 Virtual Channel Identifier a. The Virtual Channel Identifier shall always be present in a Transfer Frame Primary Header. b. The Virtual Channel Identifier shall be contained within bits 12-14 of the Transfer Frame Primary Header. c. The Virtual Channel Identifier shall provide the identification of the virtual channel to which the TM Transfer Frame belongs. NOTE
The order of occurrence of TM Transfer Frames belonging to different virtual channels on a master channel can vary. 5.2.4 Operational Control Field Flag a. The Operational Control Field Flag shall always be present in a Transfer Frame Primary Header. b. The Operational Control Field Flag shall be contained in bit 15 of the Transfer Frame Primary Header. c. The Operational Control Field Flag shall indicate the presence or absence of the Operational Control Field, as follows: 1.
‘1’ Operational Control Field is present; 2.
‘0’
Operational Control Field is not present. d. The Operational Control Field Flag shall be static in the associated master channel or virtual channel throughout a mission phase. NOTE
See clause 5.5.1. 5.2.5 Master Channel Frame Count a. The Master Channel Frame Count shall always be present in a Transfer Frame Primary Header. b. The Master Channel Frame Count shall be contained within bits 16-23 of the Transfer Frame Primary Header. c. The Master Channel Frame Count shall contain a sequential binary count (modulo 256) of each TM Transfer Frame transmitted in a specific master channel. NOTE
This field provides a running count of the frames transmitted through the same master channel. kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 17 d. The Master Channel Frame Count shall not be reset before reaching 255 unless there is a major system reset. NOTE
If the Master Channel Frame Count is reset due to a re-initialisation, the completeness of a sequence of TM Transfer Frames cannot be determined. 5.2.6 Virtual Channel Frame Count a. The Virtual Channel Frame Count shall always be present in a Transfer Frame Primary Header. b. The Virtual Channel Frame Count shall be contained within bits 24-31 of the Transfer Frame Primary Header. c. The Virtual Channel Frame Count shall contain a sequential binary count (modulo 256) of each TM Transfer Frame transmitted through a specific virtual channel of a master channel. NOTE
This field provides individual accountability for the frames of each virtual channel. It can be used to detect gaps in the stream of data carried in the Transfer Frame Data Fields of the frames for a virtual channel. d. The Virtual Channel Frame Count shall not be reset before reaching 255 unless there is a major system reset. NOTE
If the Virtual Channel Frame Count is reset due to a re-initialisation, the completeness of a sequence of TM Transfer Frames in the related virtual channel cannot be determined. 5.2.7 Transfer Frame Data Field Status 5.2.7.1 General a. The Transfer Frame Data Field Status shall always be present in a Transfer Frame Primary Header. b. The Transfer Frame Data Field Status shall be contained within bits 32-47 of the Transfer Frame Primary Header. c. The Transfer Frame Data Field Status shall consist of five fields, positioned contiguously, in the following sequence: 1. Transfer Frame Secondary Header Flag 1 bit 2. Synchronization Flag
1 bit 3. Packet Order Flag
1 bit 4. Segment Length Identifier
2 bits 5. First Header Pointer
11 bits NOTE 1 All these five fields are always present in a Transfer Frame Data Field Status. kSIST FprEN 16603-50-03:2014
FprEN 16603-50-03:2013 (E) 18 NOTE 2 This field indicates whether a secondary header is present and provides information relating to the data contained in the Transfer Frame Data Field. 5.2.7.2 Transfer Frame Secondary Header Flag a. The Transfer Frame Secondary Header Flag shall always be present in a Transfer Frame Data Field Status. b. The Transfer Frame Secondary Header Flag shall be contained in bit 32 of the Transfer Frame Primary Header. c. The Transfer Frame Secondary Header Flag shall indicate the presence or absence of the Transfer Frame Second
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.