ISO 15889:2000

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

General Information

• Status: Withdrawn
• Publication Date: 18-Oct-2000
• Withdrawal Date: 18-Oct-2000
• ICS: 49.140 - Space systems and operations
• Technical Committee: ISO/TC 20/SC 13 - Space data and information transfer systems
• Drafting Committee: ISO/TC 20/SC 13 - Space data and information transfer systems
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 10-Feb-2003
• Completion Date: 30-Oct-2025

Relations

• Consolidated By: ISO 20846:2011 - Petroleum products - Determination of sulfur content of automotive fuels - Ultraviolet fluorescence method
• Effective Date: 06-Jun-2022
• Revised: ISO 15889:2003 - Space data and information transfer systems - Data description language - EAST specification
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 15889
First edition
2000-10-01
Space data and information transfer
systems — Data description language —
EAST specification
Systèmes de transfert des informations et données spatiales — Langage
de description des données — Spécification EAST
Reference number
©
ISO 2000
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.
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 [e-mail]
Web www.iso.ch
Printed in Switzerland
ii © ISO 2000 – 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 3.
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 International Standard 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-1, May 1997) 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:2000(E)
Space data and information transfer systems — Data description
language — EAST specification
1 Scope
This International Standard specifies the requirements for the data description language EAST specification
(CCSDS 0010) for space data and information transfer systems.
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-1, May 1997, 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-1.
Pages i to v
This part is information which is relevant to the CCSDS publication only.
Page 1-5
Reference to ISO/IEC 10646-1:1993 is informative (see reference [2]). It should be moved to the informative
Annex E on page E-1 where it should read:
[E6] 10646-1:1993, Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1:
Architecture and Basic Multilingual Plane.
3 Revision of publication CCSDS 644.0-B-1
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-1. To this end, NASA
will act as a liaison body between CCSDS and ISO.
(blank page)
2 © ISO 2000 – All rights reserved

RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
THE DATA DESCRIPTION
LANGUAGE EAST
SPECIFICATION
(CCSD0010)
CCSDS 644.0-B-1
BLUE BOOK
May 1997
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
AUTHORITY
Issue: Blue Book, Issue 1
Date: May 1997
Location: São José dos Campos
São Paulo, Brazil
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 MG)
National Aeronautics and Space Administration
Washington, DC 20546, USA
CCSDS 644.0 -B-1 Page i May 1997
4 © ISO 2000 – All rights reserved

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-1 Page ii May 1997
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-1 Page iii May 1997
6 © ISO 2000 – All rights reserved

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.
– 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)/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 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.
– 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.
– 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-1 Page iv May 1997
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
DOCUMENT CONTROL
Document Title Date Status/Remarks
CCSDS 644.0-B-1 Recommendation for Space Data May 1997 Original Issue
System Standards: The Data
Description Language EAST
Specification (CCSD0010)
CCSDS 644.0 -B-1 Page v May 1997
8 © ISO 2000 – All rights reserved

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-29
3.3 PHYSICAL DESCRIPTION. 3-40
3.3.1 WAY OF STORING ARRAYS. 3-41
3.3.2 WAY OF STORING OCTETS/BITS . 3-41
3.3.3 REPRESENTATION OF SCALAR TYPES . 3-43
3.3.4 RELATIONSHIP BETWEEN THE REPRESENTATION OF SCALAR
TYPES AND LOGICAL TYPES . 3-54
CCSDS 644.0 -B-1 Page vi May 1997
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
CONTENTS (continued)
Section Page
3.3.5 TEMPLATE OF A PHYSICAL DESCRIPTION PART . 3-56
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-3
3-7 Based Literal Definition Diagram . 3-4
3-8 Integer Based Literal Definition Diagram . 3-4
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
3-23 Discriminant Specification Diagram . 3-16
3-24 Variant Part Specification Diagram. 3-16
3-25 Discriminants in a Packet Format . 3-19
CCSDS 644.0 -B-1 Page vii May 1997
10 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR EAST SPECIFICATION
CONTENTS (continued)
Figure Page
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-29
3-34 Enumeration Clause Specification Diagram. 3-31
3-35 Component Representation Clause Specification Diagram. 3-32
3-36 Record Representation Clause Specification Diagram. 3-32
3-37 First Tree Structure. 3-34
3-38 Second Tree Structure. 3-35
3-39 Third Tree Structure . 3-36
3-40 Fourth Tree Structure. 3-37
3-41 Distance Specification Diagram. 3-39
3-42 Record Value Specification Diagram . 3-47
3-43 Array Value Specification Diagram . 3-47
3-44 ASCII Encoded Decimal Integer Format . 3-52
3-45 ASCII Encoded Decimal Real Format . 3-53
Example
1-1 Example of BNF. 1-4
3-1 Decimal Literals . 3-4
3-2 Based Literals. 3-5
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
3-14 Variable Declaration. 3-26
3-15 Constant Declaration. 3-27
3-16 Number Declarations . 3-27
3-17 Marker Declaration. 3-28
CCSDS 644.0 -B-1 Page viii May 1997
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
CONTENTS (continued)
Example Page
3-18 EOF Marker Declaration. 3-28
3-19 Length Clause Declarations . 3-29
3-20 Explicit Description of Unused Space. 3-30
3-21 Enumeration Clause Declarations . 3-31
3-22 Type Definitions. 3-33
3-23 Complete Record Representation Clause Declaration. 3-34
3-24 Incomplete Record Representation Clause Declaration . 3-35
3-25 Complete Record Representation Clause Declaration. 3-36
3-26 Complete Record Representation Clause Declaration. 3-38
3-27 Record Representation Clause Using WORD_32_BITS. 3-39
3-28 Actual Array Storage Method . 3-41
3-29 Octet Storage Possibilities . 3-42
3-30 Actual Bit Order . 3-43
3-31 Bit Ordering . 3-45
3-32 Bit Ordering for the Above 16-Bit Signed Integer. 3-48
3-33 Actual Binary Representation of the Above 16-Bit Signed Integer. 3-48
3-34 Bit Ordering for the Above 16-Bit Unsigned Integer. 3-48
3-35 Actual Binary Representation of the Above 16-Bit Unsigned Integer. 3-49
3-36 Bit Ordering for the Above 32-Bit Real . 3-49
3-37 Actual Binary Representation of a 32-Bit Real. 3-50
3-38 ASCII Enumeration Type Logical Declaration . 3-52
3-39 ASCII Enumeration Type Physical Description . 3-52
3-40 ASCII Integer Type Logical Declaration . 3-54
3-41 ASCII Integer Type Physical Description . 3-54
3-42 ASCII Real Type Logical Declaration . 3-54
3-43 ASCII Real Type Physical Description . 3-54
CCSDS 644.0 -B-1 Page ix May 1997
12 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR EAST SPECIFICATION
1 INTRODUCTION
1.1 PURPOSE AND SCOPE
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
This Recommendation defines the 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
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
[E4]
the EAST language to describe non-ambiguous data, and suggests practices and tools to the
This Recommendation is registered under the CCSDS Authority and Description Identifier
(ADID): CCSD0010.
1.2 APPLICABILITY
data exchanges where data descriptions are desired, and these descriptions need to provide an
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
primary interest, e.g., actual measurements) and data description information (that is the
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
CCSDS 644.0 -B-1 May 1997
1-1 Page
the recommended languages.
information telling how the application data are formatted).
SFDU data products may be viewed as containing application data (that is the data which is of
the interchange of data within and among space agencies.
unambiguous description of the record structure of the data.
The specifications in this document are applicable to all space-related science and engineering
users.
describes the requirements, explains how to use understanding this document. Reference
software to extract values from the data on any host machine (i.e., on a different machine from
Consultative Committee for Space Data Systems (CCSDS).
The purpose of this document is to establish a common Recommendation for the specification

CCSDS RECOMMENDATION FOR EAST SPECIFICATION
1.4 DOCUMENT STRUCTURE
-2
-3
-4
-0
-0 defines the character set to be used in an EAST data description, as well as a
-0 provides the EAST formal specification using a simple variant of the Backus-
).
-0
-0
1.5 DEFINITIONS
1.5.1 TERMS
The terms used throughout this document are listed in annex A. They are also explained in
1.5.2 NOMENCLATURE
a)
c)
d)
CCSDS 644.0 -B-1 May 1997
14 © ISO 2000 – All rights reserved
1-2 Page
the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
the word ‘may’ implies an optional specification;
the word ‘should’ implies an optional, but desirable, specification; b)
the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
The following conventions apply throughout this Recommendation:
the text when they are first used.
lists the informative references. Annex
lists the main differences between the Ada programming language and EAST. Annex
Naur-Form (BNF
Annex
predefined type called CHARACTER.
Annex
contains acronyms and the glossary of terms used in this document. Annex
lists the EAST reserved keywords. Section
specifies the EAST language and defines its usage in Data Descriptions. Section
provides an overview of the EAST language. Section
The Recommendation is structured as follows:

CCSDS RECOMMENDATION FOR EAST SPECIFICATION
1.5.3 CONVENTIONS
This document uses syntax diagrams to illustrate the syntax of the EAST constructs.
a) Elements that are presented in bold characters in a circle are reserved keywords,
::=
c) ::=
d)
e) to be repeated.
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 is an Identifier; i.e.,
the definition of the category Identifier applies, but the reader has additional semantic
The following example presents a diagram specifying the declaration of Item A. Item A is
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
,
Italicized
) ;
type is (
Figure 1-1: Example of Syntax Diagram
CCSDS 644.0 -B-1 May 1997
1-3 Page
Item B
Declaration
Item B
::=
Item A
Item C
delimiters (“)” and “;”).
defined as first a keyword (“type”), then followed by an italicized Item B (already defined, and
information (it is an integer).
Identifier”
f)
A repetition is indicated by a loop-back covering the object
A vertical branch represents a choice.
symbol is the corresponding definition. The diagram on the right of the
symbol is the item being defined. The item named on the left of the b)
delimiters, or literals.
Components of a construct are called elements. The following conventions are used:

CCSDS RECOMMENDATION FOR EAST SPECIFICATION
of Backus-Naur-Form with the
a) Boldface words are used to denote reserved keywords.
c)
d) A vertical bar separates alternative items unless it occurs immediately after an opening
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
italicized_part
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
a delimiter (“,”) is inserted. The structure is ended by two delimiters (“)” and “;”). The
type 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
a)
user type names or user variable names are provided using uppercase letters, although
CCSDS 644.0 -B-1 May 1997
16 © ISO 2000 – All rights reserved
1-4 Page
EAST is not a case-sensitive language.
b)
bold characters denote reserved keyword or delimiters;
the examples:
::= |
{ , } _Item B> ::=
choice is between Items B and C.
structure is followed by a choice. The choice may be repeated any number of times, each time
The following example presents the definition of Item A using a simple variant
_name> to the previously defined element . element like <
brace ({): in this case it represents the character ‘vertical bar’.
Braces enclose a repeated item. This item may appear zero or more times.
Square brackets enclose optional items. b)
following conventions:
The syntax of the language is described using a simple variant

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
. All documents are subject to revision, and users of this Recommendation are
indicated below . The CCSDS Secretariat maintains a register of currently valid CCSDS
[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-1 May 1997
1-5 Page
Recommendations.
ments encouraged to investigate the possibility of applying the most recent editions of the docu
valid
CCSDS RECOMMENDATION FOR EAST SPECIFICATION
2 OVERVIEW
2.1 DESIGN AIMS
EAST was designed with three overriding concerns: data description capabilities, human
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
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
2.2 STRUCTURE OF AN EAST DESCRIPTION
An EAST Data Description Record (DDR) includes a syntactic, and in some way semantic,
The physical description makes possible the interpretation of the actual bit patterns
- 3.2.1 3.2.2
- 3.2.4.1
- 3.2.4.3 ).
- 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
3.3.1
- octet and bit organization on the medium (high-order-first or low-order-first—see
3.3.2 ).
CCSDS 644.0 -B-1 May 1997
18 © ISO 2000 – All rights reserved
2-1 Page
the
); machine (see
);
The physical part of an EAST description includes:
their location within the set of the described data (see
); their size in bits (see
); and a logical description of all components of the exchanged data (see
The logical part of an EAST description includes:
: one for the logical part and another one for the associated physical part. a package
encountered on the medium. Each description part of a DDR consists of an EAST unit, called
description of the data called a logical description, which is followed by a physical description.
and the interpretation of data in an automated fashion.
forms in favor of more English-like constructs.
about the format and the nature of the described data is well established.
The need for data description languages that supply complete and non-ambiguous information
readability, and computer interpretability.

CCSDS RECOMMENDATION FOR EAST SPECIFICATION
package name_of_the_logical_description is
(see 3.2)
end name_of_the_logical_description ;
package name_of_the_physical_description is
(see 3.3)
end name_of_the_physical_description ;
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
are equal. Note that the representations written to an exchange medium do not have to be the
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.,
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
CCSDS 644.0 -B-1 May 1997
2-2 Page
is a model, defined once, that is used to create many occurrences (objects) of the models.
the information needed by a user to understand the data he has to deal with. The physical part
ones typically supported by the writing machine.
description different from the one on a 1750 architecture, although lengths in bits of each field
packages are mandatory even if the content of the physical one can be empty (see section
The logical description always precedes the physical description. The logical and the physical
Physical Description
Logical Description
Data Description Record
A DDR created using the EAST Language has the following structure:

CCSDS RECOMMENDATION FOR EAST SPECIFICATION
. An object in the language has
a type, which characterizes a set of values. The basic classes of types are scalar types
enumeration and numeric types composite types
array record types
A type has a name: if well chosen, this name is a way to provide the meaning of the model
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
except for
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
3.2.1.1.
Numeric type s provide a means of describing whole numbers and real numbers. Whole
numbers are described using integer type s. Real numbers are described using floating point
Composite type s allow definitions of structured objects with related components. The
composite types of the EAST language are arrays and records. An array is an object with
indexed components of the same type. The array type STRING is predefined and given in
3.2.1.1
A record may have special components called discriminants. Discriminants specify either
which of alternative record structures is to be used or the dynamic size of an internal array
The concept of type is refined by the concept of subtype, whereby a user can constrain the set
of allowed values of a type. Subtypes can be used to define subranges of scalar types and
Representation clause s are used to specify the mapping between logical types and their
physical representations. For example, the user specifies that objects of a given type are
represented with a given number of bits, or the components of a record are represented using
NOTES
1[E3] ). EAST contains
2The declarative part of Ada normally defines the logical entities and sometimes some
of their physical characteristics. EAST extends the descriptive power of the Ada
language (using conventions in the physical packages). It is able to describe not only
CCSDS 644.0 -B-1 May 1997
20 © ISO 2000 – All rights reserved
2-3 Page
the logical aspects of a data item, but also all its physical aspects.
therefore most of the declarative features of Ada, but no algorithmic features.
EAST is a subset of the Ada programming language (reference
a given storage layout.
values. arrays with a limited set of index
(depending on the values of the discriminants).
. A record is an object with named components of possibly different types. section
types, with relative bounds on the error.
CHARACTER is predefined and given in section
an EAST reserved keyword (reserved keywords are provided in section
particular date). The name used to identify a type or an object can be any identifier
has a name also: this name is a (e.g., the type DATE may describe a CCSDS date). An object
, describing sequences of objects). and (comprising
, describing single elements), and (comprising
Every data item described in an EAST description is an object

CCSDS RECOMMENDATION FOR EAST SPECIFICATION
3 DEFINITION OF THE EAST LANGUAGE
An EAST Data Description is a text composed of lexical elements, each composed of ASCII
characters: the 128 first characters of the Latin Alphabet No. 1. (see reference [1] and/or
0). The rules of composition are given in 3.1 . They are applicable to the whole EAST
3.1 LEXICAL ELEMENTS
lexical element is either a delimiter , an identifier (which may be a reserved word), a
. The rules of composition are
3.1.1 SEPARATORS AND DELIMITERS
In some cases an explicit separator is required to separate adjacent lexical elements (namely,
separator is
- A space character is a separator except within a comment , a string literal, or a space
- Control characters other than horizontal tabulation are always separators. Horizontal
.
- The end of a line is always a separator . What defines the end of a line is specified in
0.
delimiter
&  ’  (  )  *
...

NORME ISO
INTERNATIONALE 15889
Première édition
2000-10-01
Systèmes de transfert des informations et
données spatiales — Langage de
description de données — Spécification
EAST
Space data and information transfer systems — Data description
language — EAST specification
Numéro de référence
©
ISO 2000
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifiéà moins que l'ordinateur employéà cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la créationduprésent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l’ISO à
l’adresse ci-aprèsouducomité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.ch
Imprimé en Suisse
ii © ISO 2000 – Tous droits réservés

Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiéeaux
comités techniques de l'ISO. Chaque comité membre intéressé par une étude aledroit de fairepartie ducomité
technique créé à cet effet. Les organisations internationales, gouvernementales et non gouvernementales, en
liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI, Partie 3.
Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.
L’attention est appelée sur le fait que certains des éléments delaprésente Norme internationale peuvent faire
l’objet de droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable de
ne pas avoir identifié de tels droits de propriété et averti de leur existence.
La Norme internationale ISO 15889 a étéélaboréepar le Comité consultatif pour les systèmes de données
spatiales (CCSDS), en tant que publication CCSDS 644.0-B-1, mai 1997, et adoptée sans changements, excepté
ceux mentionnés dans l’article 2 de la présente Norme internationale, par le comité technique ISO/TC 20,
Aéronautique et espace, sous-comité SC 13, Systèmes de transfert des informations et données spatiales.
NORME INTERNATIONALE ISO 15889:2000(F)
Systèmes de transfert des informations et données spatiales —
Langage de description de données — Spécification EAST
1 Domaine d'application
La présente Norme internationale donne la spécification du language de description de données EAST
(CCSD0010) pour les systèmes de transfert des informations et données spatiales.
2 Exigences
Les exigences sont les recommandations techniques stipulées dans la publication suivante qui est adoptéecomme
Norme internationale:
CCSDS 644.0-B-1, May 1997, Recommendation for space data system standards — The data description
1)
language EAST specification (CCSD0010).
Aux fins de normalisation internationale, les modifications indiquées ci-après doivent être appliquées aux chapitres
et paragraphes suivants de la publication CCSDS 644.0-B-1.
Pages i à v
Cette partie est une information qui concerne la publication CCSDS seulement.
Page 1-5
L’ISO/CEI 10646:1993 (voir référence [2]) est citéede façon informative dans le document. La référence doit être
déplacée à l’annexe informative E, page E-1 et doit lire:
[E6] ISO/CEI 10646-1:1993, Technologies de l'information — Jeu universel de caractères codés à plusieurs
octets — Partie 1: Architecture et table multilingue.
3Révision de la publication CCSDS 644.0-B-1
Il a été convenu avec le Comité consultatif pour les systèmes de données spatiales (CCSDS) que le sous-comité
ISO/TC 20/SC 13 sera consulté dans l'éventualité d'une révision ou d'un amendement de la publication
CCSDS 644.0-B-1. À cette fin, la NASA agira en tant qu'organe de liaison entre le CCSDS et l'ISO.
1)
Unetraduction enfrançais de ce document a étéétablie par l’Agence spatiale française. Cette traduction est reproduite
ci-après.
(page blanche)
2 © ISO 2000 – Tous droits réservés

Comité
Consultatif pour
les Systèmes de Données Spatiales
RECOMMANDATION POUR LES NORMES SUR
LES SYSTEMES DE DONNEES SPATIALES
SPECIFICATION RELATIVE AU
LANGAGE DE DESCRIPTION DE
DONNEES EAST
(CCSD0010)
CCSDS 644.0-B-1
LIVRE BLEU
Mai 1997
RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
AUTORITES COMPETENTES
Edition : Livre Bleu, Edition n° 1
Date : Mai 1997
Lieu : São José dos Campos
São Paulo, Brésil
Le Comité Directeur du CCSDS (Consultative Committee for Space Data Systems - Comité Consultatif
pour les Systèmes de Données Spatiales) a autorisé à la publication le présent document qui synthétise
l'accord technique général des agences membres du CCSDS, participantes. La procédure de révision et
d'autorisation des Recommandations CCSDS est détaillée dans le Procedures Manual for the Consultative
Committee for Space Data Systems (référence [E1]) ; la position des agences lors de la procédure
d'autorisation de ce document est enregistrée et peut être demandée auprès du Secrétariat CCSDS à
l'adresse ci-dessous.
Ce document est publié et mis à jour par :
CCSDS Secretariat
Program Integration Division (Code MG)
National Aeronautics and Space Administration
Washington, DC 20546, USA
CCSDS 644.0 -B-1 Page i Mai 1997
4 © ISO 2000 – Tous droits réservés

RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
DECLARATION D'INTENTION
Le Comité Consultatif pour les Systèmes de Données Spatiales (CCSDS) est une organisation créée
officiellement par des agences spatiales membres. Le Comité se réunit périodiquement afin de traiter des
problèmes de systèmes de données qui sont communs à tous les participants, et de formuler des solutions
techniques adaptées à ces problèmes. Attendu que la participation au sein du CCSDS n'est pas obligatoire,
les décisions du Comité sont appelées Recommandations et n'engagent pas les agences.
La présente Recommandation est émise par l'Assemblée Plénière du CCSDS et en représente l'accord
général. L'adhésion d'une agence à cette Recommandation n'est pas obligatoire mais elle suppose
l'acceptation des conditions suivantes :
° Chaque fois qu'une agence crée une norme qui est du ressort du CCSDS, cette norme doit être
conforme à la Recommandation applicable. La création d'une norme n'exclut pas d'autres dispositions
qu'une agence pourrait entreprendre par ailleurs.
° Chaque fois qu'une agence crée une norme qui est du ressort du CCSDS, l'agence doit fournir aux
autres agences membres du CCSDS les informations suivantes :
- La norme elle-même.
- La date prévue pour l'entrée en vigueur.

- La durée prévue du service opérationnel.
° Les dispositions pour un service spécifique doivent être prises par l'intermédiaire de protocoles
d'accord. Ni la présente Recommandation ni aucune norme en résultant ne peuvent se substituer à un
protocole d'accord.
Cinq ans après sa date d'émission au plus tard, cette Recommandation sera révisée par le CCSDS afin de
déterminer : (1) si elle peut rester en vigueur sans aucune modification ; (2) si elle doit être modifiée afin de
refléter l'influence de nouvelles technologies, de nouveaux besoins ou de nouvelles orientations ; ou (3) si elle
doit être retirée ou annulée.
Lorsqu'une nouvelle version d'une Recommandation est publiée, les normes et implémentations des agences
qui sont du ressort du CCSDS, ne sont ni annulées ni jugées incompatibles avec le CCSDS. Il incombe à
chaque agence de déterminer si ces normes ou implémentations doivent être modifiées. Toutefois, il est
vivement recommandé à chaque agence de se baser, pour ses nouvelles normes et implémentations, sur la
version la plus récente de la Recommandation.
CCSDS 644.0 -B-1 Page ii Mai 1997
RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
AVANT-PROPOS
La présente Recommandation est une recommandation technique pour la normalisation d'un langage à utiliser
pour fournir des informations syntaxiques et dans une certaine mesure sémantiques que l'échange de données
en utilisant les Unités de Données à Structuration Normalisée (Standard Formatted Data Unit ou SFDU).
La présente Recommandation fournit la spécification relative à la syntaxe du langage EAST qui est un sous-
ensemble du langage Ada.
Au cours de l'évolution normale de ce document, on pourra procéder le cas échéant à des extensions, des
suppressions ou des modifications. Cette Recommandation est donc soumise aux procédures de contrôle et
de modification des documents CCSDS qui sont définies dans le document de référence [E1]. Les versions
actuelles des documents CCSDS sont conservées sur le site Web du CCSDS :
http://www.ccsds.org/ccsds/
Toute question concernant le contenu ou l'état de cette Recommandation doit être adressée au Secrétariat du
CCSDS, à l'adresse mentionnée à la page i .
CCSDS 644.0 -B-1 Page iii Mai 1997
6 © ISO 2000 – Tous droits réservés

RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
Agences Membres actives et Agences Observatrices du CCSDS au moment de la publication:
Agences Membres
- Agenzia Spaziale Italiana (ASI)/Italie.
- British National Space Centre (BNSC)/Royaume-Uni.
- Canadian Space Agency (CSA)/Canada.
- Centre National d'Etudes Spatiales (CNES)/France.
- Deutsche Forschungsanstalt für Luft- und Raumfahrt e.V. (DLR)/Allemagne.
- European Space Agency (ESA)/Europe.
- Instituto Nacional de Pesquisas Espaciais (INPE)/Brésil.
- National Aeronautics and Space Administration (NASA)/Etats-Unis.
- National Space Development Agency of Japan (NASDA)/Japon.
- Russian Space Agency (RSA)/Fédération de Russie.
Agences Observatrices
- Austrian Space Agency (ASA)/Autriche.
- Central Research Institute of Machine Building (TsNIIMash)/Fédération de Russie.
- Centro Tecnico Aeroespacial (CTA)/Brésil.
- Chinese Academy of Space Technology (CAST)/Chine.
- Commonwealth Scientific and Industrial Research Organization (CISRO)/Australie.
- Communications Research Laboratory (CRL)/Japon.
- Danish Space Research Institute (DSRI)/Danemark.
- 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)/Belgique.
- Hellenic National Space Committee (HNSC)/Grèce.
- Indian Space Research Organization (ISRO)/Inde.
- Industry Canada/Communications Research Center (CRC)/Canada.
- Institute of Space and Astronautical Science (ISAS)/Japon.
- Institute of Space Research (IKI)/Fédération de Russie.
- KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hongrie.
- MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
- Korea Aerospace Research Institute (KARI)/Corée.
- Ministry of Communications (MOC)/Israël.
- National Oceanic & Atmospheric Administration (NOAA)/Etats-Unis.
- National Space Program Office (NSPO)/Taipei.
- Swedish Space Corporation (SSC)/Suède.
- United States Geological Survey (USGS)/Etats-Unis.
CCSDS 644.0 -B-1 Page iv Mai 1997
RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
GESTION DE CONFIGURATION DU DOCUMENT
Document Titre Date Statut/Remarque
CCSDS 644.0-B-1 Recommandation pour les Mai 1997 Edition originale
Normes sur les Systèmes de
Données Spatiales :
Spécification relative au
Langage de Description de
Données EAST
(CCSDS0010)
CCSDS 644.0 -B-1 Page v Mai 1997
8 © ISO 2000 – Tous droits réservés

RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
SOMMAIRE
Section Page
1. INTRODUCTION.1-1
1.1 OBJET ET DOMAINE D'APPLICATION. 1-1
1.2 APPLICABILITE. 1-1
1.3 JUSTIFICATIONS. 1-1
1.4 STRUCTURE DU DOCUMENT. 1-2
1.5 DEFINITIONS. 1-2
1.5.1 TERMES. 1-2
1.5.2 NOMENCLATURE. 1-2
1.5.3 CONVENTIONS . 1-3
1.6 REFERENCES . 1-5
2. PRESENTATION GENERALE.2-1
2.1 OBJECTIFS DE CONCEPTION. 2-1
2.2 STRUCTURE D'UNE DESCRIPTION EAST. 2-1
2.3 RESUME DU LANGAGE. 2-2
3. DEFINITION DU LANGAGE EAST.3-1
3.1 ÉLÉMENTS LEXICAUX. 3-1
3.1.1 SEPARATEURS ET DELIMITEURS . 3-1
3.1.2 COMMENTAIRES. 3-1
3.1.3 IDENTIFICATEURS . 3-2
3.1.4 LITTERAUX NUMERIQUES . 3-2
3.2 DESCRIPTION LOGIQUE. 3-7
3.2.1 DECLARATIONS DE TYPES . 3-8
3.2.2 DECLARATIONS DE SOUS-TYPES. 3-23
3.2.3 DECLARATIONS D'OBJETS. 3-26
3.2.4 CLAUSES DE REPRESENTATIONS. 3-29
3.3 DESCRIPTION PHYSIQUE. 3-40
3.3.1 METHODE DE STOCKAGE DES TABLEAUX. 3-41
3.3.2 METHODE DE STOCKAGE OCTETS/BITS . 3-41
3.3.3 REPRESENTATION DE TYPES SCALAIRES . 3-43
3.3.4 RELATIONS ENTRE LA REPRESENTATION DE TYPES SCALAIRES ET DE
TYPES LOGIQUES. 3-54
CCSDS 644.0 -B-1 Page vi Mai 1997
RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
SOMMAIRE (suite)
Section. Page
3.3.5 MODELE D'UNE PARTIE DESCRIPTION PHYSIQUE . 3-56
4. MOTS-CLES RESERVES.4-1
5. CONCORDANCE.5-1
ANNEXE A SIGLES ET GLOSSAIRE.A-1
ANNEXE B DEFINITION DES CARACTÈRES.B-1
ANNEXE C SPECIFICATION RELATIVE A LA SYNTAXE FORMELLE DU LANGAGE
EAST.C-1
ANNEXE D PRINCIPALES DIFFÉRENCES ENTRE LES LANGAGES ADA ET EAST. D-1
ANNEXE E DOCUMENTS DE REFERENCE POUR INFORMATION .E-1
INDEX. .I-1
Figure
1-1 Exemple de schéma de syntaxe.1-3
3-1 Schéma de définition d'un identificateur .3-2
3-2 Schéma de définition d'un littéral décimal.3-2
3-3 Schéma de définition d'un littéral décimal entier.3-3
3-4 Schéma de définition d'un littéral décimal réel.3-3
3-5 Schéma de définition d'un entier.3-3
3-6 Schéma de définition d'un exposant.3-3
3-7 Schéma de définition d'un littéral basé .3-4
3-8 Schéma de définition d'un littéral basé entier.3-4
3-9 Schéma de définition d'un littéral basé réel.3-5
3-10 Schéma de définition d'un entier basé.3-5
3-11 Schéma de définition d'un littéral entier.3-6
3-12 Schéma de définition d'un littéral réel.3-6
3-13 Structure d'une partie logique.3-7
3-14 Schéma de spécification d'un type énumératif .3-8
3-15 Schéma de définition d'un littéral d'énumération.3-9
3-16 Schéma de spécification d'un type entier.3-9
3-17 Schéma de spécification d'un type réel.3-10
3-18 Schéma de spécification d'un type tableau.3-12
3-19 Schéma de spécification d'indice.3-12
3-20 Schéma de spécification d'un type article.3-14
3-21 Schéma de déclaration d'un composant.3-14
3-22 Schéma de contrainte d'indice.3-15
3-23 Schéma de spécification d'un discriminant.3-16
3-24 Schéma de spécification de partie variantes.3-16
3-25 Discriminants dans un format de paquet.3-19
CCSDS 644.0 -B-1 Page vii Mai 1997
10 © ISO 2000 – Tous droits réservés

RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
SOMMAIRE (suite)
Figure Page
3-26 Résumé des types.3-22
3-27 Schéma de déclaration de sous-types.3-23
3-28 Schéma de contrainte d'énumération.3-23
3-29 Schéma de contrainte d'entier .3-24
3-30 Schéma de contrainte de réel.3-25
3-31 Schéma de déclaration d'une variable.3-26
3-32 Schéma de déclaration d'une constante .3-26
3-33 Schéma de spécification d'une clause de longueur.3-29
3-34 Schéma de spécification d'une clause d'énumération.3-31
3-35 Schéma de spécification d'une clause de représentation de composant .3-32
3-36 Schéma de spécification d'une clause de représentation d'article.3-32
3-37 Première structure arborescente.3-34
3-38 Deuxième structure arborescente .3-35
3-39 Troisième structure arborescente.3-36
3-40 Quatrième structure arborescente.3-37
3-41 Schéma de spécification de distance.3-39
3-42 Schéma de spécification d'une valeur article.3-47
3-43 Schéma de spécification d'une valeur tableau.3-47
3-44 Format d'un entier décimal codé ASCII.3-52
3-45 Format d'un réel décimal codé ASCII.3-53
Exemple
1-1 Exemple de BNF .1-4
3-1 Littéraux décimaux .3-4
3-2 Littéraux basés.3-5
3-3 Déclarations de types énumératifs .3-9
3-4 Déclarations de types entiers.3-10
3-5 Déclarations de types réels .3-10
3-6 Définitions de type tableau contraint .3-13
3-7 Définitions de type tableau non contraint.3-13
3-8 Définitions de types articles.3-15
3-9 Définition d'un type article avec discriminant .3-17
3-10 Définition d'un type article avec discriminant .3-17
3-11 Description logique du format de paquet .3-21
3-12 Déclarations de sous-types de CHARACTER.3-24
3-13 Déclarations de sous-types.3-25
3-14 Déclaration de variable .3-26
3-15 Déclaration de constante.3-27
3-16 Déclarations de nombres .3-27
3-17 Déclaration de marqueur.3-28
CCSDS 644.0 -B-1 Page viii Mai 1997
RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
SOMMAIRE (suite)
Exemple Page
3-18 Déclarations de marqueur EOF.3-28
3-19 Déclarations de clause de longueur.3-29
3-20 Description explicite de l'espace inutilisé.3-30
3-21 Déclarations de clauses d'énumérations .3-31
3-22 Définitions de type.3-33
3-23 Déclaration d'une clause de représentation d'article complète.3-34
3-24 Déclaration d'une clause de représentation d'article incomplète .3-35
3-25 Déclaration d'une clause de représentation d'article complète.3-36
3-26 Déclaration d'une clause de représentation d'article complète.3-38
3-27 Clause de représentation d'article utilisant WORD_32_BITS.3-39
3-28 Méthode formelle de stockage de tableau.3-41
3-29 Possibilités de stockage des octets.3-42
3-30 Ordre formel des bits.3-43
3-31 Ordre des bits.3-45
3-32 Ordre des bits pour l'entier signé 16 bits précédent.3-48
3-33 Représentation binaire formelle de l'entier signé 16 bits précédent .3-48
3-34 Ordre des bits pour l'entier non signé 16 bits précédent .3-48
3-35 Représentation binaire formelle de l'entier non signé 16 bits précédent.3-49
3-36 Ordre des bits pour le réel 32 bits précédent.3-49
3-37 Représentation binaire formelle d'un réel 32 bits .3-50
3-38 Déclaration logique ASCII d'un type énumératif .3-52
3-39 Description physique ASCII d'un type énumératif.3-52
3-40 Déclaration logique ASCII d'un type entier.3-54
3-41 Description physique ASCII d'un type entier.3-54
3-42 Déclaration logique ASCII d'un type réel.3-54
3-43 Description physique ASCII d'un type réel.3-54
CCSDS 644.0 -B-1 Page ix Mai 1997
12 © ISO 2000 – Tous droits réservés

RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
1. INTRODUCTION
1.1 OBJET ET DOMAINE D'APPLICATION
Le présent document a pour objet d'établir une Recommandation commune pour la spécification d'un langage
standard permettant de désigner et d'exprimer des valeurs de données afin d'échanger des informations de
façon plus harmonisée et automatique au sein des Agences et entre Agences du CCSCS (Consultative
Committee for Space Data Systems - Comité Consultatif pour les Systèmes de Données Spatiales).
La présente Recommandation définit le langage EAST utilisé pour créer des descriptions de données,
appelées DDR (Data Description Records- Bloc de description de données). Ces DDR assurent une
compréhension totale et exacte des données et permettent de les interpréter de façon automatique; cela
signifie qu'un logiciel est capable d'analyser un DDR et d'interpréter le format des données associées. Cela
permet au logiciel d'extraire des valeurs à partir des données sur toute machine hôte (c'est-à-dire, sur une
machine différente de celle qui a produit les données).
Un premier aperçu de la référence [E4], qui est un tutoriel pour le langage EAST, peut aider l'utilisateur à
comprendre ce document. La référence [E4] décrit les exigences, explique les modalités d'utilisation du
langage EAST pour décrire des données non-ambiguës et fournit des méthodes et des instruments aux
utilisateurs.
La présente Recommandation est enregistrée à l'ADID du CCSDS (CCSDS Authority and Description
Identifier- Identificateur d'autorité de contrôle et de description de données) : CCSD0010.
1.2 APPLICABILITE
Les spécifications contenues dans le présent document sont applicables à tous les échanges d'informations
scientifiques et techniques liés aux missions spatiales, susceptibles d'utiliser des descriptions de données. Ces
descriptions doivent fournir une description non ambiguë de la structure des articles de données.
1.3 JUSTIFICATIONS
Le Comité Consultatif pour les Systèmes de Données Spatiales a défini le concept de SFDU (Standard
Formatted Data Unit- Unité de Données à Structuration Normalisée) pour la mise en oeuvre de structures de
données normalisées à utiliser pour l'échange de données au sein et entre agences spatiales.
Les produits de données SFDU pourront être considérés comme contenant des données d'application (c'est-
à-dire des données qui présentent un intérêt particulier, par exemple, les mesures effectives) et des
informations de description de données (c'est-à-dire des informations expliquant les modalités de formatage
des données d'application).
Les informations de description de données doivent être fournies sous une forme compréhensible pour les
agences concernées par l'échange de données. Pour cette raison, le CCSDS doit fournir quelques
recommandations pour la définition de langages de description normalisés. EAST est un des langages
recommandés.
CCSDS 644.0 -B-1 Page 1-1 Mai 1997
RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
1.4 STRUCTURE DU DOCUMENT
La présente Recommandation est organisée selon la structure suivante :
- La section 2 propose une présentation générale du langage EAST.
- La section 3 apporte des spécifications sur le langage EAST, et définit son utilisation dans les
Descriptions de Données.
- La section 4 fournit une liste des mots-clés réservés du langage EAST.
- L'annexe A présente les sigles et le glossaire des termes utilisés dans le présent document.
- L'annexe B définit le jeu de caractères à utiliser pour une description de données EAST, ainsi qu'un
type prédéfini dénommé CHARACTER.
- L'annexe C établit les spécifications formelles en utilisant une variante simple de la forme de Backus-
Naur (BNF).
- L'annexe D présente une liste des principales différences entre le langage de programmation Ada et le
langage EAST.
- L'annexe E présente une liste des documents de référence à titre d'information.
1.5 DEFINITIONS
1.5.1 TERMES
Les termes utilisés dans le présent document sont répertoriés dans une liste qui figure à l'Annexe A. Ils sont
également expliqués dans le texte la première fois qu'ils sont utilisés.
1.5.2 NOMENCLATURE
Les conventions suivantes seront en vigueur pour la présente Recommandation:
a) l'utilisation du verbe "devoir" (doit/doivent) implique une obligation et une spécification vérifiable ;
b) l'utilisation du verbe "devoir" au conditionnel (devrait/devraient) implique le caractère facultatif, mais
souhaitable, d'une spécification;
c) l'utilisation du verbe "pourvoir" (peut/peuvent) implique une spécification facultative;
d) si ces verbes ne sont pas utilisés, il s'agit d'une simple assertion.
CCSDS 644.0 -B-1 Page 1-2 Mai 1997
14 © ISO 2000 – Tous droits réservés

RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
1.5.3 CONVENTIONS
Le présent document utilise des schémas de syntaxe pour illustrer la syntaxe des différentes constructions du
langage EAST. Les différents composants d'une construction sont appelés éléments. Les conventions
suivantes sont adoptées :
a) Les éléments présentés en caractères gras à l'intérieur d'un cercle sont des mots-clés réservés, des
délimiteurs, ou des littéraux.
b) L'élément désigné à gauche du symbole ::= est l'élément que l'on définit.
c) Le schéma situé à droite du symbole ::= représente la définition correspondante.
d) Une branche verticale représente un choix.
e) Une répétition est indiquée par une boucle d'itération au-dessus de l'objet à répéter.
f) Si le nom d'une catégorie syntaxique contient une partie en italique, il est équivalent au nom de la
catégorie sans la partie en italique. La partie en italique est sensée apporter une information
sémantique. Par exemple, un "Identificateur Entier" est un Identificateur ; c'est-à-dire qu'on se réfère
à la définition de la catégorie Identificateur, mais le lecteur a une information sémantique
supplémentaire (c'est un entier).
L'exemple suivant présente un schéma qui spécifie la déclaration de l'élément A. L'élément A est défini par
premier mot-clé ("type"), puis il est suivi d'un élément B en italique (déjà défini, et identifié comme élément B),
puis il est suivi par un mot-clé ("is") et un délimiteur ("("). Cette structure est alors suivie d'un choix entre les
éléments B et C. Le choix peut être répété un nombre de fois quelconque, à chaque fois qu'un délimiteur (",")
est inséré. La structure se termine par deux délimiteurs (")" et ";").
,
Elément C
Elément B
Déclaration
) ;
::= type is (
élément A en italique
Elément B
Figure 1-1: Exemple de schéma de syntaxe
CCSDS 644.0 -B-1 Page 1-3 Mai 1997
RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
La syntaxe du langage est décrite par une variante simple de la forme Backus-Naur conformément aux
conventions suivantes :
a) Les mots en caractères gras s'utilisent pour dénoter les mots-clés réservés.
b) Les crochets encadrent des éléments optionnels.
c) Les accolades encadrent un élément répété. L'élément peut apparaître zéro ou plusieurs fois.
d) Une barre verticale sépare les alternatives à moins qu'elle n'apparaisse immédiatement après une
accolade ouvrante ({):, auquel cas elle représente le caractère 'barre verticale' .
e) Si le nom d'une catégorie syntaxique contient une partie en italique, il est équivalent au nom de la
catégorie sans la partie en italique. La partie en italique est sensée apporter une information
sémantique. Cette particularité utilisée dans la syntaxe de la Forme Backus-Naur tente d'assimiler
chaque élément sous la forme à l'élément précédemment défini .
L'exemple suivant présente la définition de l'élément A en utilisant une variante simple de la forme Backus-
Naur. L'élément A est tout d'abord défini comme un mot-clé ("type"), puis il est suivi d'un élément B en
italique (déjà défini et connu comme élément B), il est alors suivi d'un mot-clé ("is") et un délimiteur ("("). La
structure est suivie par un choix. Le choix peut être répété un nombre de fois quelconque, chaque fois qu'un
délimiteur (",") est inséré. La structure se termine par deux délimiteurs (")" et ";"). Le choix s'opère entre les
éléments B et C.
::= type < Elément B_en_italique> is ( { , } ) ;
::= |
Exemple 1-1: Exemple de BNF
Pour lever toute ambiguïté, le schéma de syntaxe et le texte correspondant constituent toujours
une référence pour la syntaxe du langage EAST, et non pour la syntaxe du BNF.
Ce document présente des exemples qui illustrent le langage EAST. Les conventions suivantes sont adoptées
dans les exemples:
a) les caractères gras s'utilisent pour dénoter les mots-clés réservés ou les délimiteurs ;
b) les noms types utilisateur ou les noms variables utilisateur apparaissent en lettres majuscules, bien que
dans le langage EAST, l'utilisation de majuscules ou de minuscules ne soit pas significative.
CCSDS 644.0 -B-1 Page 1-4 Mai 1997
16 © ISO 2000 – Tous droits réservés

RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
1.6 REFERENCES
Les documents suivants contiennent des dispositions qui, citées en référence dans le présent texte, constituent
des dispositions de la présente Recommandation. Au moment de la publication, toutes les éditions indiquées
étaient valables, mais ces documents étant soumis à une révision, il est recommandé aux utilisateurs de cette
recommandation de se renseigner sur l'édition la plus récente des documents référencés ci-dessous. Le
secrétariat du CCSDS tient à jour un registre sur les éditions actuellement valables de toutes les
Recommandations CCSDS.
[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-1 Page 1-5 Mai 1997
RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
2. PRESENTATION GENERALE
2.1 OBJECTIFS DE CONCEPTION
EAST a été conçu avec trois préoccupations principales : la possibilité de décrire des données, la lisibilité
pour l'homme et l'interprétabilité pour les ordinateurs.
La nécessité de disposer de langages de description de données qui fournissent des informations exhaustives
et non ambiguës sur le format et la nature des données décrites est bien établie.
Tout utilisateur doit être capable de comprendre les descriptions de données, sans trop d'efforts. Les
notations favorisant les erreurs ont été évitées, et la syntaxe du langage EAST évite l'utilisation de formes
cryptiques au profit de constructions plus proches de l'anglais.
EAST est un langage formel et non un langage naturel : c'est un langage compilable (ou interprétable) par une
machine. La nature formelle du langage EAST permet le contrôle des descriptions de données et
l'interprétation des données de façon automatique.
2.2 STRUCTURE D'UNE DESCRIPTION EAST
Un DDR (Data Description Record- Bloc de Description de Données) EAST comprend une description
syntaxique des données, et d'une certaine façon sémantique, appelée description logique, qui est suivie par
une description physique. La description physique permet l'interprétation des profils binaires effectifs
rencontrés sur le support. Chaque partie de la description d'un DDR correspond à une unité EAST, appelée
paquetage: un pour la partie logique et un autre pour la partie physique correspondante.
La partie logique d'une description EAST comprend:
- une description logique de tous les composants des données échangées (voir 3.2.1 et 3.2.2);
- leur taille en bits (voir 3.2.4.1);
- leur emplacement dans l'ensemble des données décrites (voir 3.2.4.3).
La partie physique d'une description EAST comprend:
- la représentation de quelques types de données simples (énumératif, entier, et réel) définis dans la
description logique et dépendants de la machine génératrice (voir 3.3.3);
- l'organisation du tableau (first-index-first ou last-index-first) utilisée par la machine génératrice (voir
3.3.1);
- l'organisation des bits et des octets sur le support (high-order-first ou low-order-first - voir 3.3.2).
CCSDS 644.0 -B-1 Page 2-1 Mai 1997
18 © ISO 2000 – Tous droits réservés

RECOMMANDATION CCSDS SUR LA SPECIFICATION EAST
La structure d'un DDR créé grâce à l'utilisation du langage EAST est la suivante:
Bloc de Description de Données
package nom_de_la_description_logique is
Description logique (voir 3.2)
end nom_de_la_description_logique ;
package nom_de_la_description_physique is
Description physique (voir 3.3)
end nom_de_la_description_physique ;
La description logique précède toujours la description physique. Les paquetages logique et physique sont
obligatoires même si le contenu du paquetage physique peut rester vide (voir section 3.3).
La conception du DDR en deux parties permet de disposer de parties de description physique
interchangeables pour une seule partie de description logique, sous réserve que la longueur des champs en
bits dans la description logique soit supportée par des longueurs de champs du même nombre de bits dans la
partie de description physique. Par exemple, un nombre réel 32 bits avec une architecture IEEE a une
description physique différente de celle de ce même nombre dans une architecture 1750, bien que les
longueurs en bits de chaque champ soient égales. Il faut noter que les représentations écrites sur un support
ne doivent pas nécessairement être celles utilisées en mémoire par la machine qui écrit.
Le bloc de données associé au DDR comporte un ou plusieurs ensembles de données. Le DDR ne
décrit qu'un seul ensemble et il est utilisé de façon répétée afin d'interpréter entièrement le bloc de
données.
2.3 RESUME DU LANGAGE
Une description EAST comporte deux unités, appelés paquetages. Le premier paquetage est une description
logique et le deuxième est une description physique des données. La partie logique d'une description EAST
fournit des informations syntaxiques et d'une certaine façon des informations sémantiques, c'est à dire les
informations dont un utilisa
...