![](media/image1.emf){width="4.19375in" height="1.2902777777777779in"}

  -----------------------------------------------------------------------
  **PANEL 2 OVERVIEW**

  -----------------------------------------------------------------------

**CCSDS 600.0-G-0.2**

**DRAFT GREEN BOOK**

November 1996

![](media/image2.emf){width="3.620138888888889in"
height="1.7347222222222223in"}

**AUTHORITY**

  ---- -------------------- ------------------------------------------ ----
                                                                       

       Issue:               Draft Green Book, Issue 0.2                

       Date:                November 1996                              

       Location:            TBD                                        

                                                                       
  ---- -------------------- ------------------------------------------ ----

**(WHEN THIS REPORT IS FINALISED, IT WILL CONTAIN THE FOLLOWING
STATEMENT OF AUTHORITY:)**

This document has been approved for publication by the Management
Council of the Consultative Committee for Space Data Systems (CCSDS) and
represents the consensus technical agreement of the participating CCSDS
Member Agencies. The procedure for review and authorisation of CCSDS
Reports is detailed in reference \[1\], and the record of Agency
participation in the authorisation of this document can be obtained from
the CCSDS secretariat at the address below.

This document is published and maintained by:

> CCSDS Secretariat
>
> Program Integration Division (Code OI)
>
> National Aeronautics and Space Administration
>
> Washington, DC 20546, USA

**FOREWORD**

This document is a tutorial providing an overview of the standards that
CCSDS is developing related to standardised information interchange. It
provides the reader with a high level description of the major elements
of the Panel 2 approach and how they relate to one another.

This document is intended to fully acquaint the reader with the
requirements of a truly generic Information Interchange system and the
set of solutions (CCSDS Recommendations) being developed within Panel 2
to meet these requirements.

For information to be successfully interchanged, it is necessary for
both the desired data to be faithfully transported from the location
where it is resident (or being generated) to the location where it is to
be used AND for the recipient to be able to understand the data being
received.

Within a space agency, the problems associated with information are
compounded. The users are numerous and diverse, the \"partners\" in the
interchange activity may be separated by billions of kilometres and tens
of years and the need for associated metadata is critical.

This book is about a generic information interchange system which must
accommodate these requirements of long lived data, diverse users,
heterogeneous systems, the need to determine the existence and location
of desired data, and the need for supporting data (metadata, local
conventions, documentation, etc.) in order for the data user to fully
understand the data being received.

Through the process of normal evolution, it is expected that expansion,
deletion or modification to this document may occur. This Report 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.

At time of publication, the active Member and Observer Agencies of the
CCSDS were

[Member Agencies]{.underline}

> Ð British National Space Centre (BNSC)/United Kingdom.
>
> Ð Canadian Space Agency (CSA)/Canada.
>
> Ð Central Research Institute of Machine Building (TsNIIMash)/Russian
> Federation.
>
> Ð Centre National d\'Etudes Spatiales (CNES)/France.
>
> Ð Deutsche Forschungsanstalt fŸr Luft- und Raumfahrt e.V.
> (DLR)/Germany.
>
> Ð European Space Agency (ESA)/Europe.
>
> Ð Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
>
> Ð National Aeronautics and Space Administration (NASA HQ)/USA.
>
> Ð National Space Development Agency of Japan (NASDA)/Japan.

[Observer Agencies]{.underline}

> Ð Australian Space Office (ASO)/Australia.
>
> Ð Austrian Space Agency (ASA)/Austria.
>
> Ð Belgian Science Policy Office (SPO)/Belgium.
>
> Ð Centro Tecnico Aeroespacial (CTA)/Brazil.
>
> Ð Chinese Academy of Space Technology (CAST)/China.
>
> Ð Communications Research Laboratory (CRL)/Japan.
>
> Ð Danish Space Research Institute (DSRI)/Denmark.
>
> Ð European Organization for the Exploitation of Meteorological
> Satellites (EUMETSAT)/Europe.
>
> Ð European Telecommunications Satellite Organization
> (EUTELSAT)/Europe.
>
> Ð Hellenic National Space Committee (HNSC)/Greece.
>
> Ð Indian Space Research Organization (ISRO)/India.
>
> Ð Industry Canada/Communications Research Centre (CRC)/Canada.
>
> Ð Institute of Space and Astronautical Science (ISAS)/Japan.
>
> Ð Institute of Space Research (IKI)/Russian Federation.
>
> Ð KFKI Research Institute for Particle & Nuclear Physics
> (KFKI)/Hungary.
>
> Ð MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
>
> Ð Ministry of Communications (MOC)/Israel.
>
> Ð National Oceanic & Atmospheric Administration (NOAA)/USA.
>
> Ð National Space Program Office (NSPO)/Taiwan
>
> Ð Swedish Space Corporation (SSC)/Sweden.
>
> Ð United States Geological Survey (USGS)/USA.

**DOCUMENT CONTROL**

+-----------------+---------------------------+--------------+---------+
| ***Document***  | ***Title***               | ***Date***   | ***Sta  |
|                 |                           |              | tus/*** |
|                 |                           |              |         |
|                 |                           |              | ***Rem  |
|                 |                           |              | arks*** |
+-----------------+---------------------------+--------------+---------+
| CCSDS           | Report Concerning Space   | June 1995    | Issue   |
| 600.0-W-0.1     | Data System Standards:    |              | 0.1     |
|                 | Panel 2 Overview, White   |              |         |
|                 | Book, Issue 0.1           |              |         |
+-----------------+---------------------------+--------------+---------+
| CCSDS           | Report Concerning Space   | October 1996 | Issue   |
| 600.0-G-0.1     | Data System Standards:    |              | 0.1     |
|                 | Panel 2 Overview, Draft   |              |         |
|                 | Green Book, Issue 0.1     |              |         |
+-----------------+---------------------------+--------------+---------+
| CCSDS           | Report Concerning Space   | November     | Issue   |
| 600.0-G-0.2     | Data System Standards:    | 1996         | 0.1     |
|                 | Panel 2 Overview, Draft   |              |         |
|                 | Green Book, Issue 0.2     |              |         |
+-----------------+---------------------------+--------------+---------+

**REFERENCES**

\[1\] \"Procedures Manual for the Consultative Committee for Space Data
Systems\", CCSDS A00.0-Y-5.0, Yellow Book, Issue 5, Consultative
Committee for Space Data Systems, May 1992.

\[2\] \"CCSDS Achievements and Products: Info to be supplied

\[3\] \"SFDU: Structure and Construction Rules\" CCSDS 620.0-B-2 , Blue
Book, Issue 2, Consultative Committee for Space Data Systems, May 1992

Document also available via Internet at url:

http://bolero.gsfc.nasa.gov/ccsds/ccsds_publications.html

The latest issues of these CCSDS documents may be obtained from the
CCSDS Secretariat at the address indicated on page i. They are also
available via the Internet at the Uniform Resource Locator (url) shown.

**[CONTENTS]{.underline}**

**1. Introduction**

1.1 Purpose and Scope

1.2 Document Organisation

2\. Panel 2 Work

2.1 General CCSDS Organisation

2.2 Panel 2 Objectives and Approach

3\. Automated Information Interchange

3.1 General

3.2 Problems in Understanding, Accessing, Locating and Transferring
Information

3.3 Panel 2 Approach to the Problems

4\. Current Panel 2 Standards

4.1 Data Description Writing

4.1.1 Data Description Languages

4.2 Data Packaging

4.3 Data Administration

4.4 Data Archiving

4.4.1 Reference Model for an Open Archival Information System

4.5 Software Support Tools

4.6 Environment of Panel 2 Approach

5\. P2 Document Tree

5.1 CCSDS Panel Products / ISO Status

5.2 Structure of the Document Tree

6\. Application of CCSDS Recommendations

7\. Panel 2 Future Work

8\. Appendix A ACRONYMS AND ABBREVIATIONS

***[FIGURES]{.underline}***

Figure 1: Generalised Space data Distribution Architecture

Figure 2: Problems of understanding and access

Figure 3: The LABEL-VALUE-OBJECT Structure

Figure 4: Schematic of a More Complex SFDU Structure

Figure 5: Data Transfer Using the SFDU Concept

Figure 6: Typical Scenario for SFDU Data Interchange

Figure 7: CCSDS Document Production Procedure and its Relationship to
Agency Standards Production

Figure 8: CCSDS Document Tree

Figure 9: Standardised Information Interchange Document Tree

# Introduction

## Purpose and Scope

The purpose of this document is to provide an overview of the standards
that the Consultative Committee for Space Data Systems (CCSDS) Panel 2
is developing on automated information interchange. Within the CCSDS,
Panel 2 has the responsibility to investigate the processes of
interchanging space related information among autonomous, distributed
and heterogeneous systems having wide variations in the time between the
generation and application of said information.

This document describes the requirements associated with the
interchanging of space related information in the most generic sense and
the approach taken to solving these problems. It highlights the major
elements of the Panel 2 approach and how they relate to one another, and
describes its implementation details. It is intended to provide data
system designers with an overview to understand what Panel 2
Recommendation may apply to their problem domain.

## Document Organisation

This document is organised as follows:

-   Section 2 outlines the objectives and approach of the CCSDS
    Information Interchange Standards.

-   Section 3 explains the problems associated with the automated
    information interchange and how Panel 2 approaches to these
    problems.

-   Section 4 describes the current Panel 2 standards.

-   Section 5 defines the principles, conventions and contents of the
    document tree for CCSDS Recommendations and related documents in the
    area of Standardised Information Interchange.

-   Section 6 lists examples of missions and/or facilities which are
    using in some areas the Panel 2 CCSDS recommendations

-   Section 7 outlines the currently planned Panel 2 future work

-   Appendix A provides the list of acronyms and abbreviations

# Panel 2 Work

## General CCSDS Organisation

In 1982 a number of the world\'s space agencies met to discuss problems
common to space information and data systems. It had long been realised
that the growing complexity of space missions as well as their
associated costs could adversely impact space endeavours in the future
unless specific efforts were undertaken to meet these concerns.
Accordingly, the Consultative Committee for Space Data Systems (CCSDS)
was established to perform end-to-end system analyses and to develop
advanced solutions to these common problems.

The Committee\'s objective is to establish Recommendations in particular
in those areas where interoperability between different space agencies
is already, or is likely to become, important.

The Committee\'s activities are executed by various panels of technical
experts. They are supported by a Secretariat and co-ordinated by a
Technical Steering Group and the Management Council, the latter being
composed of the Senior Representatives of the Member Agencies plus the
Panel Chairmen. This Organization is depicted in Reference \[2\].

These solutions are formally reviewed and accepted by the CCSDS member
agencies before they are released as approved Recommendations (\'Blue
Books\' in CCSDS terminology). Details of this procedure are described
in the CCSDS Procedures Manual, Reference \[1\].

Although the participating agencies are not obliged to adopt the
Recommendations, their use will not only reduce the cost and time
impacts of unique systems developments within individual agencies but
will also provide further collective benefits through the promotion of
cross support opportunities. As indicated in Reference \[2\], a growing
number of space missions and programs are adopting CCSDS
Recommendations.

## Panel 2 Objectives and Approach

Panel 2 has identified its mission as providing Recommendations that can
facilitate the development of an open, integrated, efficient and
effective environment (the Information system) whereby any user can:

-   determine the availability of, or request the creation of, or make
    known the location of,

-   access or insert, when allowed,

-   transfer

-   understand or describe,

-   archive

-   use

data (and metadata) that has been, is being, or can be created at a
different time and place by an entity (e.g. instrument, individual or
Organization) from an environment that may be foreign to the user.

To date, P2 has concentrated on the fourth requirement, \"understand or
describe\" data . Work is currently being initiated on standards for
data archiving to meet the fifth requirement.

The high level services associated with data understanding and
describing are seen to include:

1.  Describe data objects via computer readable or processable data
    descriptions;

2.  To identify data descriptions and to associate that with the data;

3.  Store, retrieve and administrate data descriptions;

4.  Parse data products to extract data objects;

5.  Interpret the contents of data objects down to the bit or byte level
    by means of the data descriptions.

CCSDS has developed (or is developing) a set of Recommendations which
defines standardised approaches to all of these tasks:

-   Task 1 is covered by Recommendations addressing data description
    languages (syntax) and data entity dictionaries (semantics).

-   Task 2 is covered by Recommendations addressing structure and
    construction rules.

-   Task 3 is covered by Recommendations addressing Data (description)
    Administration and Management.

-   Task 4 is covered by software programs and techniques being
    developed by P2.

-   Task 5 is covered by recommendations on Data Interchange Languages.

# Automated Information Interchange

## General

In the context of CCSDS Panel 2, \"Information Interchange\" refers not
to the transport of data, but to the application-level packaging and the
understanding of data or information, that is, data plus its
description. A general information interchange scheme is depicted in
Figure 1.

![](media/image3.emf)

Figure 1: Generalised Space data Distribution Architecture

In this scheme, the users of the various types of data will, in general,
be remote from the suppliers of data. Moreover, a given user may require
different types of data (quick look data, data products as they are
generated, archive data), i.e., these users are not necessarily mutually
exclusive.

## Problems in Understanding, Accessing, Locating and Transferring Information

The problems that Panel 2 is addressing under the Data Interchange
concept are depicted in Figure 2. This figure is a model of the typical
information interchange process as viewed from the perspective of
understanding, locating, accessing and transferring the information.

![](media/image4.emf)

Figure 2: Problems of understanding and access

Data producers, which include any source of digital data ranging from
instruments to project production processing to individual investigator
data sets, are viewed as holding various types of data together with an
understanding of this data. This understanding is often partially
documented in notes and local documents, and includes local conventions
that may or may not be documented, and even information that is implicit
in software. Some of the information, including the relationships among
these data and other information sources, may not be documented
anywhere.

To make the primary data of interest (e.g., application and supporting
data) available to consumers, the data producer decides on a way to
package the data and also generates a description of the data. Typically
this description is a stand-alone document, which may reference other
documents that may or may not be readily available to future data
consumers. The data producer usually follows his or her own instincts in
determining the level of detail, scope, and organisation of data
description documents.

The data and documentation may be sent immediately to one or more data
consumers, or it may go into archives. Even the data consumer, upon
receiving the data, may archive it for some time before attempting to
use it. The time and space separation between data production and data
consumption can easily result in lost documentation.

Upon receipt of the data, which may arrive on physical media such as
magnetic tapes, optical disks, or via electronic network file transfers,
the data consumer\'s first problem is to identify what has arrived and
to match the documentation with the data. Even today\'s self-describing
data formats seldom carry enough supporting information to do much
scientific analysis with the data and thus need additional
documentation. Matching the data and documentation, even when candidate
documentation has been found, often involves trying to match information
on external media labels with document titles.

Once the correct documentation has been located, the next problem is to
understand the material. The uniqueness of each document poses a severe
burden on the data consumer who is trying to understand the format and
meaning of the data. It can be likened to learning a new language - one
that the data producer has created and documented in a unique way. In
addition, it is very easy for the data producer to leave important
information out of the document because it is common knowledge in the
data producer\'s local environment.

Once the documentation is understood, at least to a level the consumer
thinks is adequate to begin trying to use the data, the next problem is
to write software to access the data. Even if the data are in a
self-describing format and the consumer has appropriate access software,
additional software may be needed to extract and present subsets of data
values in a way that is most productive in meeting the consumer\'s
needs.

For a given space mission operations system, data formats are normally
negotiated before launch and are, therefore, known and documented within
the environment of that mission. However, in generic information
interchange, the data being interchanged may be many years old or may
involve different projects or disciplines. Thus it cannot be assumed
that the user accessing the data is fully aware of the conventions,
computer environment, etc. used in originally creating the data.
Therefore techniques must exist to provide full description of the data
at both the logical and physical levels, so that the data can be read
and understood independently of the availability of the original system
(hardware and software) on which it was created.

##  Panel 2 Approach to the Problems

The Table below highlights the Panel 2 approach to these problems.

+-----------------+----------------------------------------------------+
| **PROBLEM**     | **PANEL 2 APPROACH**                               |
+=================+====================================================+
| Matching Data   | -   Standard mechanism to unambiguously link data  |
| and             |     structures and descriptions                    |
| Documentation   |                                                    |
|                 | -   Standards supporting an infrastructure to      |
|                 |     maintain descriptions and assist users         |
+-----------------+----------------------------------------------------+
| -               | -   Standards supporting the writing of data and   |
|   Understanding |     data descriptions                              |
|     each        |                                                    |
|     Producer\'s | -   Accommodate existing and future format         |
|     Unique      |     standards                                      |
|                 |                                                    |
|   Documentation |                                                    |
+-----------------+----------------------------------------------------+
| -   New Access  | -   Science discipline-independent standards       |
|     Software    |     support use of generic software                |
|     for each    |                                                    |
|     Product     | -   Data identification                            |
|     received    |                                                    |
|                 | -   Data packaging                                 |
|                 |                                                    |
|                 | -   Data understanding to level supported by       |
|                 |     standards used                                 |
+-----------------+----------------------------------------------------+

The problem of matching data and documentation is addressed by creating
a standard mechanism to unambiguously link data structures with their
descriptions, while allowing these descriptions to be completely
separated from the data structures. This is done by associating a small
label with each data structure (data object), and including a unique
identifier of the data description in that label. The assignment of
these unique identifiers is controlled by a standard for a supporting
infrastructure which registers, maintains, and disseminates the data
descriptions. This supporting infrastructure, called the Control
Authority (CA), is an internationally co-ordinated set of agency
organisations called Control Authority Offices . These Control Authority
Offices also provide a convenient mechanism by which agencies can assist
users in applying the Panel 2 standards for information interchange.

The problem of understanding each producer\'s unique documentation is
addressed by creating standards for the writing of data descriptions.
Data descriptions can be extremely complex, ranging from descriptions of
bit patterns for simple data types such as integers and reals to high
level semantics such as instrument descriptions and observation
philosophy. All of this information must be understood by the consumer,
or some combination of the consumer and the consumer\'s local software,
to support a full and correct analysis of the data. Today there is no
single language (i.e., data description language, format, or
self-describing data structure) that can be used to describe data AND
also be understood by machines (i.e., hardware/software). Consequently
one or more machine interpretable languages are usually combined with a
natural language, such as English, to obtain some level of automated
understanding together with a complete description of the data. Panel 2
standards include English as the natural language and an evolving set of
machine interpretable languages able to describe basic record formats,
associate names with values, and associate names with their English
descriptions in a dictionary form. Note that by approaching the data
understanding problem from a data description perspective, the Panel 2
approach is inherently compatible with existing and future format
standards, including so called \'self-describing formats\', because some
combination of Panel 2 description writing standards can always be used
to fully describe the data. A major challenge is to increase the
functionality of machine interpretable languages.

The problem of having to write new access software for each new data
product received is addressed by Panel 2 standards that are discipline
independent and that support automation of basic data ingest and parsing
functions. These functions include the identification of separate data
objects on the media being examined, the ability to parse these data
objects into identified sub-objects in a recursive manner until the
simplest data elements are obtained, the ability to present the meanings
of the data elements to the data consumer, and the ability to understand
the relationships among the data objects and data elements to the level
supported by the particular standards used. Note that external software
supporting self-describing data formats can be incorporated based on the
CA assignment of unique identifiers.

# Current Panel 2 Standards

Panel 2 has developed an approach to the problem of information
interchange which includes a comprehensive set of techniques for
packaging data products and links to full descriptions of the data
objects, that provide an integrated solution to the problems presented
by the Information Interchange Process (IIP).

There are four major aspects of the IIP , namely :

-   Data Description Writing, which specifies notations and languages to
    enable the data producer to document the syntax (e.g., physical
    format) and semantics (e.g., meaning of names) of his data.

-   Data Packaging, which specifies mechanisms for the labelling of data
    objects and aggregation techniques for the association of related
    data objects.

-   Data Description Administration, which specifies an infrastructure
    to enable the registration, maintenance, and retrieval of data
    descriptions.

-   Data Archiving, which specifies a Reference Model and associated
    standards.

The Panel 2 specifications are designed to be highly modular and have
well-defined interfaces. This feature allows data descriptions that are
written in previously defined formats to use the data description
administration services provided by the SFDU Recommendations, and allows
existing data sets to use the specified labelling and aggregation
services.

CCSDS Recommendations have been, or are being developed in each of these
areas.

## Data Description Writing

Data description falls into two main areas:

1.  The description of the physical layout or formatting of the data (in
    essence the order, length and representation of data elements) -
    this is referred to as the **[syntax]{.underline}** of the data.

2.  The meaning of the data or its component data entities- this is
    referred to as the **[semantics]{.underline}** of the data.

Work on both of these aspects has been done and draft Recommendations
produced, the former under the heading of the Data Description Languages
(DDLs), the latter under Data Entity Dictionaries (DEDs).

An essential feature of the SFDU concept is that it imposes the
discipline of providing for each data object (i.e., LVO) a corresponding
data description to permit complete understanding of the data in the
value field of the LVO. These standard forms are not LVO forms, but they
are described in the P2 Recommendations.

Some of the LVOs may contain data description information. Such
descriptions do not need to be included when they have been registered
with an agency Control Authority organisation because data consumers can
always obtain them by request.

### Data Description Languages

Data description languages permit the writing of formal data
descriptions. In the simplest case, the data description would be
English expressed in ASCII text. However, this is not fully computer
processable and Panel 2 with the aim of automated exchange and
interpretation of data, has been examining computer-processable data
description languages, with greater automated functionality.

Work has been done on the following as briefly described below :

-   ASCII-Encoded English

-   Parameter Value Language (PVL)

-   Enhanced Ada Subset (EAST)

-   Modified ASN.1 (Abstract Syntax Notation One) as a Data Description
    Language (MADEL)

-   Data Entity Dictionary Specification Language ( DEDSL )

Section 5 presents an overview of the documentation produced on Data
Description Languages.

#### ASCII Encoded English

A Recommendation has been produced entitled \"ASCII Encoded English,
which defines a digital (ASCII) representation of a natural language
(English). It is intended for use within the SFDU environment in cases
where a machine interpretable language is not suitable or for
information that is best supplied in natural language.

#### Parameter Value Language (PVL)

PVL specifies a standard \"keyword = value\" language. This is a simple
language, primarily intended for applications such as catalogues, where
PVL gives a flexible means of assigning values to named parameters. It
is also used within the Recommendation for SFDU. It is not generally
intended for use as a full data description language, although it could
be applied as a data description language in fairly simple cases (such
as catalogues, as mentioned earlier).

#### EAST

A Recommendation has been produced on the use of the language Ada as
Data Description Language. In this case, some extensions to the language
is required. The data declaration subset of the language is used, but
extensions are needed, for example to deal with physical representation
aspects. Hence the DDL being developed is called the Enhanced Ada Subset
(EAST). This language is seen as complementary. Prototype tools have
been developed by Member Agencies to support the work.

#### MADEL

Work is in progress on the use of the language ASN.1 as Data Description
Language. In this case, some extensions to the language is required.
ASN.1 is already a data description language, intended for in-line (or
tagged) insertion of data description information. Here some
modifications are needed to extend the data description powers of basic
ASN.1 to describe the data exchanged. This language is seen as
complementary. Prototype tools have been developed by Member Agencies to
support the work.

#### Data Entity Dictionary Specification Language

Data Entity Dictionaries are concerned with the meaning of data
elements: they thus focus on the **semantics** of data.

Work is in progress on the definition of a specification language for a
standard Data Entity Dictionary. This concentrates on providing
conventions and techniques for defining standard names, meanings and
other attributes (such as units) of data items.

## Data Packaging

Panel 2 has developed a concept called the Standard Formatted Data Unit
(SFDU). The SFDU is **[not]{.underline}** a data format, but rather a
set of techniques for packaging data products. P2 establishes rules for
implementing standard data structures for data interchange rather than
using the data producer unique rules. 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). These P2 rules still leave considerable
discretion to the data producer, including the ability to maintain
existing data structures.

The LABEL field structure is completely specified in the Panel 2
recommendations. The VALUE field may contain any form of data that can
be described by a producer defined data description (registered
identifier) or by a CCSDS Recommendation (CCSDS identifier).

The LVO structure is shown schematically in Figure 3.

![](media/image5.emf)

Figure 3: The LABEL-VALUE-OBJECT Structure

Section 5 presents an overview of the documentation that includes
standards for LVO formation and aggregation.

The LABEL field specification depends upon the value of a sub-field in
the LABEL called the Version Identifier. The LABEL contains the
following information:

-   An unique identifier of the description of the \"format and
    meaning\" of the data in the VALUE field;

-   An identifier that gives a general classification of the type of
    data in the VALUE field; i.e. application data, supporting data,
    etc.

-   The necessary information required to delimit the VALUE field; i.e.
    length of VALUE field, occurrence of a user defined marker pattern,
    count of system generated end-of-files.

The SFDU concept provides the following:

-   Methods for building hierarchical data products from LVOs.

-   Methods for referencing of objects (e.g. files) physically external
    to the SFDU product. These can be used for incorporating data
    formatted using other standards (e.g. FITS).

P2 also specifies techniques which allow multiple LVOs to be aggregated
into units.

A more complex SFDU product is shown in Figure 4. It can be seen from
this figure that the different types of labels permit the building of a
hierarchical structure.

![](media/image6.emf)

Figure 4: Schematic of a More Complex SFDU Structure

The Panel 2 standards support the mapping of LVOs onto both sequential
(e.g., magnetic tape) and random access media (e.g., optical disks). For
example, these rules allow existing data files to be formed into LVOs
without any alteration to the data file content.

The time and space separation is bridged by the exchange of media and by
network transmissions. Upon receipt of media or transmissions containing
data, SFDU rules are used to extract the data view.

If the data consumer has a preferred form in which to maintain received
data, then the P2 rules and local standards may be used to map the data
into this form. This corresponds to local data ingest and may be
automated to the extent that the data producer has incorporated, in a
standard way, the information needed by the consumer. If this
information is contained in English text, then manual intervention and
possibly additional software will be needed to obtain the preferred
form.

## Data Administration

While the SFDU concept requires that the data descriptions are provided
for all data objects, it also provides for administrative services for
the registration and distribution of data descriptions. These
descriptions describe the format and meaning of the data objects. These
administrative services are provided by the Control Authority
Organisation. Figure 5 shows how the originator of the data can either
supply the data directly to a recipient within the SFDU, or register the
description with a Control Authority Office and refer to it using a
unique identifier. In the latter case the recipient can request the data
description from the Control Authority Office, irrespective of whether
he is receiving the data directly from the data producer, or requests it
at a much later data from a separate archive.

![](media/image7.emf)

Figure 5: Data Transfer Using the SFDU Concept

P2 Recommendation establishes the responsibilities of the CCSDS Control
Authority organisation, which comprises the Control Authority Agent (CA
Agent) acting for the CCSDS Secretariat, and Member Agency Control
Authority Offices (MACAOs) reporting to it. This Recommendation also
describes all the procedures to be followed within the Control Authority
Organisation and by the user community to register / archive / access
data descriptions.

Also included are the mechanisms to be used in establishing and
recognising a new CA Office. Additional services, such as supporting
users in the application of SFDU Recommendations and offering software,
may also be provided.

The recommendation describes standards for interfacing with Control
Authorities. These data structures contain the information needed to
register, revise and obtain data descriptions from MACAOs. These data
structures comprise the Registration Package (RP), the Revision
Registration Package (RRP) and Data Description Package (DDP), which
includes a minimum set of attributes about the description, such as name
and address of originator, list of revising authorities, title, brief
description, and release status.

The specifications forms of the RP, RRP, and DDP which may be exchanged
between users and CA Offices are contained in the Control Authority Data
Structures Recommendation.

These structures are in SFDU form and so may be used for automation of
the Control Authority Procedures. Work on the standardisation of
protocols and media for communication within the Control Authority
organisation is also foreseen.

The degree of automation associated with this understanding depends on
the formalism of the languages used to express the description, and/or
on related software.

Section 5 presents an overview of the documentation primarily addressing
standards for data description administration.

## Data Archiving

Panel 2 has accepted a work item from the International Organization for
Standardisation (ISO) for the development of archiving standards.

The first step is the development of an archiving reference model. When
this is sufficiently mature, further archiving standards will be
developed.

### Reference Model for an Open Archival Information System

The archiving reference model is under development and has two primary
objectives. The first objective is to establish common terms and
concepts which enable the description and comparison of current and
future archives, and which make the problems of long-term digital
information preservation. The second objective is to provide a framework
which enables the development of additional archive standards.

## Software Support Tools

Recognising the absolute necessity to provide tools to assist users in
understanding and utilising any new technology, P2 is developing the
following facilities :

-   A capability to manipulate SFDUs. Called the Science Data Users
    Workbench, the facility is designed to help researchers use
    information obtained from earth and space science data archives. It
    handles information formatted in accordance with the CCSDS
    Recommendation for SFDU Structures and Construction Rules
    \[Reference 3\]

> The Workbench can be used to create new SFDUs or copy SFDUs from one
> medium to another (for example, from CD-ROM to tape). It also allows
> users to view data by launching an appropriate display program. The
> Workbench architecture is based on principles derived from distributed
> computing, software reuse, object-oriented technology, and artificial
> intelligence. Each of the objects depicted in Figure \_\_ executes as
> a separate process. The objects communicate using TCP/IP and may be
> located on different processors.

-   A set of tools based on EAST

1.  Data Description

    A tool called OASIS allows the user to describe its data via a MMI
    which does not require any EAST knowledge. OASIS allows the user to
    add to this description some semantics attributes, which are used to
    produce both a formal semantic description expressed in DEDSL and an
    interface document ( free text )

2.  Data Manipulation

    2.1 Reading

    An "interpreter" offers an API to applications, which includes :

    \- access to the next data block in the input data flow

    \- access to a particular field in the data block

    2.2 Display

    A data viewer accesses the data ( using the API of the interpreter )
    and prints the value of each data file ( ASCII image of each type )

    2.3 Migration

    A tool allows to migrate data from an original format to a new
    format as soon as both formats are described in EAST. The user can
    move, suppress or duplicate data fields and also change the data
    field representation ( e.g. PC to SUN or binary to ASCII )

-   A tool called EISMAN which allows users, with or without experience
    in SFDU files, to browse and get all information contained in a very
    simple and user-friendly way. Some of its features are :

-   Interactive SFDU graphical view

-   LVO information data

-   Value raw dump view with wrap / no wrap

-   Automated process launching

-   Fully on-line configuration

-   Search engine : search by ADID or, ADID and Value Field

-   Windows like file browsing system

-   Multiple SFDU / Window handling

```{=html}
<!-- -->
```
-   An SFDU prototype which allows

-   Both SFDU Generator and Parser

-   SFDU LVO Structure Construction and Analysis

-   SFDU Language ( DDR , DED ) Generation and Interpretation

-   Implementation of both EAST and TSDN

-   Tree display of the Data Description Structure tree

## Environment of Panel 2 Approach

Figure 6 shows a typical environment view of the Panel 2 approach. This
figure describes a typical data flow ( indicated by numbers ) starting
(1) when a generic user requests any type of data from a generic data
centre and ending (6) with the data extraction, interpretation and
analysis on its own personal archive. The data interchanged may or may
not contain the data description. The latter case means that the user
has to ask the data description ( d and e ) to the Control Authority
Office ( previously registered by the Data Centre - a and c -). The Data
Centre also keeps the Data Descriptions in the Central Archive ( b ).
This information flow is shown by letters on figure 6.

![](media/image8.emf)

Figure 6: Typical Scenario for SFDU Data Interchange

# P2 Document Tree

## CCSDS Panel Products / ISO Status

The CCSDS products take the form of \"Blue Books\" and \"Green Books\".
Blue Books contain the CCSDS Recommendations and the Green Books are
technical reports which provide supplementary or supporting information
to CCSDS Recommendations.

The Blue Books are committed to the principle of long term technical
stability. They are published after a process of technical discussion
and review in the CCSDS Panels and by CCSDS member and observer
agencies. During this process intermediate issues of the books are
published. These are the so-called White and Red Books, the former being
intended for review within the relevant panel, and the latter being used
for the Formal Agency Review.

Figure 7 shows the procedures for the production of these books.

![](media/image9.emf)

Figure 7: CCSDS Document Production Procedure and its Relationship to
Agency Standards Production

## Structure of the Document Tree

A high-level document tree, as envisaged at the time of issue of this
document is provided below. The tree provides a context structure for
current and planned documents. The documentation tree is restricted to
Recommendations (Blue Books) and Reports (Green Books), that is,
documents subject to formal approval either by Member Agencies or by
CCSDS Management Council. The documentation tree does **not** include
working documents such as concept papers and position papers,
administrative documents (e.g. Yellow Books, management plans), and
documents in intermediate stages of production of Recommendations and
Reports, that is White Books and Red Books.

Figure 8 shows the CCSDS Document Tree. There are eight branches in
terms of the topic area designator:

Telemetry (100)

Telecommand (200)

Ancillary Data (300)

Radio Frequency & Modulation (400)

Tracking and Navigation (500)

Information Access and Interchange (600)

Advanced Orbiting Systems (700)

Ground Network and Communications (800)

Cross Support Concepts, Services and Architecture (900)

![](media/image10.emf)

Figure 8: CCSDS Document Tree

The present report is concerned only with the sub-tree CCSDS
Standardised Information Interchange (series 600), which is shown in
Figure 9.

![](media/image11.emf)

Figure 9: Standardised Information Interchange Document Tree

The Information Interchange Document Tree is structured to follow the
general P2 procedure. It should be noted that the procedure is iterative
in that some documents are developed to a certain degree. Then others
are developed and the material developed in this second document may be
such that the first document requires modification.

Given below is a brief description of each category of the document
together with those documents issued by CCSDS at the time of this
document\'s publication. The reader is cautioned that since the document
list is a dynamic entity, a complete list of current documents is only
maintained in Reference \[2\]. The list in this document should not be
considered complete.

***P2 Overview***

This covers the overall requirements for data exchange, determined by
studying data exchange processes and basic concepts for meeting these
requirements. It serves as a Green Book for the entire P2 activity by
describing the scope of standardised information interchange. It will be
updated periodically to address new P2 endeavours.

This document is CCSDS 600.0-G-1

**P2 User Requirements**

This document identifies through systems analysis, scenarios and real
life experiences the overall requirements for information interchange.

\[1\] Report Concerning Space Data System Standards: Space Data System
Operations with Standard Formatted Data Units: Systems and
Implementation Aspects, CCSDS 610.0-G-5, Green Book, Issue 5, February
1987

***Data Packaging***

Documents in this category cover the definition of structures and rules
for packaging data products and data descriptions. These rules also
include mechanisms for linking data objects to data descriptions.

\[1\] Recommendation for Space Data System Standards: Standard Formatted
Data Units \-- Structure and Construction Rules, CCSDS 620.0-B-2, Blue
Book, Issue 2, May 1992

-   Specifies version 3 LABELS which allow delimitation by length,
    marker, and End Of File

-   Specifies CCSD0003, CCSD0005 and CCSD0009 packaging

-   Defines Classes C, R, E, V, K, U, F to allow more detailed
    classification of LVOs

-   C : Data Administration Service Object

-   R : Replacement service Object

-   E : DED Object

-   V : Volume Preparation Data Object

-   K : Catalogue Attribute Object

-   U : Application Data Unit

-   F : Description Data Unit

-   

\[2\] Report Concerning Space Data System Standards: Standard Formatted
Data Units \-- A Tutorial, CCSDS 621.0-G-1, Green Book, Issue 1, May
1992

-   Informal explanation of the SFDU concept, plus examples using the
    techniques

***Data Administration***

Under the heading \"Data Administration\" are found Recommendations and
Reports concerning the organisation, procedures and interchange
structures for managing data descriptions.

\[1\] Recommendation for Space Data System Standards: Standard Formatted
Data Units \-- Control Authority Procedures, CCSDS 630.0-B-1, Blue Book,
Issue 1, June 1993

-   Specifies the minimum responsibilities and services of the CA
    organisation

-   Establishes the mechanisms by which new CA Offices are recognised

-   Specifies the encoding scheme for ADID assignments to ensure
    uniqueness

-   Specifies the minimum attributes needed in a data description
    Registration Package

-   Specifies an annual report for the dissemination of CA related
    information

-   Provides context and rationale for the CA Data Structures

\[2\] Report Concerning Space Data System Standards: Standard Formatted
Data Units \-- Control Authority Tutorial, CCSDS 631.0-G-1, Green Book,
Issue 1, June 1993

-   Provides context and rationale for the establishment of the CA
    organisation

\[3\] Recommendation for Space Data System Standards: Standard Formatted
Data Units \-- Control Authority Data Structures, CCSDS 632.0-B-1, Blue
Book, Issue 1, November 1994

-   Provides specifications for Registration Packages, Revision
    Registration Packages, and Data Description Packages in terms of
    CCSD0005

-   

Specifies standard forms for expressing required registration attributes
(e.g., name, meaning, title, units, etc.)

***Data Description***

Included in this category are documents describing languages used to
write data descriptions of data set formats (syntax) and dictionaries to
provide the meaning (semantics) of data terms.

\[1\] Recommendation for Space Data System Standards: Parameter Value
Language Specification (CCSD0006), CCSDS 641.0-B-1, Blue Book, Issue 1,
May 1992

-   Provides specifications for a standard keyword / value type language
    for naming and expressing data values

\[2\] Report Concerning Space Data System Standards: Parameter Value
Language - A Tutorial, CCSDS 641.0-G-1, Green Book, Issue 1, May 1992

\[3\] Recommendation for Space Data System Standards: ASCII Encoded
English (CCSD0002), CCSDS 643.0-B-1, Blue Book, Issue 1, May 1992

***Archiving***

Documents in this category provide a reference model for an archival
information system and additional archive standards. No documents have
been completed at this time

***Test / Applications***

These are currently no release documents. This category provides test
methodologies and test results from activities conducted to validate P2
Recommendations before they are released external to CCSDS. Also,
applications are provided to assist potential user in adopting these
recommendations

***Tools and Software***

Documents in this category provide tools and software programs to assist
the user in understanding and utilising the technology being developed
within P2. Documents are available via Internet at url:

> http://bolero.gsfc.nasa.gov/ccsds/ccsds_publications.html

# Application of CCSDS Recommendations

The following tables show a number of examples of acceptance by missions
and/or facilities of the Panel 2 Recommendations within each CCSDS
agency. The recommendations are being used in some areas within the
mission / project and not everywhere.

A tick indicates that they are being used, N/A means that they are not
being used and a \"-\" indicates that they are under consideration for
future use. Furthermore, some of the missions/facilities are currently
implemented whilst other are in the process of being implemented or are
planned ; this is also indicated in the table.

Additionally, the CCSDS is developing a compendium of CCSDS compatible
products which have been, or are being developed by industries globally.
At this time, the document is being assembled and is not available for
release. When it is completed, it will be referenced in this document.

**NASA**

+-----------------+-----------+---------+------+-----------+---------+
| **Pro           | **Impl    | **      | **P  | **SFDU    | **      |
| ject/Facility** | emented** | ASCII** | VL** | Pa        | Control |
|                 |           |         |      | ckaging** | Auth    |
|                 | **/       | **En    |      |           | ority** |
|                 | Planned** | glish** |      |           |         |
+=================+===========+=========+======+===========+=========+
| Data            | I         |        |     |          |        |
| Distribution    |           |         |      |           |         |
| Facility        |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| NSSDC^†^        | I         |        |     |          |        |
+-----------------+-----------+---------+------+-----------+---------+
| AMMOS           | I         | N/A     |     |          | N/A     |
+-----------------+-----------+---------+------+-----------+---------+
| JPL/Planetary   | I         | N/A     |     |          | N/A     |
| Data System     |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| NSSDC Control   | I         |        |     |          |        |
| Authority       |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| UARS Control    | I         |        | N/A  |          |        |
| Authority       |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| JPL Control     | I         |        |     |          |        |
| Authority       |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| ISTP/GGS        | I         |        |     |          |        |
+-----------------+-----------+---------+------+-----------+---------+
| UARS            | I         |        | N/A  |          |        |
+-----------------+-----------+---------+------+-----------+---------+
| SOHO^‡^         | I         |        |     |          |        |
+-----------------+-----------+---------+------+-----------+---------+
| Dynamics        | I         |        | N/A  |          |        |
| Explorer^†^     |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| Pioneer         | I         |        | N/A  |          |        |
| 10/11^†^        |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| Halley Watch    | I         |        |     |          |        |
| CD-ROMs         |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| ISEE^‡^         | I         |        | N/A  |          |        |
+-----------------+-----------+---------+------+-----------+---------+
| SMM^‡^          | I         |        | N/A  |          |        |
+-----------------+-----------+---------+------+-----------+---------+
| EOSDIS          | P         | \-      |     |          |        |
+-----------------+-----------+---------+------+-----------+---------+

^†^ Some data objects conform to a draft version of the SFDU
Recommendation.

^‡^ Data and description from a few instruments only.

**ESA**

+-----------------+-----------+---------+------+-----------+---------+
| **Project**     | **Impl    | **      | **P  | **SFDU    | **      |
|                 | emented** | ASCII** | VL** | Pa        | Control |
|                 |           |         |      | ckaging** | Auth    |
|                 | **/       | **En    |      |           | ority** |
|                 | Planned** | glish** |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| EURECA          | I         | N/A     | N/A  |          | N/A     |
+-----------------+-----------+---------+------+-----------+---------+
| Cluster /       | I         |        |     |          |        |
| Phoenix         |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| Huygens         | P         |        |     |          |        |
+-----------------+-----------+---------+------+-----------+---------+
| XMM             | P         |        |     |          |        |
+-----------------+-----------+---------+------+-----------+---------+

**CNES**

+-----------------+-----------+---------+------+-----------+---------+
| **Project**     | **Impl    | **      | **P  | **SFDU    | **      |
|                 | emented** | ASCII** | VL** | Pa        | Control |
|                 |           |         |      | ckaging** | Auth    |
|                 | **/       | **En    |      |           | ority** |
|                 | Planned** | glish** |      |           |         |
+=================+===========+=========+======+===========+=========+
| Science Data    | P         | N/A     | N/A  |          |        |
| Management      |           |         |      |           |         |
| Services        |           |         |      |           |         |
| (Archiva        |           |         |      |           |         |
| l/Distribution) |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| CST Control     | P         |        | N/A  |          |        |
| Authority       |           |         |      |           |         |
| (Toulouse Space |           |         |      |           |         |
| Centre)         |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| MARS96          | P         |        | N/A  |          |        |
+-----------------+-----------+---------+------+-----------+---------+
| Swedish Viking  | I         | N/A     | N/A  |          |        |
| Archive         |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| ISEE 1-2        | P         | N/A     | N/A  |          |        |
| Archive         |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| PHOBOS Archive  | P         | N/A     | N/A  |          |        |
+-----------------+-----------+---------+------+-----------+---------+

**BNSC**

+-----------------+-----------+---------+------+-----------+---------+
| **Project**     | **Impl    | **      | **P  | **SFDU    | **      |
|                 | emented** | ASCII** | VL** | Pa        | Control |
|                 |           |         |      | ckaging** | Auth    |
|                 | **/       | **En    |      |           | ority** |
|                 | Planned** | glish** |      |           |         |
+=================+===========+=========+======+===========+=========+
| Cluster /       | P         |        |     |          | N/A     |
| Phoenix         |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+
| Solar           | I         |        |     |          | N/A     |
| Terrestrial     |           |         |      |           |         |
| Physics Data    |           |         |      |           |         |
| Facility        |           |         |      |           |         |
+-----------------+-----------+---------+------+-----------+---------+

# Panel 2 Future Work

There is still work to be done under the current P2 thrust \"understand
and describe\" data, including:

• Complete the development of the following CCSDS Recommendations (and
supporting documents):

-   Report Concerning Space Data System Standards: Standardized Data
    Interchange \-- Methodology for Development of Recommendations
    Document, Yellow Book.

```{=html}
<!-- -->
```
-   Recommendation for Space Data System Standards: Standard Formatted
    Data Units \-- Control Authority Operations, Green Book,

-   Recommendation for Space Data System Standards: Enhanced Ada Subset
    (EAST) as a Data Description Language - Specification (CCSD0010),
    Blue Book.

```{=html}
<!-- -->
```
-   Report Concerning Space Data System Standards: Enhanced Ada Subset
    (EAST) as a Data Description Language - A Tutorial (CCSD0010), Green
    Book.

```{=html}
<!-- -->
```
-   Report Concerning Space Data System Standards: Data Interchange
    Languages \-- Logical Model and Requirements, Green Book

```{=html}
<!-- -->
```
-   Recommendation Concerning Space Data System Standards: Data Entity
    Dictionary Specification Language (DEDSL) \-- Specification, Blue
    Book.

```{=html}
<!-- -->
```
-   Report Concerning Space Data System Standards: Data Entity
    Dictionary Specification Language (DEDSL) \-- A Tutorial, Green
    Book.

-   Report Concerning Space Data System Standards: Referencing
    Environment \-- Specification, Blue Book.

Other areas for standardisation, although not yet the focus of P2,
include developing:

-   Master Directories to meet requirements for \"determining the

availability of, or make known the location of data\"

-   increasingly sophisticated tools to improve the \"use\" of data

It must be pointed out that there is a large and growing community of
related, commercial standards from which P2 plans to adopt or adapt as
appropriate to its needs. Not all CCSDS standards will be developed
uniquely under CCSDS funding.

CCSDS Panel 2 welcomes all comments on its work plan directions

# Appendix A ACRONYMS AND ABBREVIATIONS

This annex defines the acronyms and abbreviations which are used
throughout this Recommendation.

  ------------------------ ------------------------------------------------------------
  **[Term]{.underline}**   **[Meaning]{.underline}**

  ADID                     Authority and Description Identifier

  ASCII                    American Standard Code for Information Interchange

  ASN.1                    Abstract Syntax Notation One

  CA                       Control Authority

  CCSDS                    Consultative Committee for Space Data Systems

  DDL                      Data Description Language

  DDP                      Data Description Package

  DDR                      Data Description Record

  DED                      Data Entity Dictionary

  DEDSL                    Data Entity Dictionary Specification Language

  EAST                     Enhanced Ada Subset

  EISMAN                   ESA Interactive SFDU MANipulator

  EOF                      End Of File

  ISO                      International Organization for Standardisation

  LVO                      Label Value Object

  MACAO                    Member Agency Control Authority Office

  MADEL                    Modified ASN.1 as a Data Description Language

  MMI                      Man Machine Interface

  P2                       CCSDS Panel 2

  PVL                      Parameter Value Language

  RP                       Registration Package

  RRP                      Revision Registration Package

  SFDU                     Standard Formatted Data Units

  TCP/IP                   Transfer Control Protocol / Internet Protocol

  TSDN                     Transfer Syntax Description Notation
  ------------------------ ------------------------------------------------------------