ISO 15889:2003

INTERNATIONAL ISO
STANDARD 15889
Second edition
2003-02-15
Space data and information transfer
systems — Data description language —
EAST specification
Systèmes de transfert des informations et données spatiales —
Langage de description de données — Spécification EAST

Reference number
©
ISO 2003
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2003
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2003 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
International Standard ISO 15889 was prepared by the Consultative Committee for Space Data Systems
(CCSDS) (as CCSDS 644.0-B-2, November 2000) and was adopted (without modifications except those
stated in Clause 2 of this International Standard) by Technical Committee ISO/TC 20, Aircraft and space
vehicles, Subcommittee SC 13, Space data and information transfer systems.
This second edition cancels and replaces the first edition (ISO 15889:2000), which has been technically
revised.
INTERNATIONAL STANDARD ISO 15889:2003(E)

Space data and information transfer systems — Data
description language — EAST specification
1 Scope
This International Standard specifies the requirements for the Enhanced Ada SubseT (EAST) language
(CCSDS 0010) used to create descriptions of data, called data description records (DDRs). The use of this
language ensures complete and exact understanding of space data as well as its automated transfer and
interpretation on any host machine having the appropriate software tools.
The scope and field of application are furthermore detailed in subclauses 1.1 and 1.2 of the enclosed CCSDS
publication.
2 Requirements
Requirements are the technical recommendations made in the following publication (reproduced on the
following pages), which is adopted as an International Standard:
CCSDS 644.0-B-2, November 2000, Recommendation for space data system standards — The data
description language — EAST specification (CCSD0010).
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 644.0-B-2.
Pages i to v
This part is information which is relevant to the CCSDS publication only.
Page 1-5
Update the following reference in 1.6 as follows:
[1] ISO/IEC 8859-1:1998, Information technology — 8-bit single-byte coded graphic character sets —
Part 1: Latin alphabet No. 1
Reference to ISO/IEC 10646-1:1993 is informative (see reference [2]). Move reference [2] to the informative
annex E on page E-1 where it should be updated to read:
[E6] 10646-1:2000, Information technology — Universal Multiple-Octet Coded Character Set (UCS) —
Part 1: Architecture and Basic Multilingual Plane
Page E-1
Add the following information to the references indicated in annex E:
[E2] Document CCSDS 620.0-B-2, May 1992, is equivalent to ISO 12175:1994.
3 Revision of publication CCSDS 644.0-B-2
It has been agreed with the Consultative Committee for Space Data Systems that Subcommittee
ISO/TC 20/SC 13 will be consulted in the event of any revision or amendment of publication
CCSDS 644.0-B-2. To this end, NASA will act as a liaison body between CCSDS and ISO.

2 © ISO 2003 – All rights reserved

RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
THE DATA DESCRIPTION
LANGUAGE EAST
SPECIFICATION
(CCSD0010)
CCSDS 644.0-B-2
BLUE BOOK
November 2000
(Blank page)
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
AUTHORITY
Issue: Blue Book, Issue 2
Date: November 2000
Location: Boulder, Colorado, USA

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 authorization of CCSDS Recommendations is detailed in the Procedures Manual
for the Consultative Committee for Space Data Systems (reference [E1]), and the record of
Agency participation in the authorization of this document can be obtained from the CCSDS
Secretariat at the address below.

This Recommendation is published and maintained by:

CCSDS Secretariat
Program Integration Division (Code MT)
National Aeronautics and Space Administration
Washington, DC 20546, USA
CCSDS 644.0-B-2 Page i November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of member space Agencies. The Committee meets
periodically to address data systems 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 Committee actions are termed
Recommendations and are not considered binding on any Agency.
This Recommendation is issued by, and represents the consensus of, the CCSDS Plenary
body. Agency endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever an Agency establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommendation. Establishing such a standard does not
preclude other provisions which an Agency may develop.
o 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.
o Specific service arrangements shall be made via memoranda 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 canceled.
In those instances when a new version of a Recommendation is issued, existing CCSDS-
related Agency standards and implementations are not negated or deemed to be non-CCSDS
compatible. It is the responsibility of each Agency to determine when such standards or
implementations are to be modified. Each Agency is, however, strongly encouraged to direct
planning for its new standards and implementations towards the later version of the
Recommendation.
CCSDS 644.0-B-2 Page ii November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
FOREWORD
This Recommendation is a technical Recommendation for the standardization of a language
to be used for providing syntactic and in some degree semantic information about data
interchange using Standard Formatted Data Units (SFDUs).
This Recommendation provides the syntax specification of the language EAST, which is a
subset of the Ada language.
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommendation is therefore subject to
CCSDS document management and change control procedures which are defined in
reference [E1]. Current versions of CCSDS documents are maintained at the CCSDS Web
site:
http://www.ccsds.org/ccsds/
Questions relating to the contents or status of this document should be addressed to the
CCSDS Secretariat at the address indicated on page i.
CCSDS 644.0-B-2 Page iii November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
At time of publication, the active Member and Observer Agencies of the CCSDS were:

Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– British National Space Centre (BNSC)/United Kingdom.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– Deutsches Zentrum 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)/USA.
– National Space Development Agency of Japan (NASDA)/Japan.
– Russian Space Agency (RSA)/Russian Federation.

Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– Centro Tecnico Aeroespacial (CTA)/Brazil.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Communications Research Centre (CRC)/Canada.
– 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.
– Federal Service of Scientific, Technical & Cultural Affairs (FSST&CA)/Belgium.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– 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.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Oceanic & Atmospheric Administration (NOAA)/USA.
– National Space Program Office (NSPO)/Taipei.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.

CCSDS 644.0-B-2 Page iv November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
DOCUMENT CONTROL
Document Title, Issue Date Status/Remarks
CCSDS 644.0-B-1 Recommendation for Space Data May 1997 Original Issue:
System Standards: The Data superseded.
Description Language EAST
Specification (CCSD0010),
Issue 1
CCSDS 644.0-B-2 Recommendation for Space Data November Current Issue:
System Standards: The Data 2000
extends EAST
Description Language EAST
ability to handle
Specification (CCSD0010),
repeated data
Issue 2
items where
repetition is
terminated by a
marker.
CCSDS 644.0-B-2 Page v November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
CONTENTS
Section Page
1 INTRODUCTION.1-1

1.1 PURPOSE AND SCOPE.1-1
1.2 APPLICABILITY.1-1
1.3 RATIONALE.1-1
1.4 DOCUMENT STRUCTURE.1-2
1.5 DEFINITIONS.1-2

1.5.1 TERMS.1-2
1.5.2 NOMENCLATURE.1-2
1.5.3 CONVENTIONS.1-3

1.6 REFERENCES.1-5

2 OVERVIEW .2-1

2.1 DESIGN AIMS.2-1
2.2 STRUCTURE OF AN EAST DESCRIPTION.2-1
2.3 LANGUAGE SUMMARY.2-2

3 DEFINITION OF THE EAST LANGUAGE .3-1

3.1 LEXICAL ELEMENTS.3-1

3.1.1 SEPARATORS AND DELIMITERS.3-1
3.1.2 COMMENTS.3-1
3.1.3 IDENTIFIERS.3-2
3.1.4 NUMERIC LITERALS.3-2

3.2 LOGICAL DESCRIPTION.3-7

3.2.1 TYPE DECLARATIONS.3-8
3.2.2 SUBTYPE DECLARATIONS.3-23
3.2.3 OBJECT DECLARATIONS.3-26
3.2.4 REPRESENTATION CLAUSES.3-30

3.3 PHYSICAL DESCRIPTION.3-41

3.3.1 STORING ARRAYS.3-42
3.3.2 STORING OCTETS/BITS.3-42
3.3.3 REPRESENTATION OF SCALAR TYPES.3-44
CCSDS 644.0-B-2 Page vi November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
3.3.4 RELATIONSHIP BETWEEN THE REPRESENTATION OF SCALAR
TYPES AND LOGICAL TYPES .3-55
3.3.5 TEMPLATE OF A PHYSICAL DESCRIPTION PART .3-57

4 RESERVED KEYWORDS .4-1

5 CONFORMANCE .5-1

ANNEX A ACRONYMS AND GLOSSARY.A-1
ANNEX B CHARACTER DEFINITION. B-1
ANNEX C EAST FORMAL SYNTAX SPECIFICATION .C-1
ANNEX D MAIN DIFFERENCES BETWEEN ADA AND EAST .D-1
ANNEX E INFORMATIVE REFERENCES. E-1
INDEX . I-1

Figure
1-1 Example of Syntax Diagram .1-3
3-1 Identifier Definition Diagram.3-2
3-2 Decimal Literal Definition Diagram .3-3
3-3 Integer Decimal Literal Definition Diagram .3-3
3-4 Real Decimal Literal Definition Diagram.3-3
3-5 Integer Definition Diagram .3-3
3-6 Exponent Definition Diagram.3-4
3-7 Based Literal Definition Diagram .3-4
3-8 Integer Based Literal Definition Diagram.3-5
3-9 Real Based Literal Definition Diagram.3-5
3-10 Based Integer Definition Diagram .3-5
3-11 Integer Literal Definition Diagram.3-6
3-12 Real Literal Definition Diagram .3-6
3-13 Logical Part Structure.3-7
3-14 Enumeration Type Specification Diagram.3-8
3-15 Enumeration Literal Definition Diagram .3-9
3-16 Integer Type Specification Diagram .3-9
3-17 Real Type Specification Diagram .3-10
3-18 Array Type Specification Diagram .3-12
3-19 Index Specification Diagram.3-12
3-20 Record Type Specification Diagram .3-14
3-21 Component Declaration Diagram.3-14
3-22 Index Constraint Diagram .3-15
CCSDS 644.0-B-2 Page vii November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
CONTENTS (continued)
Figure Page
3-23 Discriminant Specification Diagram.3-16
3-24 Variant Part Specification Diagram .3-16
3-25 Discriminants in a Packet Format .3-19
3-26 Type Summary .3-22
3-27 Subtype Declaration Diagram .3-23
3-28 Enumeration Constraint Diagram .3-23
3-29 Integer Constraint Diagram.3-24
3-30 Real Constraint Diagram.3-25
3-31 Variable Declaration Diagram .3-26
3-32 Constant Declaration Diagram.3-26
3-33 Length Clause Specification Diagram.3-30
3-34 Enumeration Clause Specification Diagram .3-32
3-35 Component Representation Clause Specification Diagram .3-33
3-36 Record Representation Clause Specification Diagram .3-33
3-37 First Tree Structure .3-35
3-38 Second Tree Structure .3-36
3-39 Third Tree Structure.3-37
3-40 Fourth Tree Structure .3-38
3-41 Distance Specification Diagram.3-40
3-42 Record Value Specification Diagram.3-48
3-43 Array Value Specification Diagram .3-48
3-44 ASCII Encoded Decimal Integer Format .3-53
3-45 ASCII Encoded Decimal Real Format .3-54

Example
1-1 Example of BNF .1-4
3-1 Decimal Literals .3-4
3-2 Based Literals.3-6
3-3 Enumeration Type Declarations.3-9
3-4 Integer Type Declarations .3-10
3-5 Real Type Declarations .3-10
3-6 Constrained Array Type Definitions .3-13
3-7 Unconstrained Array Type Definitions .3-13
3-8 Record Type Definitions .3-15
3-9 Record Type Definition with Discriminant.3-17
3-10 Record Type Definition with Discriminant.3-17
3-11 Logical Description of the Packet Format.3-21
3-12 Character Declarations .3-24
3-13 Subtype Declarations.3-25
CCSDS 644.0-B-2 Page viii November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
CONTENTS (continued)
Example Page
3-14 Variable Declaration .3-26
3-15 Constant Declaration.3-27
3-16 Number Declarations .3-27
3-17 Marker Declaration .3-28
3-18 EOF Marker Declaration.3-29
3-19 Length Clause Declarations .3-30
3-20 Explicit Description of Unused Space .3-31
3-21 Enumeration Clause Declarations .3-32
3-22 Type Definitions.3-34
3-23 Complete Record Representation Clause Declaration .3-35
3-24 Incomplete Record Representation Clause Declaration.3-36
3-25 Complete Record Representation Clause Declaration .3-37
3-26 Complete Record Representation Clause Declaration .3-39
3-27 Record Representation Clause Using WORD_32_BITS .3-40
3-28 Actual Array Storage Method .3-42
3-29 Octet Storage Possibilities .3-43
3-30 Actual Bit Order.3-44
3-31 Bit Ordering .3-46
3-32 Bit Ordering for the Above 16-Bit Signed Integer.3-49
3-33 Actual Binary Representation of the Above 16-Bit Signed Integer .3-49
3-34 Bit Ordering for the Above 16-Bit Unsigned Integer.3-49
3-35 Actual Binary Representation of the Above 16-Bit Unsigned Integer.3-50
3-36 Bit Ordering for the Above 32-Bit Real.3-50
3-37 Actual Binary Representation of a 32-Bit Real.3-51
3-38 ASCII Enumeration Type Logical Declaration .3-53
3-39 ASCII Enumeration Type Physical Description.3-53
3-40 ASCII Integer Type Logical Declaration.3-55
3-41 ASCII Integer Type Physical Description .3-55
3-42 ASCII Real Type Logical Declaration .3-55
3-43 ASCII Real Type Physical Description.3-55

CCSDS 644.0-B-2 Page ix November 2000
(Blank page)
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
1 INTRODUCTION
1.1 PURPOSE AND SCOPE
The purpose of this document is to establish a common Recommendation for the
specification of a standard language for describing and expressing data in order to
interchange them in a more uniform and automated fashion within and among Agencies
participating in the Consultative Committee for Space Data Systems (CCSDS).
This Recommendation defines the Enhanced Ada SubseT (EAST) language used to create
descriptions of data, called Data Description Records (DDRs). Such DDRs ensure a
complete and exact understanding of the data and allow it to be interpreted in an automated
fashion. This means that a software tool is able to analyze a DDR and interpret the format of
the associated data. This allows the software to extract values from the data on any host
machine (i.e., on a different machine from the one that produced the data).
A first look at reference [E4], which is a tutorial for the EAST language, may aid the user in
understanding this document. Reference [E4] describes the requirements, explains how to
use the EAST language to describe non-ambiguous data, and suggests practices and tools to
the users.
This Recommendation is registered under the CCSDS Authority and Description Identifier
(ADID): CCSD0010.
1.2 APPLICABILITY
The specifications in this document are applicable to all space-related science and
engineering data exchanges where data descriptions are desired, and these descriptions need
to provide an unambiguous description of the record structure of the data.
1.3 RATIONALE
The Consultative Committee for Space Data Systems has defined the Standard Formatted
Data Unit (SFDU) concept for the implementation of standard data structures to be used for
the interchange of data within and among space agencies.
SFDU data products may be viewed as containing application data (that is the data which is
of primary interest, e.g., actual measurements) and data description information (that is the
information telling how the application data are formatted).
The data description information shall be provided in a form that is understandable by the
agencies involved in the data interchange. That is the reason why the CCSDS must provide
some recommendations for the definition of standard description languages. EAST is one of
the recommended languages.
CCSDS 644.0-B-2 Page 1-1 November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
1.4 DOCUMENT STRUCTURE
The Recommendation is structured as follows:
– Section 2 provides an overview of the EAST language.
– Section 3 specifies the EAST language and defines its usage in Data Descriptions.
– Section 4 lists the EAST reserved keywords.
– Annex A contains acronyms and the glossary of terms used in this document.
– Annex B defines the character set to be used in an EAST data description, as well as a
predefined type called CHARACTER.
– Annex C provides the EAST formal specification using a simple variant of the
Backus-Naur-Form (BNF).
– Annex D lists the main differences between the Ada programming language and
EAST.
– Annex E lists the informative references.
1.5 DEFINITIONS
1.5.1 TERMS
The terms used throughout this document are listed in annex A. They are also explained in
the text when they are first used.
1.5.2 NOMENCLATURE
The following conventions apply throughout this Recommendation:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
CCSDS 644.0-B-2 Page 1-2 November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
1.5.3 CONVENTIONS
This document uses syntax diagrams to illustrate the syntax of the EAST constructs.
Components of a construct are called elements. The following conventions are used:
a) Elements that are presented in bold characters in a circle are reserved keywords,
delimiters, or literals.
b) The item named on the left of the ::= symbol is the item being defined.
c) The diagram on the right of the ::= symbol is the corresponding definition.
d) A vertical branch represents a choice.
e) A repetition is indicated by a loop-back covering the object to be repeated.
f) If the name of any syntactic category starts with an italicized part, it is equivalent to
the category name without the italicized part. The italicized part is intended to
convey some semantic information. For example, an “Integer Identifier” is an
Identifier; i.e., the definition of the category Identifier applies, but the reader has
additional semantic information (it is an integer).
The following example (figure 1-1) presents a diagram specifying the declaration of Item A.
Item A is defined as first a keyword (“type”), then followed by an italicized Item B (already
defined, and known as Item B), then followed by a keyword (“is”) and a delimiter (“(”).
Then this structure is followed by a choice between Items B and C. The choice may be
repeated any number of times, each time a delimiter (“,”) is inserted. The structure is ended
by two delimiters (“)” and “;”).
,
Item C
Item A Italicized
);
::= type is (
Item B
Declaration
Item B
Figure 1-1: Example of Syntax Diagram
CCSDS 644.0-B-2 Page 1-3 November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
The syntax of the language is described using a simple variant of Backus-Naur-Form with the
following conventions:
a) Boldface words are used to denote reserved keywords.
b) Square brackets enclose optional items.
c) Braces enclose a repeated item. This item may appear zero or more times.
d) A vertical bar separates alternative items unless it occurs immediately after an
opening brace ({): in this case it represents the character ‘vertical bar’.
e) If the name of any syntactic category starts with an italicized part, it is equivalent to
the category name without the italicized part. The italicized part is intended to
convey some semantic information. This facility used for the BNF intends to
assimilate every element like to the previously defined
element .
The following example presents the definition of Item A using a simple variant of BNF. Item
A is defined as first a keyword (“type”), then followed by an italicized Item B (already
defined, and known as Item B), then followed by a keyword (“is”) and a delimiter (“(”). The
structure is followed by a choice. The choice may be repeated any number of times, each
time a delimiter (“,”) is inserted. The structure is ended by two delimiters (“)” and “;”). The
choice is between Items B and C.
::= type is ( { , } ) ;
::= |
Example 1-1: Example of BNF
In the case of any confusion, the syntax diagram and the associated text are always the
reference for the EAST syntax, and not the BNF.
This document uses examples to illustrate the EAST. The following conventions are used in
the examples:
a) bold characters denote reserved keyword or delimiters;
b) user type names or user variable names are provided using uppercase letters, although
EAST is not a case-sensitive language.
CCSDS 644.0-B-2 Page 1-4 November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
1.6 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommendation. At the time of publication, the editions indicated were
valid. All documents are subject to revision, and users of this Recommendation are
encouraged to investigate the possibility of applying the most recent editions of the docu-
ments indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS Recommendations.
[1] Information Processing—8-Bit Single-Byte Coded Graphic Character Sets—Part 1:
Latin Alphabet No. 1. International Standard, ISO 8859-1:1987. Geneva: ISO, 1987.

[2] Information Processing—Universal Multiple-Octet Coded Character Set (UCS).
International Standard, ISO/IEC 10646-1:1993.

CCSDS 644.0-B-2 Page 1-5 November 2000
(Blank page)
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
2 OVERVIEW
2.1 DESIGN AIMS
EAST was designed with three overriding concerns: data description capabilities, human
readability, and computer interpretability.
The need for data description languages that supply complete and non-ambiguous
information about the format and the nature of the described data is well established.
Any user must be able to understand descriptions of data, with a minimal effort. Error-prone
notations have been avoided, and the syntax of the EAST language avoids the use of cryptic
forms in favor of more English-like constructs.
EAST is a formal language and not a natural language: it is a machine compilable (or
interpretable) language. The formal nature of EAST allows the control of data descriptions
and the interpretation of data in an automated fashion.
2.2 STRUCTURE OF AN EAST DESCRIPTION
An EAST Data Description Record (DDR) includes a syntactic, and in some way semantic,
description of the data called a logical description, which is followed by a physical
description. The physical description makes possible the interpretation of the actual bit
patterns encountered on the medium. Each description part of a DDR consists of an EAST
unit, called a package: one for the logical part and another one for the associated physical
part.
The logical part of an EAST description includes:
– a logical description of all components of the exchanged data (see 3.2.1 and 3.2.2);
– their size in bits (see 3.2.4.1);
– their location within the set of the described data (see 3.2.4.3).
The physical part of an EAST description includes:
– the representation of some basic data types (enumeration, integer, and real) defined in
the logical description and dependent on the machine that has generated the data (see
3.3.3);
– the array organization (first-index-first or last-index-first) used by the generating
machine (see 3.3.1);
– the octet and bit organization on the medium (high-order-first or low-order-first—see
3.3.2).
CCSDS 644.0-B-2 Page 2-1 November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
A DDR created using the EAST Language has the following structure:

Data Description Record
package name_of_the_logical_description is

Logical Description (see 3.2)
end name_of_the_logical_description ;

package name_of_the_physical_description is

Physical Description (see 3.3)

end name_of_the_physical_description ;

The logical description always precedes the physical description. The logical and the physical
packages are mandatory even if the content of the physical one can be empty (see 3.3).
The two part design of the DDR is intended to allow interchangeable physical description
parts for one logical description part, provided that the length of fields in bits in the logical
description are supported by field lengths of the same number of bits in the physical
description part. For example, a 32 bit real number on a IEEE architecture has a physical
description different from the one on a 1750 architecture, although lengths in bits of each
field are equal. Note that the representations written to an exchange medium do not have to
be the ones typically supported by the writing machine.
The data block associated with the DDR contains one or more complete sets of data.
The DDR describes a single set only and is repetitively applied to fully interpret the
data block.
2.3 LANGUAGE SUMMARY
An EAST description is composed of two units, called packages. The first one is a logical
description and the second one is a physical description of the data. The logical part of an
EAST description provides syntactic information and in some way semantic information, i.e.,
the information needed by a user to understand the data he has to deal with. The physical
part of an EAST description provides a bit-level description that ensures the non-ambiguous
interpretation of the data.
The syntax used in each of the two packages is based on the type and object concept. A type
is a model, defined once, that is used to create many occurrences (objects) of the models.
CCSDS 644.0-B-2 Page 2-2 November 2000
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
Every data item described in an EAST description is an object. An object in the language has
a type, which characterizes a set of values. The basic classes of types are scalar types
(comprising enumeration and numeric types, describing single elements), and composite
types (comprising array and record types, describing sequences of objects).
A type has a name: if well chosen, this name is a way to provide the meaning of the model
(e.g., the type DATE may describe a CCSDS date). An object has a name also: this name is
a way to provide (if any) the particularity of the occurrence (e.g., the object
DATE_AT_THE_BEGINNING_OF_THE_ORBIT of the type DATE may represent a
particular date). The name used to identify a type or an object can be any identifier except for
an EAST reserved keyword (reserved keywords are provided in section 4).
An enumeration type defines an ordered set of distinct enumeration literals; for example, a
Boolean type defines two enumeration literals (TRUE and FALSE). The enumeration type
CHARACTER is predefined and given in section 3.2.1.1.
Numeric types provide a means of describing w
...