ISO 12175:1994/Amd 1:2015

INTERNATIONAL ISO
STANDARD 12175
First edition
1994-10-20
AMENDMENT 1
2015-07-01
Space data and information transfer
systems — Standard formatted data
units — Structure and construction
rules
AMENDMENT 1
Systèmes de transfert des informations et données spatiales — Unités
de données à structuration normalisée (SFDU) — Règles de structure
et de construction
AMENDEMENT 1
Reference number
ISO 12175:1994/Amd.1:2015(E)
©
ISO 2015
ISO 12175:1994/Amd.1:2015(E)
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved

Consultative
Committee for
Space Data Systems
RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
STANDARD FORMATTED
DATA UNITS —
STRUCTURE AND
CONSTRUCTION RULES
CCSDS 620.0-B-2
Note:
BLUE BOOK
This current
issue includes
all updates through
May 1992
Technical Corrigendum 1,
dated November 1996.
TMG 8/92
CCSDS Recommendation for SFDUs: Structure and Construction Rules
AUTHORITY
Issue: Blue Book, Issue 2
Date: May 1992
Location: CCSDS Panel 2 Meeting, May
1992, Oberpfaffenhofen, Germany
This Recommendation reflects the consensus technical agreement of the following member Agencies
of the Consultative Committee for Space Data Systems (CCSDS):
• British National Space Centre (BNSC) / United Kingdom
• Canadian Space Agency (CSA) / Canada
• Centre National D’Etudes Spatiales (CNES) / France
• Deutsche Forschungsanstalt für Luft und Raumfahrt (DLR) / FRG
• European Space Agency (ESA) / Europe
• Instituto de Pesquisas Espaciais (INPE) / Brazil
• National Aeronautics and Space Administration (NASA) / USA
• National Space Development Agency of Japan (NASDA) / Japan
The following observer Agencies also concur with this Recommendation:
• Department of Communication/Communications Research Centre (DOC/CRC)
/ Canada
• Institute for Space Astronautics and Science (ISAS) / Japan
This Recommendation is published and maintained by:
CCSDS Secretariat
Communications and Data Systems Division, (Code-OS)
National Aeronautics and Space Administration
Washington, DC 20546, USA
Issue 2 May 1992
iii
CCSDS Recommendation for SFDUs: Structure and Construction Rules
FOREWORD
This document is a technical Recommendation for the standardisation of the structure and construction
rules of Standard Formatted Data Units (SFDU), for the interchange of digital space-related data in an
open data system and has been prepared by the Consultative Committee for Space Data Systems
(CCSDS). Other aspects of the SFDU concept are described in documents listed in the Reference
section.
This Recommendation defines SFDU structures that will handle some of the problems of digital data
interchange and several construction rules that will limit the SFDUs to a practical set that can exist in
an open data system environment. It allows implementing organisations within each Agency to proceed
coherently with the development of compatible derived Standards for space data systems and widely
dispersed data users that are within their cognisance.
Through the process of normal evolution, it is expected that expansion, deletion, or modification to this
document may occur. This Recommendation is therefore subject to CCSDS document management
and change control procedures which are defined in Reference [1].
Questions relating to the contents or status of this document should be addressed to the CCSDS
Secretariat.
Issue 2 May 1992
iv
CCSDS Recommendation for SFDUs: Structure and Construction Rules
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organisation officially established
by the management of the member space Agencies. The committee meets periodically to address data
system problems that are common to all participants, and to formulate sound technical solutions to
these problems. Inasmuch as participation in the CCSDS is completely voluntary, the results of the
committee are termed RECOMMENDATIONS and are not considered binding to any Agency.
This Recommendation is issued by, and represents the consensus of, the CCSDS Plenary body.
Agency endorsement of the Recommendation is entirely voluntary. Endorsement, however, indicates
the following understandings:
• Whenever an Agency establishes a CCSDS-related Standard, this Standard
will be in accordance with the relevant Recommendation. Establishing such
a Standard does not preclude other provisions which an Agency may develop.
• Whenever an Agency establishes a CCSDS-related Standard, the Agency will
provide other CCSDS member Agencies with the following information:
- The Standard itself.
- The anticipated date of initial operational capability.
- The anticipated duration of operational service.
• Specific service arrangements shall be made via memorandum of agreement.
Neither this Recommendation nor any ensuing Standard is a substitute for a
memorandum of agreement.
No later than five years from its date of issuance, this Recommendation will be reviewed by the CCSDS
to determine whether it should: (1) remain in effect without change; (2) be changed to reflect the impact
of new technologies, new requirements, or new directions; or (3) be retired or cancelled.
Issue 2 May 1992
v
CCSDS Recommendation for SFDUs: Structure and Construction Rules
DOCUMENT CONTROL
Document Title Date Status/
Remarks
CCSDS 620.0-B-1 Recommendation for Space Data System Feb 1988 Issue 1
Standards: Standard Formatted Data
Units -- Structure and Construction Rules,
Blue Book, Issue 1
CCSDS 620.0-B-2 Recommendation for Space Data System May 1992 Issue 2,
Standards: Standard Formatted Data see note
Units -- Structure and Construction Rules, below
Blue Book, Issue 2
Note: The major changes from Issue 1 to Issue 2 are the inclusion of techniques for the following:
• For linking a data description with its identifier (ADID).
• For delimiting data objects other than by length.
• For referencing external labelled and unlabelled data objects.
Issue 2 is forwards compatible with the whole of Issue 1.
Issue 2 May 1992
vi
CCSDS Recommendation for SFDUs: Structure and Construction Rules
CONTENTS
Sections
1 INTRODUCTION . 1
1.1 Purpose and Scope . 1
1.2 Applicability . 1
1.3 Recommended Approach to Reading the Document . 1
2 SFDU OVERVIEW . 4
2.1 Introduction . 4
2.2 The SFDU Building Block - The LABEL-VALUE-OBJECT . 4
2.3 SFDU Structuring . 5
2.3.1 Simple LVOs . 5
2.3.2 Compound LVOs . 6
2.3.2.1 Exchange Data Unit (EDU) . 6
2.3.2.2 Application Data Unit (ADU) . 7
2.3.2.3 Description Data Unit (DDU) . 7
2.4 EDU Structure Diagram . 8
3 LVO LABEL FIELD SPECIFICATIONS USED IN SFDUS . 9
3.1 LVO LABEL Specification - Version ID = 1 . 9
3.1.1 Version ID . 9
3.1.2 Authority and Description Identifier (ADID) . 9
3.1.2.1 Control Authority Identifier (CAID) . 9
3.1.2.2 Data Description Identifier (DDID) . 10
3.1.3 Class ID . 10
3.1.4 Spare 1 . 10
3.1.5 Spare 2 . 10
3.1.6 Length . 10
3.1.7 Structure Diagram . 11
3.2 LVO LABEL Specification - Version ID = 2 . 11
3.2.1 Version ID . 11
3.2.2 Authority and Description Identifier (ADID) . 11
3.2.2.1 Control Authority Identifier (CAID) . 11
3.2.2.2 Data Description Identifier (DDID) . 12
3.2.3 Class ID . 12
3.2.4 Spare 1 . 12
3.2.5 Spare 2 . 12
3.2.6 Length . 12
3.2.7 Structure Diagram . 12
3.3 LVO LABEL Specification - Version ID = 3 . 13
3.3.1 Version ID . 13
3.3.2 Authority and Description Identifier (ADID) . 13
3.3.2.1 Control Authority Identifier (CAID) . 13
3.3.2.2 Data Description Identifier (DDID) . 13
3.3.3 Class ID . 14
3.3.4 Delimitation . 14
3.3.4.1 Length (Specified in ASCII) - Delimitation ID = A . 14
3.3.4.2 Length (Specified in Binary) - Delimitation ID = B . 15
Issue 2 May 1992
vii
CCSDS Recommendation for SFDUs: Structure and Construction Rules
3.3.4.3 Marker Pattern - Delimitation ID = S . 15
3.3.4.4 Sequential End-of-File (EOF) - Delimitation ID = E . 16
3.3.4.5 Contiguous End-of-File (EOF) - Delimitation ID = C . 16
3.3.4.6 Shared End-of-File (EOF) - Delimitation ID = F . 16
3.3.5 Spare . 17
3.3.6 Delimitation Parameter . 17
3.3.7 Structure Diagram . 17
4 CLASS ID SPECIFICATIONS . 18
4.1 Structure Classes . 18
4.1.1 Exchange Data Unit - Class ID = Z . 18
4.1.2 Application Data Unit - Class ID = U . 19
4.1.3 Description Data Unit - Class ID = F . 19
4.2 Service Classes . 19
4.2.1 Replacement Service Object - Class ID = R . 19
4.2.2 Data Administration Service Object - Class ID = C . 19
4.3 Data Classes . 20
4.3.1 Application Data Object - Class ID = I . 20
4.3.2 Supplementary Data Object - Class ID = S . 20
4.3.3 Data Description Record Object - Class ID = D . 20
4.3.4 Data Entity Dictionary Object - Class ID = E . 20
4.3.5 Catalogue Attribute Object - Class ID = K . 20
4.3.6 Volume Preparation Data Object - Class ID = V . 20
4.4 Overview of Structure Class IDs . 21
5 CCSDS ADID SPECIFICATIONS . 22
5.1 Specification for ADID = CCSD0001 . 22
5.2 Specification for ADID = CCSD0003 . 22
5.3 Specification for ADID = CCSD0004 . 24
5.4 Specification for ADID = CCSD0005 . 25
5.5 Specification for ADID = CCSD0009 . 26
6 COMBINATION OF ADIDS AND CLASS IDS . 27
Annex A: Acronyms . 30
Annex B: Glossary of Terms . 32
Annex C: ASN.1 Definitions . 34
C.1 ASN.1 Definition of the LVO Structure . 34
C.2 ASN.1 Definition of the DDR for ADID = CCSD0001 . 40
C.3 ASN.1 Definition of the DDR for ADID = CCSD0003 . 41
C.4 ASN.1 Definition of the DDR for ADID = CCSD0004 . 42
C.5 ASN.1 Definition of the DDR for ADID = CCSD0005 . 43
C.6 ASN.1 Definition of the DDR for ADID = CCSD0009 . 44
Annex D: ASCII & Restricted ASCII Codes . 46
Annex E: Octet Numbering Convention and Nomenclature . 48
Annex F: Proposed Referencing Environment Specifications . 50
F.1 Basic Referencing Environment - $CCSDS1 . 50
F.2 Extended Referencing Environment - $CCSDS2 . 51
Issue 2 May 1992
viii
CCSDS Recommendation for SFDUs: Structure and Construction Rules
INDEX . 53
Figures
Figure 1-1: Example Structure Diagram . 2
Figure 2-1: The LABEL-VALUE-OBJECT Structure . 4
Figure 2-2: Structure Diagram of a Simple LVO . 6
Figure 2-3: Structure Diagram of a Compound LVO . 6
Figure 2-4: Example of the Use of ADUs . 7
Figure 2-5: Example of the Use of DDUs . 8
Figure 2-6: Structure Diagram of an EDU . 8
Figure 3-1: CCSDS LABEL Specification - Version ID = 1 . 9
Figure 3-2: Structure Diagram for an LVO with Version ID = 1 . 11
Figure 3-3: CCSDS LABEL Specification - Version ID = 2 . 11
Figure 3-4: Structure Diagram for an LVO with Version ID = 2 . 12
Figure 3-5: CCSDS LABEL Specification - Version ID = 3 . 13
Figure 3-6: Schematic of a Marker Pattern Delimited LVO . 15
Figure 3-7: Structure Diagram for an LVO with Version ID = 3 . 17
Figure 4-1: SFDU Class ID Breakdown . 18
Figure 5-1: Structure Diagram of the VALUE Field of an LVO with ADID=CCSD0001 . 22
Figure 5-2: Structure Diagram of the PVL Statements within an LVO with ADID =
CCSD0003 . 23
Figure 5-3: Structure Diagram of the VALUE Field of an LVO with ADID = CCSD0005 . 25
Figure 5-4: Structure Diagram of the VALUE Field of an LVO with ADID = CCSD0009 . 26
Figure F-1: Structure Diagram of $CCSDS1 Name Specification . 50
Figure F-2: Structure Diagram of $CCSDS2 Name Specification . 51
Tables
Table 3-1: Delimitation IDs . 14
Table 3-2: Delimitation Parameter Definitions . 17
Table 4-1: LVOs Permitted within each Compound LVO . 21
Table 6-1: ADID and Class ID Combination Categorisations . 28
Table 6-2: CCSDS Defined Combinations of Class IDs and ADIDs . 28
Table D-1: ASCII and Restricted ASCII Codes . 46
Issue 2 May 1992
ix
CCSDS Recommendation for SFDUs: Structure and Construction Rules
REFERENCES
[1] "Procedures Manual for the Consultative Committee for Space Data Systems", CCSDS A00.0-
Y-4, Yellow Book, Issue 4, Consultative Committee for Space Data Systems, September 1990.
[2] "Recommendation for Space Data System Standards: Standard Formatted Data Units --
Control Authority Procedures", CCSDS 630.0-R-2, Red Book, Issue 2, Consultative Committee
for Space Data Systems, April 1992 or later.
[3] "Report Concerning Space Data System Standards: Standard Formatted Data Units -- A
Tutorial", CCSDS 621.0-G-1, Green Book, Issue 1, Consultative Committee for Space Data
Systems, May 1992 or later.
[4] "Information Technology - Open Systems Interconnection - Specification of Abstract Syntax
Notation One (ASN.1)", ISO 8824:1990E, Second Edition, December 1990.
[5] "Recommendation for Space Data System Standards: Parameter Value Language Specification
(CCSD0006)", CCSDS 641.0-B-1, Blue Book, Issue 1, Consultative Committee for Space Data
Systems, May 1992 or later.
[6] "Recommendation for Space Data System Standards: ASCII Encoded English (CCSD0002)",
CCSDS 643.0-R-1, Red Book, Issue 1, Consultative Committee for Space Data Systems, May
1992 or later.
[7] "Recommendation for Space Data System Standards: Standard Formatted Data Units --
Control Authority Data Structures", CCSDS 632.0-B-1, Blue Book, Issue 1, Consultative
Committee for Space Data Systems, November 1994 or later.
[8] "Recommendation for Space Data System Standards: Standard Formatted Data Units --
Referencing Environment", CCSDS 622.0-R-1, Red Book, Issue 1, Consultative Committee for
Space Data Systems, November 1994 or later.
CCSDS 620.0-B-2 Cor. 1 November 1996
x
Cor. 1
CCSDS Recommendation for SFDUs: Structure and Construction Rules
1 INTRODUCTION
1.1 Purpose and Scope
The purpose of this document is to establish a Recommendation for the implementation of standard
data structures for the interchange of data in a more uniform and automated fashion within and
between the Agencies participating in the Consultative Committee for Space Data Systems (CCSDS).
This Recommendation defines the Standard Formatted Data Unit (SFDU) Concept. This concept
covers the following areas:
1) A method for labelling data objects to provide a general classification and a
link to a unique description of each data object;
2) A method of organising data objects into a hierarchial structure to provide a
complete set of information. This includes referencing of data objects that are
defined externally, such as files.
1.2 Applicability
This Recommendation serves as a guideline for the development of compatible agency standards in
the field of digital data interchange. The specifications in this document are to be invoked through the
normal standards program of each member agency and are applicable, at a minimum, to those
missions and services for which cross support based on the need for open system data interchange
is anticipated.
To be compatible with the CCSDS SFDU concept, an agency must use the structures as defined by
this Recommendation.
1.3 Recommended Approach to Reading the Document
A proper understanding of this Recommendation requires familiarity with the SFDU concept, the
rationale underlying the various product building and packaging techniques and the specific terminology
used in this document. It is recommended that Reference [3] be read prior to this Recommendation
as it describes both the requirements and the rationale behind the SFDU concept, and introduces the
technical material contained in this Recommendation through examples.
The document is structured as follows:
• Section 2 gives a general overview of the SFDU concept, and introduces the
basic data structuring components;
• Section 3 describes the details of the LABEL-VALUE structure used by the
SFDU concept and defines all its sub-fields;
• Section 4 describes CCSDS defined Class IDs and, where applicable, the
relationships between them;
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
• Section 5 describes the CCSDS defined Authority and Description Identifiers
(ADIDs) which are relevant to this Recommendation, with regard to the rules
for constructing and parsing the corresponding VALUE fields;
• Section 6 describes the CCSDS defined combinations of ADIDs and Class IDs;
• Annexes A and B present a complete summary of the acronyms and the
terminology used in this document;
• Annex C gives a formal specification in Abstract Syntax Notation One (ASN.1,
see Reference [4]), of the structures presented in this Recommendation;
• Annexes D and E specify the ASCII character codes and octet/bit numbering
conventions used throughout the document;
• An index is supplied covering all the major terms in the document, the first
page referenced by the index points to the definition of the term.
Throughout this Recommendation structure diagrams are used to explain the structures presented. The
following conventions are used in these diagrams:
• The item named to the left of the := symbol is the item being defined;
• The diagram on the right of the := symbol is the definition;
• A vertical branch point represents a choice;
• A repetition is indicated by a loop back covering the object to be repeated. If
there are the symbols n be repeated only 0 to x number of times;
• The termination of each structure is represented by an o symbol.
For example:
Figure 1-1: Example Structure Diagram
In this example Item A is defined as first a choice between Items B or C or nothing, if Item B is selected
then it may be repeated further from 1 to 7 times. Then this structure is followed by one Item D. Once
this structure is built up, it may then all be repeated any number of times, until the choice to pass onto
theo symbol is taken. Of course if any items on the right (B, C or D) contain an Item A, the definition
is recursive. Recursive structure definitions are permitted in this Recommendation.
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
Where possible Abstract Syntax Notation One (ASN.1, see Reference [4]) definitions of the structures
presented in this Recommendation are given in Annex C. In the case of any unintentional
inconsistency with the ASN.1 specification, the specification given in Sections 1 to 6 is the ruling
specification (This is because the ASN.1 cannot wholly describe the structures presented here, without
additional natural language comments).
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
2 SFDU OVERVIEW
2.1 Introduction
This Recommendation defines under the Standard Formatted Data Unit (SFDU) concept, methods for
packaging supplementary data and metadata with space related science and engineering data to create
data products that contain complete sets of information for the purpose of information interchange.
Any type of data can be integrated into the SFDU domain; what is standardised is the technique of
packaging together the various data objects into an SFDU data product. There is no constraint on the
format of the user data.
Data instances are of little value without descriptions of their contents and organisation. The SFDU
concept integrates data and metadata and provides a technique to identify the different types of
packaged information.
2.2 The SFDU Building Block - The LABEL-VALUE-OBJECT
The basic SFDU building block is comprised of a LABEL field and a VALUE field, and is referred to as
a Label-Value-Object (LVO). This structure is the fundamental structural element used to build SFDUs.
The LVOs themselves are made up of a sequence of octets.
In the SFDU approach, data exchanged between open (independent) data systems are tagged with a
LABEL, as shown in Figure 2-1.
Figure 2-1: The LABEL-VALUE-OBJECT Structure
The LABEL contains the following sub-fields:
• An identifier of the format and meanings of all the other LABEL sub-fields;
• An identifier of the description of the format and meaning of the data in the
VALUE field;
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
• An identifier that gives an indication of the type of data in the VALUE field;
• The necessary information required to delimit the VALUE field.
A complete definition of the sub-fields of the LABEL is given in Section 3.
The VALUE field may contain any form of data that can be described by a user defined data description
or by a CCSDS recognised data description as defined in Sections 5 and 6. The method used to
delimit this field, and a description of the data in this field, are identified through the associated LABEL
field.
The optional marker field is required by some delimitation techniques to delimit the VALUE field (See
Section 3.3).
2.3 SFDU Structuring
SFDU data products are constructed from the basic LVO in one of two ways. If the VALUE field of the
LVO contains purely user data it is termed a "Simple LVO". If, on the other hand, the VALUE field of
the LVO contains purely LVOs, it is termed a "Compound LVO". There are various CCSDS defined
categories of Simple and Compound LVOs depending upon the type of data or LVOs respectively that
they contain, as detailed in the following sections.
2.3.1 Simple LVOs
Data in a Simple LVO may be viewed as belonging to one of the following categories:
• Application data; that is the data which is of primary interest (typically actual
measurements or data derived from actual measurements);
• Supplementary data; that is data that is considered to enhance the
understanding of the associated data;
• Data description information, telling how the application data are formatted,
including such details as size of the data fields, numerical or other
representations used and the meanings of the fields;
• Data cataloguing/production information, telling how the data may be divided,
for example, by date, instrument used, instrument location or general
information about the way the data was collected, relayed or processed.
Any of these types of data may be contained in the VALUE field of a single LVO. The structure of a
(1)
Simple LVO can be described by Figure 2-2 (overleaf).
(1)
For clarity in this diagram, the optional marker component is not shown.
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
Figure 2-2: Structure Diagram of a Simple LVO
2 .3.2
Compound LVOs
Compound LVOs are LVOs which contain within their VALUE field a sequence of one or more LVOs,
each of which can be a Simple or Compound LVO itself; this sequence of LVOs is deemed to be one
"Structure Level" lower than that of the containing Compound LVO. Any Compound LVOs in this
sequence will themselves contain a sequence of LVOs; this sequence is at the next lower "Structure
Level". This process may continue indefinitely leading to a succession of structure levels. This process
is the way in which LVOs are nested. The structure of a Compound LVO can be described by Figure
(2)
2-3 .
Figure 2-3: Structure Diagram of a Compound LVO
There are three Compound LVOs defined in this Recommendation; there is the Exchange Data Unit
(EDU), and two particular structures which must be packaged within an EDU. These are the
Application Data Unit (ADU), which explicitly does not contain any data description information, and
the Description Data Unit (DDU), which must contain only data description information.
2.3.2.1 Exchange Data Unit (EDU)
Typically an EDU data product consists of not only the data (e.g., an image, a set of measurement
samples), but also all the supporting metadata that is needed to understand the data product. Any type
of data may be contained within an EDU, whether it be packaged in Simple LVOs or Compound LVOs.
For example, the following could be packaged within an EDU:
• Information on the production of the product;
• Catalogue data pertaining to the product (e.g., platform ID, data type, time
span);
(2)
For clarity in this diagram, the optional marker component is not shown.
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
• A number of data instances comprising of application data and supplementary
data (e.g., images and image coordinates);
• A number of data descriptions that describe each of the application data
formats and the supplementary data formats.
2.3.2.2 Application Data Unit (ADU)
The purpose of an ADU is to package application data instances (e.g., measurement samples) together
with any necessary ancillary data (e.g., sampling rate) and identification data (e.g., catalogue
information), and to explicitly exclude any data description information. Typically an ADU will be used
to "subset" a set of application data within an EDU. Software may be designed so that data stored
within an ADU is directed towards one particular processing task, which selects the ADUs out of the
data structure and skips over any others. Several such units typically appear within a data product.
An ADU must always be packaged within an EDU. An example of the use of ADUs is shown in Figure
2-4.
Figure 2-4: Example of the Use of ADUs
2.3.2.3 Description Data Unit (DDU)
A Description Data Unit consists of the following:
• It carries the description of a data object (typically syntactic information such
as the format of a sample, and semantic information such as the name and
units of the components of the sample);
• It explicitly links the data description to the data object to which it applies;
• It does not include any application data instances.
Like an ADU, a DDU must always be packaged within an EDU. Figure 2-5 (overleaf) shows a DDU
that could be used to describe the data within the ADU shown in Figure 2-4. This data description data
may be packaged together with the application data or held separately.
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
Figure 2-5: Example of the Use of DDUs
2.4 EDU Structure Diagram
The four structures that have been illustrated in the previous section are the Simple Label-Value-Object
(LVO), the Exchange Data Unit (EDU), the Application Data Unit (ADU) and the Description Data Unit
(DDU). These structures may be packaged together as indicated in the structure diagram of Figure
(3)
2-6 . Not all the components on the right of the := must be included in all EDUs, but at least one
Simple LVO must be present. This shows a clear hierarchical approach to packaging, with all data
objects being packaged within an EDU. Recall that ADUs and DDUs contain further LVOs.
Figure 2-6: Structure Diagram of an EDU
(3)
For clarity in this diagram, the optional marker component is not shown.
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
3 LVO LABEL FIELD SPECIFICATIONS USED IN SFDUS
Sections 3.1 to 3.3 specify the three versions of the LVO LABEL defined in this Recommendation. The
version of the LABEL is indicated by octet 4 of the LABEL in all cases. This sub-field of the LABEL
is called the Version ID.
(An SFDU product must be immediately identifiable as falling within the CCSDS/SFDU domain;
therefore octets 0 to 3 must contain the stringCCSD, which is the Control Authority Identifier (CAID) for
the CCSDS. Therefore, that even though the Version ID dictates the format of the LABEL, it may not
appear prior to the string CCSD and thus appears in octet 4.)
The octet numbering conventions, as described in Annex E, apply only to the LABEL field, not to the
VALUE field. In addition, a restricted ASCII character set, denoted by RA (see Annex D), is used in
many sub-fields of the LABEL.
3.1 LVO LABEL Specification - Version ID = 1
Figure 3-1 shows the LVO LABEL specification that is identified by the RA character 1 in the Version
ID sub-field. Figure 3-1 indicates the sub-field names and their octet positions within the LABEL. The
definitions of the terms used in the figure are given below in Sections 3.1.1 to 3.1.6.
Figure 3-1: CCSDS LABEL Specification - Version ID = 1
3.1.1 Version ID
The Version ID contains the RA character 1. This Version ID, specified in the second sub-field (octet
4), identifies the format and meaning of the LABEL.
3.1.2 Authority and Description Identifier (ADID)
The ADID is an identifier which is used to uniquely identify the data description information that applies
to the associated VALUE field. The ADID is partitioned into two four octet sub-fields, one in octets 0
to 3 and the other in octets 8 to 11. The Control Authority Identifier occupies the first sub-field of the
ADID. The second sub-field of the ADID contains the Data Description Identifier.
3.1.2.1 Control Authority Identifier (CAID)
The Control Authority Identifier specified in the first sub-field (octets 0 to 3) of the LABEL identifies the
organisation that has assigned the ADID to the data description information. This Control Authority
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
Office has the responsibility for maintaining the data description information and disseminating it in
response to user requests according to the procedures recommended in Reference [2].
Only RA characters are allowed in the CAID sub-field.
3.1.2.2 Data Description Identifier (DDID)
The Data Description Identifier, specified in the sixth sub-field (octets 8 to 11) of the LABEL contains
the identifier of the data description information held at the Control Authority Office, as identified by the
CAID.
Only RA characters are allowed in the DDID sub-field.
3.1.3 Class ID
The Class ID, specified in the third sub-field (octet 5) of the LABEL, indicates the kind of data contained
in the VALUE field following the LABEL. The Class ID must be selected from those approved by the
CCSDS. A list of approved Class IDs is found in Section 4.
Only RA characters are allowed in the Class ID sub-field.
3.1.4 Spare 1
Octet 6 of the LABEL is a spare and shall be set to RA character 0 (zero).
3.1.5 Spare 2
Octet 7 of the LABEL is a spare and shall be set to RA character 0 (zero).
3.1.6 Length
The length of the VALUE field, in units of octets, is specified in the seventh sub-field (octets 12 to 19)
of the LABEL. The length is specified in decimal and represented in the numeric character subset of
RA. The eight octets specified for this field makes possible a VALUE field length of up to 10 -1 octets.
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
3.1.7 Structure Diagram
An LVO with a Version ID = 1 can be described by the structure diagram shown in Figure 3-2.
Figure 3-2: Structure Diagram for an LVO with Version ID = 1
3.2 LVO LABEL Specification - Version ID = 2
Figure 3-3 shows the CCSDS LABEL specification that is identified by the RA character 2 in the
Version ID sub-field. Figure 3-3 indicates the sub-field names and their octet positions within the
LABEL. The definitions of the terms used in the figure are given below in Sections 3.2.1 to 3.2.6.
Figure 3-3: CCSDS LABEL Specification - Version ID = 2
Note: A LABEL with Version ID = 2 differs from a LABEL with Version ID = 1 only
in the value in the Version ID sub-field and that the Length sub-field specifies
the length of the VALUE field in binary, not in RA characters.
3.2.1 Version ID
The Version ID contains the RA character 2. This Version ID, specified in the second sub-field (octet
4), identifies the format and meaning of the LABEL.
3.2.2 Authority and Description Identifier (ADID)
The ADID is an identifier which is used to uniquely identify the data description information that applies
to the associated VALUE field. The ADID is partitioned into two four octet sub-fields, one in octets 0
to 3 and the other in octets 8 to 11. The Control Authority Identifier occupies the first sub-field of the
ADID. The second sub-field of the ADID contains the Data Description Identifier.
3.2.2.1 Control Authority Identifier (CAID)
The Control Authority Identifier specified in the first sub-field (octets 0 to 3) of the LABEL identifies the
organisation that has assigned the ADID to the data description information. This Control Authority
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
Office has the responsibility for maintaining the data description information and disseminating it in
response to user requests according to the procedures recommended in Reference [2].
Only RA characters are allowed in the CAID sub-field.
3.2.2.2 Data Description Identifier (DDID)
The Data Description Identifier, specified in the sixth sub-field (octets 8 to 11) of the LABEL contains
the identifier of the data description information held at the Control Authority Office, as identified by the
CAID.
Only RA characters are allowed in the DDID sub-field.
3.2.3 Class ID
The Class ID, specified in the third sub-field (octet 5) of the LABEL, indicates the kind of data contained
in the VALUE field following the LABEL. The Class ID must be selected from those approved by the
CCSDS. A list of approved Class IDs is found in Section 4.
Only RA characters are allowed in the Class ID sub-field.
3.2.4 Spare 1
Octet 6 of the LABEL is a spare and shall be set to RA character 0 (zero).
3.2.5 Spare 2
Octet 7 of the LABEL is a spare and shall be set to RA character 0 (zero).
3.2.6 Length
The length, specified in the seventh sub-field (octets 12 to 19) of the LABEL, is used to specify the
length of the VALUE field in octets and is represented in binary. The eight octet field specifies a 64
bit binary number that provides for a VALUE field length of up to 2 -1 octets.
3.2.7 Structure Diagram
An LVO with a Version ID = 2 can be described by the structure diagram shown in Figure 3-4.
Figure 3-4: Structure Diagram for an LVO with Version ID = 2
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
3.3 LVO LABEL Specification - Version ID = 3
Figure 3-5 shows the LVO LABEL Specification that is identified by the RA character 3 in the Version
ID sub-field. Figure 3-5 indicates the sub-field names and their octet positions within the LABEL. The
definitions of the terms used in the figure are given below in Sections 3.3.1 to 3.3.6.
Figure 3-5: CCSDS LABEL Specification - Version ID = 3
Note: A LABEL with Version ID = 3 differs from a LABEL with Version ID = 1 or 2
only in how octets 6 and 12 to 19 are used. Octet 6 specifies how the VALUE
field is delimited (as opposed to being "spare" for the previous Version IDs) ,
and octets 12 to 19 specify a parameter to be used for delimitation.
3.3.1 Version ID
The Version ID contains the RA character 3. This Version ID, specified in the second sub-field (octet
4), identifies the format and meaning of the LABEL.
3.3.2 Authority and Description Identifier (ADID)
The ADID is an identifier which is used to uniquely identify the data description information that applies
to the associated VALUE field. The ADID is partitioned into two four octet sub-fields, one in octets 0
to 3 and the other in octets 8 to 11. The Control Authority Identifier occupies the first sub-field of the
ADID. The second sub-field of the ADID contains the Data Description Identifier.
3.3.2.1 Control Authority Identifier (CAID)
The Control Authority Identifier specified in the first sub-field (octets 0 to 3) of the LABEL identifies the
organisation that has assigned the ADID to the data description information. This Control Authority
Office has the responsibility for maintaining the data description information and disseminating it in
response to user requests according to the procedures recommended in Reference [2].
Only RA characters are allowed in the CAID sub-field.
3.3.2.2 Data Description Identifier (DDID)
The Data Description Identifier, specified in the sixth sub-field (octets 8 to 11) of the LABEL contains
the identifier of the data description information held at the Control Authority Office, as identified by the
CAID.
Only RA characters are allowed in the DDID sub-field.
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
3.3.3 Class ID
The Class ID, specified in the third sub-field (octet 5) of the LABEL, indicates the kind of data contained
in the VALUE field following the LABEL. The Class ID must be selected from those approved by the
CCSDS. A list of approved Class IDs is found in Section 4.
Only RA characters are allowed in the Class ID sub-field.
3.3.4 Delimitation ID
This single octet sub-field (octet 6) of the LABEL specifies the manner in which the LVO is delimited.
Table 3-1 lists the defined Delimitation IDs and their corresponding delimitation techniques. These
techniques use, as necessary, the value contained within the Delimitation Parameter sub-field to
complete the delimitation technique description.
Delimitation ID Delimitation Technique
A Length (specified in ASCII)
B Length (specified in binary)
S Marker Pattern
E Sequential End-of-File
C Contiguous End-of-File
F Shared End-of-File
Table 3-1: Delimitation IDs
Note: End-of File (EOF) is a concept common to many storage systems and is
widely used for delimitation of data sets. However its physical implementation
is specific to individual media/operating systems. Any of the above
delimitation techniques that make use of EOF treat it conceptually without
defining its implementation. It is assumed that the creation and recognition of
EOFs are operations which can be performed for the specific media/operating
systems on which these LVOs are stored or transmitted.
(4)
3.3.4.1 Length (Specified in ASCII) - Delimitation ID = A
The length of the VALUE field, in units of octets, is specified in the Delimitation Parameter sub-field
(octets 12 to 19) of the LABEL. The length is specified in decimal and represented in the numeric
character subset of RA. The eight octets specified for the Delimitation Parameter sub-field makes
possible a VALUE field length of up to 10 -1 octets.
(4)
This delimitation technique replicates the functionality of that indicated by a Version ID = 1. Support for LVOs with Version ID
= 1 are retained for compatibility with previous versions of this Recommendation.
Issue 2 May 1992
CCSDS Recommendation for SFDUs: Structure and Construction Rules
(5)
3.3.4.2 Length (Specified in Binary) - Delimitation ID = B
The length of the VALUE field is specified in binary in the Delimitation Parameter sub-field (octets 12
to 19) of the LABEL. The eight octet sub-field specifies a 64 bit binary number that provides for a
VALUE field length of up to 2 -1 octets.
3.3.4.3 Marker Pattern - Delimitation ID = S
Delimitation by Marker Pattern employs a twenty octet
marker pattern to indicate the end of the VALUE field. This
delimitation technique is intended for use when the length
of the VALUE field cannot be determined at the time of
generation of the LABEL, or when transfer protocols or
other processing may change the actual length of the LVO.
Therefore an in-line 20 octet marker pattern is inserted
when the VALUE field is complete. The first twelve octets
of this marker pattern is a fixed pattern and must be
’CCSD$$MARKER’; the remaining eight octets are user
specified in the Delimitation Parameter sub-field of the
LABEL. Schematically an LVO delimited by marker pattern Figure 3-6: Schematic of a Marker
can be described as shown in Figure 3-6. (Note: the lower Pattern Delimited LVO
case letters in Figure 3-6 represent variable user-specified
sub-fields)
As shown, the marker pattern has the following format:
CCSD$$MARKERxxxxxxxx
The eight octet xxxxxxxx part of the marker pattern is the user specified part and can be any
characters from the ASCII character sub-set, decimal codes 32 to 126 (See Annex D).
An LVO employing this delimitation technique is terminated when the complete marker pattern (i.e.,
CCSD$$MARKERxxxxxxxx, where x
...