ISO 12175:1994/Amd 1:2015
(Amendment)Space data and information transfer systems — Standard formatted data units — Structure and construction rules — Amendment 1
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
General Information
Relations
Standards Content (Sample)
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
---------------------- Page: 1 ----------------------
ISO 12175:1994/Amd.1:2015(E)
COPYRIGHT PROTECTED DOCUMENT
© 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
---------------------- Page: 2 ----------------------
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
---------------------- Page: 3 ----------------------
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
---------------------- Page: 4 ----------------------
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
---------------------- Page: 5 ----------------------
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
---------------------- Page: 6 ----------------------
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
---------------------- Page: 7 ----------------------
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
---------------------- Page: 8 ----------------------
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
---------------------- Page: 9 ----------------------
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
---------------------- Page: 10 ----------------------
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
---------------------- Page: 11 ----------------------
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
1
---------------------- Page: 12 ----------------------
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
2
---------------------- Page: 13 ----------------------
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
3
---------------------- Page: 14 ----------------------
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
4
---------------------- Page: 15 ----------------------
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
5
---------------------- Page: 16 ----------------------
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
6
---------------------- Page: 17 ----------------------
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
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.