ISO 15889:2011

INTERNATIONAL ISO
STANDARD 15889
Third edition
2011-10-15
Space data and information transfer
systems — The data description
language EAST specification
Systèmes de transfert des informations et données spatiales —
Spécification du langage de description de données EAST

Reference number
©
ISO 2011
©  ISO 2011
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 2011 – 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.
This third edition cancels and replaces the second edition (ISO 15889:2003), which has been technically
revised.
ISO 15889 was prepared by the Consultative Committee for Space Data Systems (CCSDS) as
CCSDS 644.0-B-3, June 2010 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.

INTERNATIONAL STANDARD ISO 15889:2011(E)

Space data and information transfer systems — The data
description language EAST specification
1 Scope
This International Standard 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
analyse 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).
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-3, June 2010, The data description language EAST specification.
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 644.0-B-3.
Pages i to vi
This part is information which is relevant to the CCSDS publication only.
Page 1-5
Add the following information to the reference indicated:
[1] ISO 8859-1:1987 has been withdrawn and replaced by ISO/IEC 8859-1:1998.
[2] ISO/IEC 10646-1:1993 has been withdrawn and has been replaced by ISO/IEC 10646:2011.
Page E-1
Add the following information to the reference indicated:
[E2] Document CCSDS 620.0-B-2, May 1992, is equivalent to ISO 12175:1994.
3 Revision of publication CCSDS 644.0-B-3
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-3. To this end, NASA will act as a liaison body between CCSDS and ISO.
(Blank page)
2 © ISO 2011 – All rights reserved

Recommendation for Space Data System Standards
THE DATA DESCRIPTION
LANGUAGE EAST
SPECIFICATION
(CCSD0010)
RECOMMENDED STANDARD
CCSDS 644.0-B-3
BLUE BOOK
June 2010
(Blank page)
4 © ISO 2011 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR EAST SPECIFICATION
AUTHORITY
Issue: Recommended Standard, Issue 3
Date: June 2010
Location: Washington, DC, 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, and the record of Agency
participation in the authorization of this document can be obtained from the CCSDS
Secretariat at the address below.

This document is published and maintained by:

CCSDS Secretariat
Space Communications and Navigation Office, 7L70
Space Operations Mission Directorate
NASA Headquarters
Washington, DC 20546-0001, USA
CCSDS 644.0-B-3
Page i June 2010
CCSDS RECOMMENDED STANDARD FOR EAST SPECIFICATION
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of its members. 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 Recommended Standards and are not
considered binding on any Agency.
This Recommended Standard is issued by, and represents the consensus of, the CCSDS
members. Endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever a member establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommended Standard. Establishing such a standard
does not preclude other provisions which a member may develop.
o Whenever a member establishes a CCSDS-related standard, that member will
provide other CCSDS members 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 Recommended Standard nor any ensuing standard is a substitute for a
memorandum of agreement.
No later than five years from its date of issuance, this Recommended Standard 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 Recommended Standard is issued, existing
CCSDS-related member standards and implementations are not negated or deemed to be non-
CCSDS compatible. It is the responsibility of each member to determine when such
standards or implementations are to be modified. Each member is, however, strongly
encouraged to direct planning for its new standards and implementations towards the later
version of the Recommended Standard.
CCSDS 644.0-B-3 Page ii June 2010
6 © ISO 2011 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR EAST SPECIFICATION
FOREWORD
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Standard is therefore subject
to CCSDS document management and change control procedures, which are defined in the
Procedures Manual for the Consultative Committee for Space Data Systems. Current
versions of CCSDS documents are maintained at the CCSDS Web site:
http://www.ccsds.org/
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-3 Page iii June 2010
CCSDS RECOMMENDED STANDARD FOR EAST SPECIFICATION
At time of publication, the active Member and Observer Agencies of the CCSDS were:

Member Agencies
– Agenzia Spaziale Italiana (ASI)/Italy.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– China National Space Administration (CNSA)/People’s Republic of China.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– Japan Aerospace Exploration Agency (JAXA)/Japan.
– National Aeronautics and Space Administration (NASA)/USA.
– Russian Federal Space Agency (RFSA)/Russian Federation.
– UK Space Agency/United Kingdom.

Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Belgian Federal Science Policy Office (BFSPO)/Belgium.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– Centro Tecnico Aeroespacial (CTA)/Brazil.
– Chinese Academy of Sciences (CAS)/China.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– CSIR Satellite Applications Centre (CSIR)/Republic of South Africa.
– Danish National Space Center (DNSC)/Denmark.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Institute of Information and Communications Technology (NICT)/Japan.
– National Oceanic and Atmospheric Administration (NOAA)/USA.
– National Space Organization (NSPO)/Chinese Taipei.
– Naval Center for Space Technology (NCST)/USA.
– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.
– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
– Swedish Space Corporation (SSC)/Sweden.
CCSDS 644.0-B-3 Page iv June 2010
8 © ISO 2011 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR EAST SPECIFICATION
– United States Geological Survey (USGS)/USA.
CCSDS 644.0-B-3 Page v June 2010
CCSDS RECOMMENDED STANDARD FOR EAST SPECIFICATION
DOCUMENT CONTROL
Document Title and Issue Date Status
CCSDS Recommendation for Space Data May 1997 Original issue,
644.0-B-1 System Standards: The Data superseded.
Description Language EAST
Specification (CCSD0010), Issue 1
CCSDS Recommendation for Space Data November Issue 2, superseded:
644.0-B-2 System Standards: The Data 2000 – extends EAST ability
Description Language EAST to handle repeated data
Specification (CCSD0010), Issue 2 items where repetition
is terminated by a
marker.
CCSDS The Data Description Language June 2010 Current issue:
644.0-B-3 EAST Specification (CCSD0010), – adds requirement to
Recommended Standard, specify EAST version.
Issue 3
NOTE – Substantive changes from the previous issue are indicated by change bars in the
inside margin.
CCSDS 644.0-B-3 Page vi June 2010
10 © ISO 2011 – All rights reserved

CCSDS RECOMMENDED STANDARD 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-28
3.2.3 OBJECT DECLARATIONS . 3-31
3.2.4 REPRESENTATION CLAUSES . 3-35

3.3 PHYSICAL DESCRIPTION . 3-47

3.3.1 STORING ARRAYS . 3-48
3.3.2 STORING OCTETS/BITS . 3-48
CCSDS 644.0-B-3 Page vii June 2010
CCSDS RECOMMENDED STANDARD FOR EAST SPECIFICATION
CONTENTS (continued)
Section Page
3.3.3 REPRESENTATION OF SCALAR TYPES . 3-50
3.3.4 RELATIONSHIP BETWEEN THE REPRESENTATION OF SCALAR
TYPES AND LOGICAL TYPES . 3-62
3.3.5 TEMPLATE OF A PHYSICAL DESCRIPTION PART . 3-64

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-2
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-8
3-14 Enumeration Type Specification Diagram . 3-9
3-15 Enumeration Literal Definition Diagram . 3-9
3-16 Integer Type Specification Diagram . 3-10
3-17 Real Type Specification Diagram . 3-11
3-18 Array Type Specification Diagram . 3-12
3-19 Index Specification Diagram . 3-13
3-20 Record Type Specification Diagram . 3-15
3-21 Component Declaration Diagram . 3-15
3-22 Default Value Definition Diagram . 3-16
3-23 Index Constraint Diagram . 3-17
CCSDS 644.0-B-3 Page viii June 2010
12 © ISO 2011 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR EAST SPECIFICATION
CONTENTS (continued)
Figure Page
3-24 Discriminant Specification Diagram. 3-18
3-25 Variant Part Specification Diagram . 3-19
3-26 Discriminants in a Packet Format . 3-22
3-27 Actual Discriminant Value Declaration Diagram . 3-26
3-28 Type Summary . 3-27
3-29 Subtype Declaration Diagram . 3-28
3-30 Enumeration Constraint Diagram . 3-28
3-31 Integer Constraint Diagram . 3-29
3-32 Real Constraint Diagram . 3-30
3-33 Variable Declaration Diagram . 3-31
3-34 Constant Declaration Diagram . 3-32
3-35 Length Clause Specification Diagram . 3-36
3-36 Enumeration Clause Specification Diagram . 3-38
3-37 Component Representation Clause Specification Diagram . 3-39
3-38 Record Representation Clause Specification Diagram . 3-39
3-39 First Tree Structure . 3-41
3-40 Second Tree Structure . 3-42
3-41 Third Tree Structure . 3-43
3-42 Fourth Tree Structure . 3-44
3-43 Distance Specification Diagram . 3-46
3-44 Record Value Specification Diagram . 3-54
3-45 Component Value Definition Diagram . 3-54
3-46 Array Value Specification Diagram . 3-55
3-47 ASCII Encoded Decimal Integer Format . 3-60
3-48 ASCII Encoded Decimal Real Format . 3-61

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-10
3-4 Integer Type Declarations . 3-10
3-5 Real Type Declarations . 3-11
3-6 Constrained Array Type Definitions . 3-13
3-7 Unconstrained Array Type Definitions . 3-14
3-8 Record Type Definitions . 3-18
3-9 Record Type Definition with Discriminant . 3-20
3-10 Record Type Definition with Discriminant . 3-20
3-11 Logical Description of the Packet Format . 3-24
CCSDS 644.0-B-3 Page ix June 2010
CCSDS RECOMMENDED STANDARD FOR EAST SPECIFICATION
CONTENTS (continued)
Example Page
3-12 Calculated Size Array . 3-25
3-13 Calculated Component Presence Condition . 3-26
3-14 Character Declarations . 3-29
3-15 Subtype Declarations . 3-30
3-16 Variable Declaration . 3-31
3-17 Constant Declaration . 3-32
3-18 Number Declarations . 3-33
3-19 Marker Declaration . 3-34
3-20 EOF Marker Declaration . 3-34
3-21 Marker Declaration in Record Definition . 3-35
3-22 Length Clause Declarations . 3-36
3-23 Explicit Description of Unused Space . 3-37
3-24 Enumeration Clause Declarations . 3-38
3-25 Type Definitions . 3-40
3-26 Complete Record Representation Clause Declaration . 3-41
3-27 Incomplete Record Representation Clause Declaration . 3-42
3-28 Complete Record Representation Clause Declaration . 3-43
3-29 Complete Record Representation Clause Declaration . 3-45
3-30 Record Representation Clause Using WORD_32_BITS . 3-46
3-31 Actual Array Storage Method . 3-48
3-32 Octet Storage Possibilities . 3-49
3-33 Actual Bit Order . 3-50
3-34 Bit Ordering . 3-52
3-35 Bit Ordering for the Above 16-Bit Signed Integer . 3-55
3-36 Actual Binary Representation of the Above 16-Bit Signed Integer . 3-55
3-37 Bit Ordering for the Above 16-Bit Unsigned Integer . 3-56
3-38 Actual Binary Representation of the Above 16-Bit Unsigned Integer . 3-56
3-39 Bit Ordering for the Above 32-Bit Real . 3-57
3-40 Actual Binary Representation of a 32-Bit Real . 3-57
3-41 ASCII Enumeration Type Logical Declaration . 3-59
3-42 ASCII Enumeration Type Physical Description . 3-60
3-43 ASCII Integer Type Logical Declaration . 3-62
3-44 ASCII Integer Type Physical Description . 3-62
3-45 ASCII Real Type Logical Declaration . 3-62
3-46 ASCII Real Type Physical Description . 3-62

CCSDS 644.0-B-3 Page x June 2010
14 © ISO 2011 – All rights reserved

CCSDS RECOMMENDED STANDARD 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 may be 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 3 Page 1-1 June 2010
-
CCSDS RECOMMENDED STANDARD 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-3 Page 1-2 June 2010
16 © ISO 2011 – All rights reserved

CCSDS RECOMMENDED STANDARD 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-3 Page 1-3 June 2010
CCSDS RECOMMENDED STANDARD 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-3 Page 1-4 June 2010
18 © ISO 2011 – All rights reserved

CCSDS RECOMMENDED STANDARD FOR EAST SPECIFICATION
1.6 REFERENCES
The following documents contain provisions which, through reference in this text, constitute
provisions of this Recommended Standard. At the time of publication, the editions indicated
were valid. All documents are subject to revision, and users of this Recommended Standard
are encouraged to investigate the possibility of applying the most recent editions of the
documents indicated below. The CCSDS Secretariat maintains a register of currently valid
CCSDS Recommended Standards.
[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-3 Page 1-5 June 2010
(Blank page)
20 © ISO 2011 – All rights reserved

CCSDS RECOMMENDED STANDARD 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-3 Page 2-1 June 2010
CCSDS RECOMMENDED STANDARD 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-3 Page 2-2 June 2010
22 © ISO 2011 – All rights reserved

CCSDS RECOMMENDED STANDARD 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; f
...