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

**RECOMMENDATION FOR SPACE\
DATA SYSTEM STANDARDS**

  -----------------------------------------------------------------------
  **THE DATA DESCRIPTION LANGUAGE EAST\
  SPECIFICATION**\
  **(CCSD0010)**

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

**CCSDS 644.0-B-1**

**BLUE BOOK**

May 1997

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

# 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

# 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.

# 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.

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

[Member Agencies]{.underline}

> Ð 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]{.underline}

> Ð 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.

DOCUMENT CONTROL

  ------------------ -------------------------- ---------- --------------------
  **Document**       **Title**                  **Date**   **Status/Remarks**

  CCSDS 644.0-B-1    Recommendation for Space   May 1997   Original Issue
                     Data System Standards: The            
                     Data Description Language             
                     EAST Specification                    
                     (CCSD0010)                            
  ------------------ -------------------------- ---------- --------------------

# CONTENTS

Section Page

**1 INTRODUCTION**

1.1 PURPOSE AND SCOPE

1.2 APPLICABILITY

1.3 RATIONALE

1.4 DOCUMENT STRUCTURE

1.5 DEFINITIONS

1.5.1 TERMS

1.5.2 NOMENCLATURE

1.5.3 CONVENTIONS

1.6 REFERENCES

2 OVERVIEW

2.1 DESIGN AIMS

2.2 STRUCTURE OF AN EAST DESCRIPTION

2.3 LANGUAGE SUMMARY

3 DEFINITION OF THE EAST LANGUAGE

3.1 LEXICAL ELEMENTS

3.1.1 SEPARATORS AND DELIMITERS

3.1.2 COMMENTS

3.1.3 IDENTIFIERS

3.1.4 NUMERIC LITERALS

3.2 LOGICAL DESCRIPTION

3.2.1 TYPE DECLARATIONS

3.2.2 SUBTYPE DECLARATIONS

3.2.3 OBJECT DECLARATIONS

3.2.4 REPRESENTATION CLAUSES

3.3 PHYSICAL DESCRIPTION

3.3.1 WAY OF STORING ARRAYS

3.3.2 WAY OF STORING OCTETS/BITS

3.3.3 REPRESENTATION OF SCALAR TYPES

3.3.4 RELATIONSHIP BETWEEN THE REPRESENTATION OF SCALAR TYPES AND
LOGICAL TYPES

# CONTENTS (continued)

Section Page

3.3.5 TEMPLATE OF A PHYSICAL DESCRIPTION PART

4 RESERVED KEYWORDS

5 CONFORMANCE

ANNEX A ACRONYMS AND GLOSSARY A-

ANNEX B CHARACTER DEFINITION B-

ANNEX C EAST FORMAL SYNTAX SPECIFICATION C-

ANNEX D MAIN DIFFERENCES BETWEEN ADA AND EAST D-

ANNEX E INFORMATIVE REFERENCES E-

INDEX I-

Figure

1-1 Example of Syntax Diagram

3-1 Identifier Definition Diagram

3-2 Decimal Literal Definition Diagram

3-3 Integer Decimal Literal Definition Diagram

3-4 Real Decimal Literal Definition Diagram

3-5 Integer Definition Diagram

3-6 Exponent Definition Diagram

3-7 Based Literal Definition Diagram

3-8 Integer Based Literal Definition Diagram

3-9 Real Based Literal Definition Diagram

3-10 Based Integer Definition Diagram

3-11 Integer Literal Definition Diagram

3-12 Real Literal Definition Diagram

3-13 Logical Part Structure

3-14 Enumeration Type Specification Diagram

3-15 Enumeration Literal Definition Diagram

3-16 Integer Type Specification Diagram

3-17 Real Type Specification Diagram

3-18 Array Type Specification Diagram

3-19 Index Specification Diagram

3-20 Record Type Specification Diagram

3-21 Component Declaration Diagram

3-22 Index Constraint Diagram

3-23 Discriminant Specification Diagram

3-24 Variant Part Specification Diagram

3-25 Discriminants in a Packet Format

# CONTENTS (continued)

Figure Page

3-26 Type Summary

3-27 Subtype Declaration Diagram

3-28 Enumeration Constraint Diagram

3-29 Integer Constraint Diagram

3-30 Real Constraint Diagram

3-31 Variable Declaration Diagram

3-32 Constant Declaration Diagram

3-33 Length Clause Specification Diagram

3-34 Enumeration Clause Specification Diagram

3-35 Component Representation Clause Specification Diagram

3-36 Record Representation Clause Specification Diagram

3-37 First Tree Structure

3-38 Second Tree Structure

3-39 Third Tree Structure

3-40 Fourth Tree Structure

3-41 Distance Specification Diagram

3-42 Record Value Specification Diagram

3-43 Array Value Specification Diagram

3-44 ASCII Encoded Decimal Integer Format

3-45 ASCII Encoded Decimal Real Format

Example

1-1 Example of BNF

3-1 Decimal Literals

3-2 Based Literals

3-3 Enumeration Type Declarations

3-4 Integer Type Declarations

3-5 Real Type Declarations

3-6 Constrained Array Type Definitions

3-7 Unconstrained Array Type Definitions

3-8 Record Type Definitions

3-9 Record Type Definition with Discriminant

3-10 Record Type Definition with Discriminant

3-11 Logical Description of the Packet Format

3-12 Character Declarations

3-13 Subtype Declarations

3-14 Variable Declaration

3-15 Constant Declaration

3-16 Number Declarations

3-17 Marker Declaration

# CONTENTS (continued)

Example Page

3-18 EOF Marker Declaration

3-19 Length Clause Declarations

3-20 Explicit Description of Unused Space

3-21 Enumeration Clause Declarations

3-22 Type Definitions

3-23 Complete Record Representation Clause Declaration

3-24 Incomplete Record Representation Clause Declaration

3-25 Complete Record Representation Clause Declaration

3-26 Complete Record Representation Clause Declaration

3-27 Record Representation Clause Using WORD_32_BITS

3-28 Actual Array Storage Method

3-29 Octet Storage Possibilities

3-30 Actual Bit Order

3-31 Bit Ordering

3-32 Bit Ordering for the Above 16-Bit Signed Integer

3-33 Actual Binary Representation of the Above 16-Bit Signed Integer

3-34 Bit Ordering for the Above 16-Bit Unsigned Integer

3-35 Actual Binary Representation of the Above 16-Bit Unsigned Integer

3-36 Bit Ordering for the Above 32-Bit Real

3-37 Actual Binary Representation of a 32-Bit Real

3-38 ASCII Enumeration Type Logical Declaration

3-39 ASCII Enumeration Type Physical Description

3-40 ASCII Integer Type Logical Declaration

3-41 ASCII Integer Type Physical Description

3-42 ASCII Real Type Logical Declaration

3-43 ASCII Real Type Physical Description

1.  

# Number range chapitreINTRODUCTION

## 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 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.

## APPLICABILITY

The specifications in this document are applicable to all space-related
science and engineering data exchanges where data descriptions are
desired, and these descriptions need to provide an unambiguous
description of the record structure of the data.

## 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.

## 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 contains acronyms and the glossary of terms used in this
document.

− Annex defines the character set to be used in an EAST data
description, as well as a predefined type called CHARACTER.

− Annex provides the EAST formal specification using a simple variant of
the Backus-Naur-Form (BNF).

− Annex lists the main differences between the Ada programming language
and EAST.

− Annex lists the informative references.

## DEFINITIONS

### TERMS

The terms used throughout this document are listed in annex A. They are
also explained in the text when they are first used.

### 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.

### 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 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 ";").

![](media/image3.emf)

Figure 1-1: Example of Syntax Diagram 11

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
\<*italicized_part*\_name\> to the previously defined element \<name\>.

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.

> \<Item A\> ::= **type** \<*Italicized*\_Item B\> **is (** \<choice\> {
> , \<choice\> } **) ;\
> **\<choice\> ::= \<Item B\> \| \<Item C\>

Example 1-1: Example of BNF 11

**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.

## REFERENCES

The following documents contain provisions which, through reference in
this text, constitute provisions of this Recommendation. At the time of
publication, the editions indicated were valid. All documents are
subject to revision, and users of this Recommendation are encouraged to
investigate the possibility of applying the most recent editions of the
docu­ments indicated below. The CCSDS Secretariat maintains a register of
currently valid CCSDS Recommendations.

\[1\] *Information Processing---8-Bit Single-Byte Coded Graphic
Character Sets---Part 1: Latin Alphabet No. 1*. International Standard,
ISO 8859-1:1987. Geneva: ISO, 1987.

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

# Number range chapitreOVERVIEW

## 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.

## 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).

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 section 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.**

## 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.

Every data item described in an EAST description is an object. An object
in the language has a type, which characterizes a set of values. The
basic classes of types are *scalar types* (comprising *enumeration* and
*numeric types*, describing single elements), and *composite types*
(comprising *array* and *record types*, describing sequences of
objects).

A type has a name: if well chosen, this name is a way to provide the
meaning of the model (e.g., the type DATE may describe a CCSDS date). An
object has a name also: this name is a way to provide (if any) the
particularity of the occurrence (e.g., the object
DATE_AT_THE_BEGINNING_OF_THE_ORBIT of the type DATE may represent a
particular date). The name used to identify a type or an object can be
any identifier except for an EAST reserved keyword (reserved keywords
are provided in section 4).

An enumeration type defines an ordered set of distinct enumeration
literals; for example, a Boolean type defines two enumeration literals
(TRUE and FALSE). The enumeration type CHARACTER is predefined and given
in section 3.2.1.1.

Numeric types provide a means of describing whole numbers and real
numbers. Whole numbers are described using integer types. Real numbers
are described using floating point types, with relative bounds on the
error.

Composite types 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 section 3.2.1.1. A
record is an object with named components of possibly different types.

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 (depending on the
values of the discriminants).

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 arrays with a limited set
of index values.

Representation clauses 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 a
given storage layout.

NOTES

1 EAST is a subset of the Ada programming language (reference \[E3\]).
EAST contains therefore most of the declarative features of Ada, but no
algorithmic features.

2 The 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 the logical aspects of a data
item, but also all its physical aspects.

# Number range chapitreDEFINITION 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 annex ). The rules of
composition are given in 3.1. They are applicable to the whole EAST DDR.

## LEXICAL ELEMENTS

A **lexical element** is either a delimiter, an identifier (which may be
a reserved word), a numeric literal, a character string, a string
literal, or a comment. The rules of composition are given in this
section.

### SEPARATORS AND DELIMITERS

In some cases an explicit separator is required to separate adjacent
lexical elements (namely, when without separation, interpretation as a
single lexical element is possible). A **separator** is any of a space
character, a control character, or the end of a line.

− A space character is a separator except within a comment, a string
literal, or a space character literal.

− Control characters other than horizontal tabulation are always
separators. Horizontal tabulation is a separator except within a
comment.

− The end of a line is always a separator. What defines the end of a
line is specified in annex .

A **delimiter** is either one of the following special characters:

& ' ( ) \* + , - . / : ; \< = \> \|

or one of the following compound delimiters, each composed of two
adjacent special characters:

=\> .. \*\* := /= \>= \<= \<\< \>\> \<\>

Each of the special characters listed for single character delimiters is
a single delimiter except if this character is used as a character of a
compound delimiter, or as a character of a comment, string literal,
character literal, or numeric literal.

The remaining forms of lexical elements are described in 3.1.2, 3.1.3
and 3.1.4.

### COMMENTS

A comment starts with two adjacent hyphens and extends up to the end of
the line. A comment can appear on any line of a description.

### IDENTIFIERS

Identifiers are used as names and also as reserved words. See below in
Figure 3-1, the lexical definition of an identifier:

![](media/image4.emf)

Figure 3-1: Identifier Definition Diagram31

All characters of an identifier are significant, including any underline
character inserted between a letter or a digit and an adjacent letter or
digit. Identifiers differing in the use of corresponding upper and lower
case letters are considered to be the same.

### NUMERIC LITERALS

A numeric literal is either a decimal literal or a based literal. A
decimal literal is a numeric literal expressed in the conventional
decimal notation (that is, the base is implicitly ten). A based literal
is a numeric literal expressed in a form that specifies the base
explicitly. The base can only be either two, eight, or sixteen.

In another way, a numeric literal is either an integer literal (decimal
or based) or a real literal (decimal or based).

**a) decimal literals**

![](media/image5.emf)

Figure 3-2: Decimal Literal Definition Diagram 32

where Integer Decimal Literal and Real Decimal Literal are defined as in
Figures 3-3 and 3-4:

![](media/image6.emf)

Figure 3-3: Integer Decimal Literal Definition Diagram 33

![](media/image7.emf)

> Figure 3-4: Real Decimal Literal Definition Diagram 34

where Integer and Exponent are defined as in Figures 3-5 and 3-6:

![](media/image8.emf)

Figure 3-5: Integer Definition Diagram35

![](media/image9.emf)

Figure 3-6: Exponent Definition Diagram36

An underline character inserted between adjacent digits of a decimal
literal does not affect the value of this decimal literal. The letter E
of the exponent, if any, can be written either in lowercase or in
uppercase, with the same meaning. Leading zeros are allowed. No space is
allowed in a decimal literal.

> 12 0 1E6 123_456 \-- integer literals\
> 12.0 0.0 0.456 3.14159_26 \-- real literals\
> 1.3E-12 1.0E+6 \-- real literals with exponent

Example 3-1: Decimal Literals 31

**b) based literals**

![](media/image10.emf)

Figure 3-7: Based Literal Definition Diagram37

where Integer Based Literal and Real Based Literal are defined as in
Figure 3-8 and Figure 3-9:

![](media/image11.emf)

Figure 3-8: Integer Based Literal Definition Diagram38

![](media/image12.emf)

Figure 3-9: Real Based Literal Definition Diagram39

where Based Integer is defined as in Figure 3-10:

![](media/image13.emf)

Figure 3-10: Based Integer Definition Diagram310

The only letters allowed as extended digits are the letters A through F
representing ten through fifteen. Letters are allowed for a based
integer only if the base of the literal of which it is a part is 16. A
letter in a based literal can be written either in lowercase or in
uppercase, with the same meaning. No space is allowed in a based
literal.

> 2#1111_1111# 16#FF# 016#0FF# \-- integer literals of value 255\
> 16#E#E1 2#1110_0000# \-- integer literals of value 224
>
> 16#F.FF#E+2 2#1.1111_1111_111#E11 \-- real literals of value 4095.0

Example 3-2: Based Literals 32

**c) integer literals**

![](media/image14.emf)

Figure 3-11: Integer Literal Definition Diagram311

**c) real literals**

![](media/image15.emf)

Figure 3-12: Real Literal Definition Diagram312

## LOGICAL DESCRIPTION

The logical part of an EAST DDR is composed of:

− the logical description of the models of data (using type and subtype
declarations for the syntactic definition of the data, and using
representation clauses for the specification of their size in bits and
their location within the set of data);

− the declaration of the data occurrences, i.e., the declaration of the
described data items (using object declarations).

The logical part of the Data Description Record consists of a package.
This unit is introduced by the keyword **package**, followed by the
package name, and ends with "**end** package name**;**". The package
name is an identifier (see 3.1.3).

Types are models, and objects are instances (or occurrences) of these
models. Type declarations describe therefore the structure of the data
elements which may occur in the described data, while **the actual data
occurrences are represented by the declaration of variables and
constants**.

A type (except predefined type), a subtype or a constant (except
predefined constant) must be declared in the package before being used.

The declaration of variables must occur in the latter section of the
logical description. Constants may be declared in the type declaration
section or in the section for the declaration of variables: in the first
section, they contribute to data models definition, while they represent
data occurrences in the second section.

The described data is a concatenation of elements in the order of the
corresponding variables. The types used in the declaration of variables
must have been previously declared in the package.

Figure 3-13 summarizes the content of the logical part of a DDR.

  ------------------------ ---------------------------------------------------------------- --- --
  **package**                                                                                   
  *logical_package_name*                                                                        
  **is**                                                                                        

                           **Section for the Declaration of Types: Definition of the Data       
                           Models**                                                             

                           − type declarations and representation clauses (see 3.2.1 and        
                           3.2.4)\                                                              
                           − subtype and constant declarations (see 3.2.2 and 3.2.3.2)          

                           **Section for the Declaration of Variables: Definition of the        
                           Data Occurrences**                                                   

                           − variable and constant declarations (see 3.2.3.1 and 3.2.3.2)       

  **end**                                                                                       
  *logical_package_name* ;                                                                      
  ------------------------ ---------------------------------------------------------------- --- --

Figure 3-13: Logical Part Structure313

### TYPE DECLARATIONS

The type is characterized by a set of permissible values. Several
classes of types exist: scalar types (enumeration types, integer types,
and real types), array types, and record types. Some types are EAST
predefined types (see 3.2.1.1); the other types are user defined types
and must be declared according to a specific syntax (see 3.2.1.2,
3.2.1.3, 3.2.1.4, 3.2.1.5 and 3.2.1.6).

#### Predefined Types

There are three predefined types provided by the EAST language:
CHARACTER, STRING and EOF. Predefined means that no previous declaration
has to be made explicitly by the user to use one of these types.

The predefined type CHARACTER is an enumeration type (see next
subsection for the enumeration definition syntax rules), whose values
are the 256 characters of the 8-bit coded Latin Alphabet No. 1.
character set (see annex and reference \[1\]).

The values of the predefined type STRING are one-dimensional arrays of
the predefined type CHARACTER, indexed by values in increments of one of
any positive integer type.

The number of characters must be specified every time the type is used.

As an example STRING(1 .. 10) designates a 10 character string, while
STRING(10 .. 22) designates a 13 character string.

The predefined type EOF is exclusively used to declare a fictive end
delimiter called EOF Marker (see 3.2.3.2.2).

#### Enumeration Type

An enumeration type is defined as a set of enumeration literals. An
enumeration literal is an identifier or a character literal for one of
the possible values of the type. Figure 3-14 illustrates the syntax of
an enumeration type specification. Each enumeration literal yields a
different enumeration value.

![](media/image16.emf)

Figure 3-14: Enumeration Type Specification Diagram314

where the enumeration literal is defined as in Figure 3-15:

![](media/image17.emf)

Figure 3-15: Enumeration Literal Definition Diagram315

The following example presents some enumeration type definitions.

> **type** DAY **is** (MON, TUE, WED, THU, FRI, SAT, SUN)**;**\
> **type** STATE **is** (OFF , ON);\
> **type** ROMAN_DIGIT **is** ('I' , 'V' , 'X' , 'L' , 'C' , 'D' , 'M');

Example 3-3: Enumeration Type Declarations 33

#### Integer Type

An integer type is defined as a set of integer values specified by a
range. Each bound of the range is an integer constant identifier (see
3.2.3.2) or an integer literal (see 3.1.4). Note that both bounds need
not have the same integer type and that negative bounds are allowed. The
range L .. R specifies the value from L to R inclusive if the relation L
\<= R is true. A *null* range is a range for which the relation R \< L
is true; no value belongs to a null range.

Figure 3-16 illustrates the syntax of an integer type specification.

![](media/image18.emf)

Figure 3-16: Integer Type Specification Diagram316

The following example presents an integer type, defined using integer
literals (-10 and 10) and an integer type, defined using a constant
identifier (MAX).

> **type** SMALL_INTEGER **is** **range** -10 **..** 10**;**\
> **type** NUMBER **is range** 0 **..** MAX**;**\
> \-- where MAX could be defined as: MAX := 100;

Example 3-4: Integer Type Declarations 34

#### Real Type

Real types provide approximations to real numbers, with relative bounds
on errors. The error bound is specified as a relative precision by
giving the required minimum number of significant decimal digits. The
range bounds are optional. When they are specified, they are either real
constant identifier (see 3.2.3.2) or real literal (see 3.1.4).

Figure 3-17 illustrates the syntax of a real type specification.

![](media/image19.emf)

Figure 3-17: Real Type Specification Diagram317

The following example presents some real type definitions.

> **type** COEFFICIENT **is** **digits** 10 **range** 0.1 **..**
> 1.0**;**\
> **type** REAL **is digits** 15**;**

Example 3-5: Real Type Declarations 35

NOTE − The range is optional in a real type declaration. If the real
type declaration specifies no range, then the range is supposed to be
the largest range that can be implemented within the specified number of
bits (see 3.2.4.1) accommodating the number of significant digits. When
unspecified, the range will depend on the convention used to represent
the binary values of the real type (see 3.3.3.1).

#### Array Type

An array type is a composite type consisting of components that have the
same type. The name for a component of an array uses one or more index
values belonging to specified discrete types.

A discrete type is either an enumeration type or an integer type.

An array type is characterized by:

− an ordered list of indices;

− the type of each index;

− the lower and upper bound for each index;

− the type of the components.

The order of indices is significant. The index type and component type
declarations must precede the array type declaration that makes use of
them, except if one of these types is a predefined type of the EAST
language.

A one-dimensional array has a distinct component for each possible index
value. A multi-dimensional array has a distinct component for each
possible sequence of index values that can be formed by selecting one
value for each index position within the list of indices (in the given
order).

The possible values for a given index are all the values between the
lower and upper bounds, inclusive; this range of values is called the
index range. Figure 3-18 illustrates the syntax of an array type
specification.

![](media/image20.emf)

Figure 3-18: Array Type Specification Diagram318

An array type can be constrained (i.e., have a fixed number of elements)
or unconstrained (i.e., have an undetermined number of elements),
depending on the specification of the indices. In multi-dimensional
array types, the indices are either all determined or all undetermined.

An index is specified as follows:

![](media/image21.emf)

Figure 3-19: Index Specification Diagram319

In the ".." notation, the first identifier or literal specifies the
lower bound, while the second one specifies the upper bound.

The "range \<\>" expression denotes an undetermined number of elements.

The following example defines array types, for which the number of
elements is known: 100 characters in a line, and 7 states in a schedule.

> **type** LINE **is array**(1 .. 100) **of** CHARACTER;\
> *\-- CHARACTER is an EAST predefined type*\
> **type** SCHEDULE **is array**(DAY) **of** STATE;\
> *\-- DAY is an enumeration type defined in 3.2.1.2 as:\
> \-- type DAY is (MON, TUE, WED, THU, FRI, SAT, SUN);*

Example 3-6: Constrained Array Type Definitions 36

The following example defines array types, for which the number of
elements is not known: because of the definition of the integer type
NUMBER, VECTOR may contain at a maximum MAX reals, and at a minimum 0
real.

> **type** VECTOR **is array**(NUMBER **range \<\>**) **of** REAL;\
> **type** MATRIX **is array**(NUMBER **range \<\>**, NUMBER **range
> \<\>**) **of** REAL;\
> *\-- NUMBER is an integer type defined in 3.2.1.3 as:\
> \-- type NUMBER is range 0 .. MAX;\
> \-- REAL is a real type defined in 3.2.1.4 as:\
> \-- type REAL is digits 15;*

Example 3-7: Unconstrained Array Type Definitions 37

The actual number of elements must be specified every time an
unconstrained array type is used, while the number of elements must not
be specified when a constrained array type is used (because this number
is already fixed by the type definition).

As an example, MATRIX(1 .. 512, 1 .. 512) designates a matrix which
contains 512\*512 elements.

If the lower bound of an index range is greater than the upper bound
(i.e., if the index range is zero), then the corresponding array
row/column has no component.

NOTE − Ways of storing arrays and, therefore, which array index varies
first are discussed in section 3.3.1.

#### Record Type

A record type is a composite type consisting of a sequence of named
components. EAST forbids identical component names in a record. This
sequence contains the declaration of each component of the record type.
Each declaration indicates the type of the component. Each component
type must have been previously defined.

The identifiers of all components of a record type must be distinct.
Figure 3-20 illustrates the syntax of a record type specification:

![](media/image22.emf)

Figure 3-20: Record Type Specification Diagram320

where a component declaration is specified as in Figure 3-21:

![](media/image23.emf)

Figure 3-21: Component Declaration Diagram321

An index constraint shall be present for an array component if the array
type identifier corresponds to an unconstrained array type. In this
case, the constraint is specified as in Figure 3-22:

![](media/image24.emf)

Figure []{#Fig_Index_Constraint .anchor}3-22: Index Constraint
Diagram322

The following example presents two record type definitions that consist
only of simple component declarations:

> **type** COMPLEX **is** **record**\
> REAL_PART: REAL;\
> IMAGINARY_PART: REAL;\
> **end record**;\
> *\-- REAL is a real type defined in 3.2.1.4 as:\
> \-- type REAL is digits 15;*\
> **type** MEASUREMENT_BLOCK **is** **record**\
> TODAY: DAY;\
> TEMPERATURE: SMALL_INTEGER;\
> VOLUME: SMALL_INTEGER;\
> FIRST_SEQUENCE_OF_MEASUREMENTS: VECTOR(1 .. 100);\
> SECOND_SEQUENCE_OF_MEASUREMENTS: VECTOR(1 ..10);\
> **end record**;\
> *\-- DAY is an enumeration type defined in 3.2.1.2 as:\
> \-- type DAY is (MON, TUE, WED, THU, FRI, SAT, SUN);\
> \-- SMALL_INTEGER is an integer type defined in 3.2.1.3 as:\
> \-- type SMALL_INTEGER is range -10 .. 10;\
> \-- VECTOR is an array type defined in 3.2.1.5 as:\
> \-- type VECTOR is array (NUMBER range \<\>) of REAL;*

Example 3-8: Record Type Definitions 38

Some records may contain components of which the size or even the
existence depends on the value of another component, called a
*discriminant*. The type of a discriminant must be discrete. Figure 3-23
illustrates the syntax of a discriminant specification.

![](media/image25.emf)

Figure 3-23: Discriminant Specification Diagram323

Figure 3-24 illustrates the syntax of a variant part, introduced by the
presence of a discriminant.

![](media/image26.emf)

Figure 3-24: Variant Part Specification Diagram324

The "when others" clause is mandatory only if all the possible values of
the discriminant are not explicitly named before, in the variant part
specification.

The following example presents a discriminant that conditions the
existence of other components:

> **type** ACTIVITY(TODAY: DAY := MON) **is** **record**\
> **case** TODAY **is**\
> **when** SAT **\|** SUN **=\>**\
> SLEEPING: DURATION_IN_HOURS;\
> PLAYING_TENNIS: DURATION_IN_HOURS;\
> SWIMMING: DURATION_IN_HOURS;\
> **when** MON **=\>**\
> RESTING_AFTER_WEEK_END: DURATION_IN_HOURS;\
> **when others =\>**\
> WORKING: DURATION_IN_HOURS;\
> **end case;**\
> **end record;**\
> *\-- DAY is an enumeration type defined in 3.2.1.2 as:\
> \-- type DAY is (MON, TUE, WED, THU, FRI, SAT, SUN);\
> \-- DURATION_IN_HOURS is an integer type defined as:\
> \-- type DURATION_IN_HOURS is range 0 .. 24;*

Example 3-9: Record Type Definition with Discriminant 39

In this example, TODAY is a discriminant for the type ACTIVITY: other
components of the record might change depending on the value of TODAY.

The keyword *case* introduces the variant part, which consists of
alternative lists of components. The keyword *when*, followed by one or
more values (separated by a vertical bar) of the type of the
discriminant of the variant part, introduces a list of components that
are present for the specified value(s) of the discriminant. The keyword
*others* represents all the possible values of the type of the
discriminant that have not been taken into account explicitly before (in
this example, others is equivalent to TUE \| WED \| THU \| FRI).

The following example presents a discriminant that conditions a size:

> **type** SQUARE(LENGTH: NUMBER := 10) **is** **record**\
> MAT: MATRIX(1 .. LENGTH, 1 .. LENGTH);\
> **end record**;\
> *\-- NUMBER is an integer type defined in 3.2.1.3 as:\
> \-- type NUMBER is range 0 .. MAX;\
> \-- MATRIX is an array type defined in 3.2.1.5 as:\
> \-- type MATRIX is array (NUMBER range \<\> , NUMBER range \<\>) of
> REAL;*

Example 3-10: Record Type Definition with Discriminant 310

In the previous example, LENGTH is a discriminant for the type SQUARE:
the value of LENGTH determines the size of the matrix. If LENGTH is less
than 1 (i.e., LENGTH is equal to 0), then the matrix has no element. If
LENGTH is, for example, equal to 5, then the matrix has 25 elements.

The EAST syntax requires a default value for each discriminant (if any)
in a record type declaration. A default value does not preclude any
possible value for the discriminant of corresponding record objects. In
the case of the type "SQUARE", the default value could have been any
allowed value for the integer type "NUMBER", i.e., in the range 0 ..
MAX.

Some records may contain components of which the size or the existence
depend on the value of a data item that is not part of the record: this
data item is considered to be a discriminant for the record, except that
the occurrence of this discriminant is not in the record itself. Such a
discriminant is called a *virtual discriminant*.

The syntax of a virtual discriminant is the same as a "classic"
discriminant (see Figure 3-23). The only difference is that the
discriminant identifier begins in this case with "VIRTUAL\_" and does
not represent any data item occurrence.

Figure 3-25 presents an example of virtual discriminant use; it
describes a packet format.

![](media/image27.emf)

Figure 3-25: Discriminants in a Packet Format325

This tree structure can be described using EAST type definitions as
follows:

> \-- basic data types used in the first branch**\
> type** VERSION **is** (VERSION_1, VERSION_2);\
> \
> **type** PACKET_TYPE **is** (TELEMETRY , TELECOMMAND);\
> \
> **type** PRESENCE_FLAG **is** (ABSENT , PRESENT);\
> \
> **type** PROCESS_IDENTIFICATION **is** (WORKING , IDLE);**\
> \
> **\-- structuring type for the Packet Identification**\
> type** PACKET_IDENTIFICATION_TYPE **is** **record**\
> VERSION_NUMBER: VERSION;\
> TYPE_ID: PACKET_TYPE;\
> SECONDARY_HEADER_FLAG: PRESENCE_FLAG;\
> APPLICATION_PROCESS_ID: PROCESS_IDENTIFICATION;\
> **end record;**\
> \
> \-- basic data types used in the second branch**\
> type** STATUS **is** (CONTINUATION_SEGMENT,\
> FIRST_SEGMENT, LAST_SEGMENT, UNSEGMENTED_PACKET);\
> \
> **type** COUNTER **is range** 0 .. 16383;\
> \
> \-- structuring type for the Packet Sequence Control\
> **type** PACKET_SEQUENCE_CONTROL_TYPE **is record**\
> SEGMENTATION_FLAG: STATUS;\
> SOURCE_SEQUENCE_COUNT: COUNTER;\
> **end record;**\
> \
> \-- basic data types used in the other branches\
> **type** NUMBER **is range** 0 .. 65535;\
> \
> **type** OCTET **is range** 0 .. 255;
>
> \.../\...
>
> \.../\...
>
> \-- structuring types\
> **type** DATA_ARRAY **is array** (NUMBER **range \<\>**) **of**
> OCTET;\
> **type** SECONDARY_HEADER_TYPE **is array** (1 .. 4) **of** OCTET;\
> \
> **type** PRIMARY_HEADER_TYPE **is** **record**\
> PACKET_IDENTIFICATION: PACKET_IDENTIFICATION_TYPE;\
> PACKET_SEQUENCE_CONTROL: PACKET_SEQUENCE_CONTROL_TYPE;\
> SOURCE_DATA_LENGTH: NUMBER;\
> **end record;**\
> \
> **type** PACKET_FORMAT_TYPE(\
> *VIRTUAL\_*SECONDARY_HEADER_FLAG: PRESENCE_FLAG := PRESENT;\
> \-- point to the secondary header flag located in the first branch\
> *VIRTUAL\_*SOURCE_DATA_LENGTH: NUMBER := 256)\
> \-- point to the source data length located in the third branch\
> **is record**\
> PRIMARY_HEADER: PRIMARY_HEADER_TYPE;\
> **case** *VIRTUAL\_*SECONDARY_HEADER_FLAG **is**\
> **when** ABSENT =\>\
> SOURCE_DATA_0: DATA_ARRAY (1 .. *VIRTUAL\_*SOURCE_DATA_LENGTH);\
> **when** PRESENT =\>\
> SECONDARY_HEADER: SECONDARY_HEADER_TYPE;\
> SOURCE_DATA_1: DATA_ARRAY (1 .. *VIRTUAL\_*SOURCE_DATA_LENGTH);\
> **end case;**\
> **end record;**

Example 3-11: Logical Description of the Packet Format 311

The two virtual discriminants "VIRTUAL_SECONDARY_HEADER_FLAG" and
"VIRTUAL_SOURCE_DATA_LENGTH" do not really exist in the exchanged data
block. They serve as a link between other data:

− VIRTUAL_SECONDARY_HEADER_FLAG is supposed to have the value of the
SECONDARY_HEADER_FLAG field in the PACKET IDENTIFICATION block; it
conditions the existence of the SECONDARY_HEADER block. It serves as a
link between these two fields.

− VIRTUAL_SOURCE_DATA_LENGTH is supposed to have the value of the
SOURCE_DATA_LENGTH field in the PRIMARY HEADER; it conditions the size
of the SOURCE DATA block. It also serves as a link.

#### Type Summary

The following diagram presents the types that can be found in the
logical part of an EAST description:

![](media/image28.emf)

Figure 3-26: Type Summary326

Scalar types have a binary coding or an ASCII coding, according to their
physical description (see 3.3.3).

A variant record is a record that contains at least one discriminant. An
invariant record contains no discriminant.

### SUBTYPE DECLARATIONS

A subtype of a given type is used to restrict the set of values of the
initial type. The initial type must be known at the subtype declaration
time: either it is a predefined type of the EAST language or it has been
previously declared.

Figure 3-27 illustrates the syntax of a subtype declaration.

![](media/image29.emf)

Figure 3-27: Subtype Declaration Diagram327

The constraint for an enumeration subtype is defined in Figure 3-28.

![](media/image30.emf)

Figure 3-28: Enumeration Constraint Diagram 328

If a character literal used as range bound is not a printable character
(as defined in annex ), its constant identifier is used (constants of
the type CHARACTER are defined in annex in a table called ASCII).

The constant identifier for a character must be prefixed by "ASCII.", in
order to avoid any confusion with other identifiers defined in the
current description.

The following example defines some subtypes of CHARACTER:

**subtype** CAPITAL_LETTER **is** CHARACTER **range** 'A' .. 'Z';\
\-- the range bounds are printable

**subtype** LINE_FORMAT **is** CHARACTER **range** ASCII.HT ..
ASCII.CR;\
\-- the range bounds are not printable

Example 3-12: Character Declarations 312

The constants of the type CHARACTER, which are specified in the ASCII
table, are EAST predefined constants.

The constraint for an integer subtype is defined in Figure 3-29.

![](media/image31.emf)

Figure 3-29: Integer Constraint Diagram329

In the previous diagram, the first integer gives the lower bound and the
second the upper bound of the specified range.

The constraint for a real subtype is defined in Figure 3-30.

![](media/image32.emf)

Figure 3-30: Real Constraint Diagram330

In the previous diagram, the first real gives the lower bound and the
second the upper bound of the specified range.

The constraint for an array subtype or for a subtype of the predefined
type STRING is defined in Figure 3-22 (on page
[15](#Fig_Index_Constraint)). In this diagram, the discrete literal in
the range specification is any integer (based or decimal integer)
literal or any enumeration literal. In the same way, the discrete
constant identifier in the range specification is any integer or
enumeration constant (see 3.2.3.2).

The following example defines some subtypes:

> **subtype** WEEK_END **is** DAY **range** SAT .. SUN **;**\
> *\-- where DAY is an enumeration type defined in 3.2.1.2 as:\
> \-- type DAY is (MON, TUE, WED, THU, FRI, SAT, SUN);*\
> **subtype** VERY_SMALL_INTEGER **is** SMALL_INTEGER **range** ‑5 ..
> 5**;**\
> *\-- where SMALL_INTEGER is an integer type defined in 3.2.1.3 as:\
> \-- type SMALL_INTEGER is range -10 .. 10;*\
> **subtype** MY_REAL **is** REAL **range** ‑9_999.999 .. 9_999.999;\
> *\-- where REAL is a real type defined in 3.2.1.4 as:\
> \-- type REAL is digits 15;*\
> **subtype** SMALL_MATRIX **is** MATRIX **(**1 **..** 10 , 1 **..**
> 10**);**\
> *\-- where MATRIX is an array type defined in 3.2.1.5 as:\
> \-- type MATRIX is array (NUMBER range \<\>, NUMBER range \<\>) of
> REAL;*\
> **subtype** NAME **is** STRING **(**1 **..** 32**);**\
> *\-- where STRING is a predefined array type (see 3.2.1.1).*

Example 3-13: Subtype Declarations 313

### OBJECT DECLARATIONS

An object is an entity that contains a value of a given type. A declared
object is called a constant if the reserved word **constant** appears in
the object declaration. An object that is not a constant is called a
variable.

#### Declaration of Variables

The declaration of a variable uses the previous type, subtype, or
constant declarations. Variables correspond to the data that are to be
exchanged. Figure 3-31 illustrates the syntax for the declaration of a
variable.

![](media/image33.emf)

Figure 3-31: Variable Declaration Diagram331

A variable declaration consists of only one identifier (the variable
identifier) followed by the identifier of the type that describes the
corresponding data.

> UPDATED_DATA: MEASUREMENT_BLOCK ;\
> *\-- MEASUREMENT_BLOCK is a record type defined in 3.2.1.6*

Example 3-14: Variable Declaration 314

#### Declaration of Constants

The declaration of a constant must include an explicit initialization,
except for the EOF Marker declaration (see 3.2.3.2.2). This declaration
guarantees that the corresponding object value cannot be modified after
initialization. Figure 3-32 illustrates the syntax of a constant
declaration.

![](media/image34.emf)

Figure 3-32: Constant Declaration Diagram332

A constant declaration consists of only one identifier (the constant
identifier) followed by the reserved word **constant**, an optional
identifier for the constant type, and the value of the constant.

> FIRST_DAY_OF_THE_WEEK: **constant** DAY **:=** MON**;**

Example 3-15: Constant Declaration 315

The value of a constant can be specified as a static expression,
combining other constant values and operators ('+', '\*', '\*\*', '-',
'/', '(' and ')').

'+' and '-' are unary or binary operators (addition and subtraction).
'\*', '/' and '\*\*' are binary operators: '\*' is the multiplication
operator, '/' is the division operator, '\*\*' is the exponentiation
operator. '(' and ')' are used to specify an explicit precedence for the
expression evaluation.

Constants may be declared either in the section for the declaration of
types or in the section for the declaration of variables (see Figure
3-13). In the first case, they contribute to data model definitions
while they represent, in the second case, some special data occurrences
called markers.

The first definition of a variable within the logical description part
delimits the two sections. Any declaration that occurs before the first
variable definition belongs to the section for the declaration of types.
Any declaration that occurs after the first variable definition
(including the first variable declaration itself) belongs to the section
for the declaration of variables.

##### Constants in the Section for the Declaration of Types

A constant that is declared in the section for the declaration of types
can be used:

− in type or subtype declarations for the specification of range bounds,

− in constant declarations for the specification of the values.

In this case, the constant is either an integer constant, a real
constant, or an enumeration constant, the end objective of the constant
being its use as a range bound.

A number declaration is a special form of a constant declaration, where
no type is specified.

> PI: **constant** := 3.14159_26536; \-- a real number\
> MAXIMUM: **constant** := 500; \-- an integer number\
> NUMBER_OF_VALUES_OF_AN_OCTET: **constant** := 2\*\*8; \-- the integer
> 256

Example 3-16: Number Declarations 316

##### Markers: Constants in the Section for the Declaration of Variables

A marker declaration is a special form of a constant declaration, where
the type of the constant is mandatory and occurs within the section for
the declaration of variables.

A marker is used to delimit the end of the repetition of an element. Its
declaration occurs after the declaration of a variable. This variable
that is declared immediately before the constant occurs an undetermined
number of times, the last instance being followed by the constant value.

A marker is a constant which should be unambiguously recognized. The
type of a marker is therefore restricted to integer type, enumeration
type, character type, or character string type.

The following example represents a set of values, the number of values
being unspecified. The end of the set occurs when the character string
"END" is encountered within the data.

> VALUE : COEFFICIENT; *\-- COEFFICIENT is a real type defined in
> 3.2.1.4 as:\
> \-- type COEFFICIENT is digits 10 range 0.0 .. 1.0;*
>
> END_OF_COEFFICIENTS : **constant** STRING := "END";

Example 3-17: Marker Declaration317

The element of a repetition delimited by a marker can only be a
variable.

The presence of the EOF marker implies that the previous element is
repeated until the File Management System returns an "end of file"
indication.

The following convention is adopted: the type of the Marker is an EAST
predefined type, called EOF. No explicit value is associated with this
constant since this value is unknown. This is the only case of a
constant declaration where the value is absent.

NOTE − The EOF marker can only be used once in an EAST description. It
is the last declaration in the logical description part.

The next example presents the description of a data file that contains a
header and *n* values (*n* being undetermined).

> HEADER : HEADER_TYPE; *\-- any record type*
>
> VALUE : COEFFICIENT; *\-- COEFFICIENT is a real type defined in
> 3.2.1.4 as:\
> \-- type COEFFICIENT is digits 10 range 0.0 .. 1.0;*
>
> END_OF_COEFFICIENTS : **constant** EOF ;

Example 3-18: EOF Marker Declaration318

### REPRESENTATION CLAUSES

Concerning the descriptive features, the representation clauses are one
of the most significant facilities offered by EAST. The representation
clauses specify the mapping between the logical types of the language
and their physical representation. EAST provides the length clauses, the
enumeration representation clauses, and the record representation
clauses.

A representation clause immediately follows the type whose storage it
describes. A representation clause is **mandatory** in a logical data
description, except for variable-sized components, for which the
representation cannot be known.

#### Length Clauses

A length clause specifies the number of bits that data of a particular
type occupy in storage. Length clauses must be provided for enumeration,
integer, and real types. Length clauses must also be provided for
composite types every time it is possible, i.e., every time the size of
the composite type (array or record) is known. In such case, this size
is the size of the whole type. Figure 3-33 illustrates the syntax of a
length clause declaration.

![](media/image35.emf)

Figure 3-33: Length Clause Specification Diagram333

The following example presents type declarations with their associated
length clauses:

> **type** VALUE **is range** 0 .. 500;\
> **for** VALUE**'size use** 16; \-- bits\
> \
> **type** COLUMN **is array**(1 .. 10) **of** VALUE;\
> **for** COLUMN**'size use** 160; \-- 10 times 16 bits

Example 3-19: Length Clause Declarations 319

If the elements of the described array are not contiguous, the unused
space between elements must be described explicitly. This results in
contiguous elements containing unused space.

The following example presents an array which contains values and spare
fields (for alignment purpose).

> **type** VALUE **is range** 0 .. 500;\
> **for** VALUE**'size use** 16; \-- bits\
> \
> **type** OCTET **is range** 0 .. 255;
>
> **for** OCTET**'size** **use** 8;
>
> **type** SPARE **is array** (1 .. 2) **of** OCTET;
>
> **for** SPARE**'size** **use** 16;\
> \
> **type** ELEMENT **is record**
>
> A_VALUE: VALUE;
>
> A_SPARE: SPARE;
>
> **end record**;
>
> **for** ELEMENT**'size** **use** 32;\
> \
> **type** COLUMN **is array**(1 .. 10) **of** ELEMENT;\
> **for** COLUMN**'size use** 320; \-- 10 times 32 bits

Example 3-20: Explicit Description of Unused Space 320

#### Enumeration Representation Clauses

An enumeration representation clause specifies the bit pattern for the
binary representation of the value associated with each literal of an
enumeration type. An enumeration representation clause is optional.

If an enumeration representation clause is provided, each literal of the
enumeration type must be provided with a unique bit pattern. The integer
values (corresponding to the given bit pattern) specified for the
enumeration type must satisfy the predefined ordering relation of the
type; i.e., they must increase.

If no enumeration representation clause is provided for a binary
enumeration type, default integer codes are presumed: the value of the
first listed enumeration literal is zero; the value for each other
enumeration literal is one more than for its predecessor in the list.

Figure 3-34 illustrates the syntax of an enumeration representation
clause declaration:

![](media/image36.emf)

Figure 3-34: Enumeration Clause Specification Diagram334

The integer value, specifying the mapping with bit pattern, can be
expressed using the binary, octal, decimal or hexadecimal notation. The
syntax for a binary, octal, or hexadecimal value is: base \# value#.

> **type** CODE **is** (ADD , SUB , MUL , LDA , STA , STZ);\
> **for** CODE **use** ( ADD =\> 2#1#, SUB =\> 2#10#,\
> MUL =\> 2#11#, LDA =\> 2#1000#,\
> STA =\> 2#11000#, STZ =\> 2#11111#);\
> \
> **type** DAY **is** (MON, TUE, WED, THU, FRI, SAT, SUN);\
> **for** DAY **use** ( MON =\> 8#1#, TUE =\> 8#2#, WED =\> 8#3#,\
> THU =\> 8#4#, FRI =\> 8#5#, SAT =\> 8#6#, SUN =\> 8#7#);\
> \
> **type** STATE **is** (OFF , ON);\
> **for** STATE **use** (OFF =\> 0 , ON =\> 1);\
> \
> **type** SYNCHRONIZATION **is** (NOMINAL_SYNCHRO , INVERSE_SYNCHRO);\
> **for** SYNCHRONIZATION **use** ( NOMINAL_SYNCHRO =\> 16#0C# ,\
> INVERSE_SYNCHRO =\> 16#F5# );

Example 3-21: Enumeration Clause Declarations 321

#### Record Representation Clauses

A record representation clause specifies the storage representation of
records, that is, the order, position, and size of record components
(including discriminants, if any).

A record representation clause occurs immediately after the record type
definition and before the record length clause (if its size is known).

A component clause specifies the storage position of a component,
relative to the beginning of the record. A component clause must be
provided every time it is possible, i.e., every time the exact location
of the component is known (e.g., it is not possible for variable-sized
components).

If component clauses are given for all components, the record
representation clause completely specifies the representation of the
record type.

If some component clauses are missing, the order of these components is
specified as in the record type definition.

The order of component clauses in a record representation clause is not
significant.

A representation clause is mandatory for a discriminant, except for
virtual discriminants which cannot have a representation clause.

There is an overlap between distinct variants. The EAST syntax requires
that a variant part is declared after the fixed part of a record. If the
variant part has a constant length, fixed components are allowed to be
physically located after the alternative components of the variant: the
actual location of the fixed components is specified using a record
representation clause.

Figure 3-35 illustrates the syntax of a component representation. The
expression after the keyword **at** indicates a relative distance to the
start of the structure. This distance is expressed in words, the length
of a word being either 16 bits or 32 bits (see page [39](#Distance) for
the declaration of the length). If distance is equal to 0, the range is
specified relatively to the beginning (i.e., location 0) of the record.
The expressions after the keyword **range** are the positions in bits
relatively to the distance.

![](media/image37.emf)

Figure 3-35: Component Representation Clause Specification Diagram335

Figure 3-36 illustrates the syntax of a record representation clause.

![](media/image38.emf)

Figure 3-36: Record Representation Clause Specification Diagram336

The next four examples illustrate the use of record representation
clauses, in different cases:

− first case: everything is known (the size and the location of every
component);

− second case: the number of elements of a component is not known at
definition time, and the size and the location of this variable
component are therefore not known;

− third case: the global size of the record is known, but there are two
alternatives for the choice of the components;

− fourth case: the record contains alternatives for the choice of the
components, followed by a fixed (i.e., known) component.

Assuming the following definitions of the basic data types used in the
four examples:

> *\-- enumeration type definition***\
> type** DAY **is** (MON, TUE, WED, THU, FRI, SAT, SUN);\
> **for** DAY**'size use** 8;\
> \
> *\-- integer type definitions*\
> **type** MONTH **is range** 1 .. 12;\
> **for** MONTH**'size use** 8;\
> **type** YEAR **is range** 1900 .. 2100;\
> **for** YEAR**'size use** 16;\
> **type** NUMBER **is range** 1 .. 10;\
> **for** NUMBER**'size use** 8;\
> **type** ALPHA **is range** 1 .. 10;\
> **for** ALPHA**'size use** 8;\
> **type** BETA **is range** 1 .. 10;\
> **for** BETA**'size use** 8;\
> **type** GAMMA **is range** 1 .. 10;\
> **for** GAMMA**'size use** 8;\
> **type** DELTA **is range** 1 .. 10;\
> **for** DELTA**'size use** 8;\
> \
> *\-- real type definition*\
> **type** VALUE **is digits** 5;\
> **for** VALUE**'size use** 32;**\
> \
> ***\-- array type definition*\
> **type** VECTOR **is array**(NUMBER **range \<\>**) **of** VALUE;

Example 3-22: Type Definitions 322

The following example presents the case of a complete record
representation clause. The record representation clause is provided
because the size and the location of every component of the data
structure are known.

![](media/image39.emf)

Figure 3-37: First Tree Structure 337

This tree structure is described using the following declaration:

> **type** FIRST_RECORD **is** **record**\
> THE_DAY_OF_MONTH: DAY;\
> THE_MONTH: MONTH;\
> THE_YEAR: YEAR;\
> THE_MEASUREMENT: VALUE;\
> **end record;**\
> **for** FIRST_RECORD **use** **record**\
> THE_DAY_OF_MONTH **at** 0 **range** 0 .. 7;\
> THE_MONTH **at** 0 **range** 8 .. 15;\
> THE_YEAR **at** 0 **range** 16 .. 31;\
> THE_MEASUREMENT **at** 0 **range** 32 .. 63;\
> **end record**;\
> **for** FIRST_RECORD**'size use** 64; ‑‑ 64 bits

Example 3-23: Complete Record Representation Clause Declaration 323

The following example presents the case of an incomplete record
representation clause.

![](media/image40.emf)

Figure 3-38: Second Tree Structure 338

The number of measurements is not known at definition time. The size of
the vector of measurements is therefore not provided. The tree structure
is described using the following declarations:

> **type** SECOND_RECORD(THE_NUMBER: NUMBER := 1) **is** **record**\
> THE_YEAR: YEAR;\
> THE_MEASUREMENT: VECTOR(1 .. THE_NUMBER);\
> THE_MONTH: MONTH;\
> THE_DAY_OF_MONTH: DAY;\
> **end record;**\
> **for** SECOND_RECORD **use** **record**\
> THE_NUMBER **at** 0 **range** 0 .. 7;\
> THE_YEAR **at** 0 **range** 8 .. 23;\
> \-- no component clause for the_measurement,\
> \-- for the_month nor for the_day_of_month\
> **end record**;\
> \-- no length clause for SECOND_RECORD type

Example 3-24: Incomplete Record Representation Clause Declaration 324

In this example, the length of "the_measurement" depends on the value of
the discriminant "the_number". No representation clause can be given for
it. Nevertheless the size is determined by the expression "the_number
times 32", 32 being the size of the basic element VALUE. The component
"the_measurement" begins at bit 24. The length of "the_month" is known
but its location is not known at definition time. No representation
clause can be given for it. The component "the_month" begins after the
end of "the_measurement". In the same way, the length of
"the_day_of_month" is known, but its location is not known at definition
time. No representation clause can be given for it. The component
"the_DAY_OF_month" begins after the end of "the_month".

The following example gives the case of a complete record representation
clause, where some components overlap:

![](media/image41.emf)

Figure 3-39: Third Tree Structure 339

The size of the record is known at definition time: all the alternatives
have the same length (32 bits if THE_DAY_OF_MONTH is equal MON, and 4\*8
bits if THE_DAY_OF_MONTH is equal something else). The location of every
component is known.

> **type** THIRD_RECORD(THE_DAY_OF_MONTH: DAY := MON) **is** **record**\
> THE_MONTH: MONTH;\
> THE_YEAR: YEAR;\
> **case** THE_DAY_OF_MONTH **is**\
> **when** MON **=\>**\
> THE_MEASUREMENT: VALUE; ‑‑ 32 bits\
> **when others =\>**\
> THE_ALPHA_VALUE: ALPHA; ‑‑ 8 bits\
> THE_BETA_VALUE: BETA; \-- 8 bits\
> THE_GAMMA_VALUE: GAMMA; \-- 8 bits\
> THE_DELTA_VALUE: DELTA; \-- 8 bits\
> **end case;**\
> **end record;\
> for** THIRD_RECORD **use** **record**\
> THE_DAY_OF_MONTH **at** 0 **range** 0 .. 7;\
> THE_MONTH **at** 0 **range** 8 .. 15;\
> THE_YEAR **at** 0 **range** 16 .. 31;\
> THE_MEASUREMENT **at** 0 **range** 32 .. 63;\
> THE_ALPHA_VALUE **at** 0 **range** 32 .. 39;\
> THE_BETA_VALUE **at** 0 **range** 40 .. 47;\
> THE_GAMMA_VALUE **at** 0 **range** 48 .. 55;\
> THE_DELTA_VALUE **at** 0 **range** 56 .. 63;\
> **end record;**\
> **for** THIRD_RECORD**'size use** 64; ‑‑ 64 bits

Example 3-25: Complete Record Representation Clause Declaration 325

NOTE − The components "THE_MEASUREMENT" and "THE_ALPHA_VALUE" cannot
appear in the same record, so their storage locations can overlap.

The following example presents the case of a complete representation
clause, where components and associated representation clauses are not
declared in the same order:

![](media/image42.emf)

Figure 3-40: Fourth Tree Structure 340

The size of the record is known at definition time. The variant part has
a constant length (32 bits). A fixed component is located after the
variant part.

> **type** FOURTH_RECORD (THE_DAY_OF_MONTH: DAY := MON) **is**
> **record**\
> THE_MONTH: MONTH;\
> THE_YEAR: YEAR;\
> **case** THE_DAY_OF_MONTH **is**\
> **when** MON **=\>**\
> THE_MEASUREMENT: VALUE; \-- 32 bits\
> **when others =\>**\
> THE_ALPHA_VALUE: ALPHA; \-- 8 bits\
> THE_BETA_VALUE: BETA; \-- 8 bits\
> THE_GAMMA_VALUE: GAMMA; \-- 8 bits\
> THE_DELTA_VALUE: DELTA; \-- 8 bits\
> **end case;**\
> **end record;\
> for** FOURTH_RECORD **use** **record**\
> THE_DAY_OF_MONTH **at** 0 **range** 0 .. 7;\
> THE_MONTH **at** 0 **range** 8 .. 15;\
> THE_MEASUREMENT **at** 0 **range** 16 .. 47;\
> THE_ALPHA_VALUE **at** 0 **range** 16 .. 23;\
> THE_BETA_VALUE **at** 0 **range** 24 .. 31;\
> THE_GAMMA_VALUE **at** 0 **range** 32 .. 39;\
> THE_DELTA_VALUE **at** 0 **range** 40 .. 47;\
> THE_YEAR **at** 0 **range** 48 .. 63;\
> **end record;**\
> **for** FOURTH_RECORD**'size use** 64; \-- 64 bits

Example 3-26: Complete Record Representation Clause Declaration 326

The data item of the type YEAR is declared before the variant part in
the record type declaration, but after the variant part in the record
representation clause declaration.

The four previous examples are an illustration of the following rules:

1 The reasons for not providing a component representation clause are:
the component has a variable size or it follows a component that has no
component representation clause.

2 When no representation clause can be given for a component, its
location is supposed to be contiguous to the previous component.

3 A fixed component is allowed after the variant part if that part has a
constant length, i.e., if the location of the fixed component can be
stated using a component representation clause.

The storage location of a component, relative to the start of the
record, has been expressed until now in bits in the examples (the
distance has been set to 0). For large structures, the values of
expressions given after the reserved word **range** can be huge.

The EAST syntax also allows one to express the relative position of a
component in distance to which a number of bits is added. For that
purpose, EAST allows two units for the []{#Distance .anchor}distance:
WORD_16_BITS and WORD_32_BITS, representing respectively a 16-bit word
and a 32-bit word.

WORD_16_BITS and WORD_32_BITS are two EAST predefined identifiers.

Distances are expressed in multiples of the selected unit as follows:

![](media/image43.emf)

Figure 3-41: Distance Specification Diagram341

NOTE − The integer decimal literal is the value of the distance
expressed in the selected unit, either word_32_bits or word_16_bits.

See below for the previous record representation clause written using
the constant WORD_32_BITS:

> **for** THIRD_RECORD **use** **record**\
> THE_DAY_OF_MONTH **at** 0 \* WORD_32_BITS **range** 0 .. 7;\
> THE_MONTH **at** 0 \* WORD_32_BITS **range** 8 .. 15;\
> THE_YEAR **at** 0 \* WORD_32_BITS **range** 16 .. 31;\
> THE_MEASUREMENT **at** 1 \* WORD_32_BITS **range** 0 .. 31;\
> THE_ALPHA_VALUE **at** 1 \* WORD_32_BITS **range** 0 .. 7;\
> THE_BETA_VALUE **at** 1 \* WORD_32_BITS **range** 8 .. 15;\
> THE_GAMMA_VALUE **at** 1 \* WORD_32_BITS **range** 16 .. 23;\
> THE_DELTA_VALUE **at** 1 \* WORD_32_BITS **range** 24 .. 31;\
> **end record;**

Example 3-27: Record Representation Clause Using WORD_32_BITS 327

## PHYSICAL DESCRIPTION

The physical description part adds implementation information to the
logical part. While the logical part of the DDR describes the meaning of
the exchanged data, the physical part describes how the data are
physically implemented on the medium.

The machine-dependent characteristics include:

− the representation of numerics;

− the way of storing arrays on the medium;

− the way of storing octets on the medium.

This physical part of the Data Description Record consists of a package.
See below the content of the physical part of a DDR.

  ------------------------- ---------------------------------------------------------------- --- --
  **package**                                                                                    
  *physical_package_name*                                                                        
  **is**                                                                                         

                            way of storing arrays (see 3.3.1)                                    

                                                                                                 

                            way of storing octets (see 3.3.2)                                    

                                                                                                 

                            actual scalar type representations (see 3.3.3)                       

                                                                                                 

                            association of basic type names with their actual                    
                            representations (see 3.3.4)                                          

  **end**                                                                                        
  *physical_package_name* ;                                                                      
  ------------------------- ---------------------------------------------------------------- --- --

The name of the physical package is an identifier (see 3.1.3) and must
be different from the name of the package giving the associated logical
description.

The physical description part has to be considered to be the instance of
a template. Thus, the syntax used throughout this section is not
justified or formally defined. An extended example of the template is
provided in section 3.3.5. The next sections (3.3.1 to 3.3.4) explain
the content of the template. Each time a declaration of the template
must be used as it is, it is called "fixed part of the physical
description" as opposed to the declarations that change from a
description to another one.

Every part of the template is optional (see 3.3.5). There is no required
ordering between the different parts of the template.

### WAY OF STORING ARRAYS

An array object on a medium consists of a sequence of components. For a
multi-dimensional array, i.e., an array with more than one index range,
there are different ways to organize the sequence: either the first
index range varies first or the last index range varies first. The first
described way of storing arrays is called *first_index_first*, and the
second one is called *last_index_first*.

The way of storing arrays on the medium is described in the physical
description by using an enumeration type. See below the corresponding
declaration:

> **type** ARRAY_STORAGE_METHOD **is** ( FIRST_INDEX_FIRST,\
> LAST_INDEX_FIRST);

Fixed Part 3-1 of the Physical Description: Array Storage Method

Using this declaration, it is necessary to declare the actual way of
storing arrays, for example:

> ARRAY_STORAGE: **constant** ARRAY_STORAGE_METHOD **:=**\
> FIRST_INDEX_FIRST;

Example 3-28: Actual Array Storage Method 328

This declaration is applicable to the whole description.

By default, the array storage is FIRST_INDEX_FIRST.

### WAY OF STORING OCTETS/BITS

The way of storing octets/bits determines the location of the Most
Significant Bit (MSB) and the Least Significant Bit (LSB) of a data
element.

A machine is said to be big-endian or little-endian depending on whether
the MSB is in the lowest or highest addressed octet of the data element.

For a big-endian representation of a multi-octet data element, the MSB
is in the first transmitted octet, i.e., in the first octet on the
medium, while it is in the last transmitted octet, i.e., in the last
octet on the medium, for a little-endian representation of a multi-octet
data element.

The big-endian representation for a data element can be viewed as
storing the bits from most to LSB order, and then keeping this same
order when output to some medium.

The little-endian representation for a data element can be viewed as
storing the bits from least to MSB order, but then re-ordering the bits
(from most to least significant) within each octet when output to some
medium.

This machine-dependent characteristic is very important for a correct
interpretation of the data. Its definition is given for multi-octet data
elements, but is still applicable for every data element, whatever its
length and its position (on octet boundary or not) within the data set.

The following example presents the transmission of data elements for
both kinds of machines.

<table style="width:100%;">
<colgroup>
<col style="width: 2%" />
<col style="width: 1%" />
<col style="width: 2%" />
<col style="width: 0%" />
<col style="width: 1%" />
<col style="width: 2%" />
<col style="width: 0%" />
<col style="width: 1%" />
<col style="width: 2%" />
<col style="width: 0%" />
<col style="width: 1%" />
<col style="width: 2%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 2%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 3%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 3%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 3%" />
<col style="width: 0%" />
<col style="width: 1%" />
<col style="width: 2%" />
<col style="width: 0%" />
<col style="width: 2%" />
<col style="width: 14%" />
<col style="width: 2%" />
<col style="width: 1%" />
<col style="width: 0%" />
<col style="width: 2%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 2%" />
<col style="width: 0%" />
<col style="width: 1%" />
<col style="width: 2%" />
<col style="width: 0%" />
<col style="width: 1%" />
<col style="width: 2%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 2%" />
<col style="width: 1%" />
<col style="width: 0%" />
<col style="width: 2%" />
<col style="width: 0%" />
<col style="width: 1%" />
<col style="width: 2%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 1%" />
<col style="width: 0%" />
<col style="width: 0%" />
<col style="width: 1%" />
<col style="width: 0%" />
<col style="width: 1%" />
<col style="width: 0%" />
</colgroup>
<tbody>
<tr class="odd">
<td colspan="61">Logically we have:</td>
</tr>
<tr class="even">
<td colspan="2"></td>
<td colspan="6"><p>A</p>
<p>2 bits</p></td>
<td colspan="9"><p>B</p>
<p>3 bits</p></td>
<td colspan="28"><p>C</p>
<p>16 bits</p></td>
<td colspan="14"><p>D</p>
<p>n bits</p></td>
<td colspan="2"></td>
</tr>
<tr class="odd">
<td colspan="2"></td>
<td colspan="3">A<sub>1</sub></td>
<td colspan="3">A<sub>2</sub></td>
<td colspan="3">B<sub>1</sub></td>
<td colspan="3">B<sub>2</sub></td>
<td colspan="3">B<sub>3</sub></td>
<td colspan="3">C<sub>1</sub></td>
<td colspan="2">C<sub>2</sub></td>
<td colspan="3">C<sub>3</sub></td>
<td colspan="3">C<sub>4</sub></td>
<td colspan="4">.................................</td>
<td colspan="3">C<sub>13</sub></td>
<td colspan="3">C<sub>14</sub></td>
<td colspan="3">C<sub>15</sub></td>
<td colspan="3">C<sub>16</sub></td>
<td colspan="3">D<sub>1</sub></td>
<td colspan="3">D<sub>2</sub></td>
<td colspan="4">.........</td>
<td colspan="4">D<sub>n</sub></td>
<td colspan="3"></td>
</tr>
<tr class="even">
<td colspan="61"><p>When writing onto a medium, the machine writes the
bits of the current octet first so that the contained data element bits
are ordered from MSB to LSB while maintaining their relative bit
positions to one another.</p>
<p>Therefore, for a big-endian machine where the bits are stored MSB
first, the bit values in memory appear as follows:</p></td>
</tr>
<tr class="odd">
<td></td>
<td colspan="2">A<sub>1</sub></td>
<td colspan="3">A<sub>2</sub></td>
<td colspan="3">B<sub>1</sub></td>
<td colspan="3">B<sub>2</sub></td>
<td colspan="3">B<sub>3</sub></td>
<td colspan="4">C<sub>1</sub></td>
<td colspan="4">C<sub>2</sub></td>
<td colspan="3">C<sub>3</sub></td>
<td colspan="3">C<sub>4</sub></td>
<td colspan="2">............C<sub>11</sub>.....</td>
<td colspan="3">C<sub>13</sub></td>
<td colspan="3">C<sub>14</sub></td>
<td colspan="3">C<sub>15</sub></td>
<td colspan="3">C<sub>16</sub></td>
<td colspan="5">D<sub>1</sub></td>
<td colspan="3">D<sub>2</sub></td>
<td colspan="2">...</td>
<td colspan="4">D<sub>n</sub></td>
<td colspan="4"></td>
</tr>
<tr class="even">
<td></td>
<td colspan="2">2<sup>1</sup></td>
<td colspan="3">2<sup>0</sup></td>
<td colspan="3">2<sup>2</sup></td>
<td colspan="3">2<sup>1</sup></td>
<td colspan="3">2<sup>0</sup></td>
<td colspan="4">2<sup>15</sup></td>
<td colspan="4">2<sup>14</sup></td>
<td colspan="3">2<sup>13</sup></td>
<td colspan="3">2<sup>12</sup></td>
<td colspan="2">.............2<sup>5</sup>......</td>
<td colspan="3">2<sup>3</sup></td>
<td colspan="3">2<sup>2</sup></td>
<td colspan="3">2<sup>1</sup></td>
<td colspan="3">2<sup>0</sup></td>
<td colspan="5">2<sup>n-1</sup></td>
<td colspan="3">2<sup>n-2</sup></td>
<td colspan="2">...</td>
<td colspan="4">2<sup>0</sup></td>
<td colspan="4"></td>
</tr>
<tr class="odd">
<td></td>
<td colspan="54"></td>
<td colspan="6"></td>
</tr>
<tr class="even">
<td colspan="60"><p>The bits are transmitted towards the medium octet by
octet in the following order:</p>
<p>A<sub>1</sub> A<sub>2</sub> B<sub>1</sub> B<sub>2</sub> B<sub>3</sub>
C<sub>1</sub> C<sub>2</sub> C<sub>3</sub> then C<sub>4</sub>
C<sub>5</sub> C<sub>6</sub> ... C<sub>11</sub> then C<sub>12</sub>
C<sub>13</sub> ... D<sub>1</sub> D<sub>2</sub> D<sub>3</sub> and so
forth.</p>
<p>For a little-endian machine where the bits are stored LSB first, the
bit values in memory appear as follows:</p></td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td colspan="3">A<sub>1</sub></td>
<td colspan="3">A<sub>2</sub></td>
<td colspan="3">B<sub>1</sub></td>
<td colspan="3">B<sub>2</sub></td>
<td colspan="3">B<sub>3</sub></td>
<td colspan="2">C<sub>1</sub></td>
<td colspan="3">C<sub>2</sub></td>
<td colspan="3">C<sub>3</sub></td>
<td colspan="3">C<sub>4</sub></td>
<td colspan="3">..............C<sub>11</sub>...</td>
<td colspan="3">C<sub>13</sub></td>
<td colspan="3">C<sub>14</sub></td>
<td colspan="3">C<sub>15</sub></td>
<td colspan="3">C<sub>16</sub></td>
<td colspan="4">D<sub>1</sub></td>
<td colspan="3">D<sub>2</sub></td>
<td colspan="3">...</td>
<td colspan="4">D<sub>n</sub></td>
<td colspan="5"></td>
</tr>
<tr class="even">
<td></td>
<td colspan="3">2<sup>0</sup></td>
<td colspan="3">2<sup>1</sup></td>
<td colspan="3">2<sup>0</sup></td>
<td colspan="3">2<sup>1</sup></td>
<td colspan="3">2<sup>2</sup></td>
<td colspan="2">2<sup>0</sup></td>
<td colspan="3">2<sup>1</sup></td>
<td colspan="3">2<sup>2</sup></td>
<td colspan="3">2<sup>3</sup></td>
<td colspan="3">..............2<sup>10</sup>...</td>
<td colspan="3">2<sup>12</sup></td>
<td colspan="3">2<sup>13</sup></td>
<td colspan="3">2<sup>14</sup></td>
<td colspan="3">2<sup>15</sup></td>
<td colspan="4">2<sup>0</sup></td>
<td colspan="3">2<sup>1</sup></td>
<td colspan="3">...</td>
<td colspan="4">2<sup>n-1</sup></td>
<td colspan="5"></td>
</tr>
<tr class="odd">
<td></td>
<td colspan="55"></td>
<td colspan="5"></td>
</tr>
<tr class="even">
<td colspan="61"><p>The bits are transmitted towards the medium octet by
octet in the following order:</p>
<p>C<sub>3</sub> C<sub>2</sub> C<sub>1</sub> B<sub>3</sub> B<sub>2</sub>
B<sub>1</sub> A<sub>2</sub> A<sub>1</sub> then C<sub>11</sub>
C<sub>10</sub> C<sub>9</sub> ... C<sub>4</sub> then D<sub>3</sub>
D<sub>2</sub> D<sub>1</sub> C<sub>16 ...</sub> C<sub>12</sub> and so
forth.</p></td>
</tr>
</tbody>
</table>

Example 3-29: Octet Storage Possibilities329

See below the corresponding declaration:

> **type** BIT_ORDER **is** ( HIGH_ORDER_FIRST, \-- big-endian
> representation\
> LOW_ORDER_FIRST); \-- little-endian representation

Fixed Part 3-2 of the Physical Description: Bit Order

Using this declaration, it is necessary to declare the actual way of
storing octets, for example:

> OCTET_STORAGE: **constant** BIT_ORDER **:=** HIGH_ORDER_FIRST;

Example 3-30: Actual Bit Order 330

This declaration is applicable to the whole description.

The description of the way of storing octets (using the type BIT_ORDER)
is sufficient to fully describe the organization on the medium (even at
a bit level).

By default, the octet storage is HIGH_ORDER_FIRST.

### REPRESENTATION OF SCALAR TYPES

Scalar types can be either binary encoded or ASCII encoded.

#### Binary Representation of Scalar Types

The way to determine the value of a numeric (integer or real), i.e., how
to interpret its bit pattern on the medium, depends on its binary
representation.

The binary representation of a numeric indicates its bit pattern on the
medium. It includes the physical characteristics that may differ
depending on the machine that has generated the numeric.

No binary representation is provided for enumeration types, because they
are mapped on integers, for which the location of the bits from the MSB
to the LSB are deduced from another physical information item, called
bit order (see 3.3.2). If necessary, negative values are represented in
a two's complement form.

If a negative value is present in the enumeration list, then the sign
bit is present in any data occurrence of the enumeration type. If the
sign bit is set, the two's complement shall be used to decode the
integer value.

If all enumeration values are positive integers, then there is no sign
bit and any data occurrence of the enumeration must be considered to be
an unsigned integer.

The binary representation of an **integer** includes the following
characteristics:

− the sign convention, which indicates the complementation, if any;

− the bit ordering, which indicates the location of MSB to the LSB, the
sign position, if any, being the MSB.

The binary representation of a **real** includes the following
characteristics:

− the sign position;

− the sign convention, if any;

− the location of the exponent;

− the bias, which is a constant chosen to make the sum of exponent value
and bias which is a non-negative number;

− the exponent base, which is the integer (two, ten or sixteen) raised
to the exponent power in determining the value of the represented
number;

− the location of the mantissa.

It must additionally include the identifier of the convention of the
generating machine, "convention of the generating machine" being the
method to reconstitute the real values from the previously defined
characteristics. An Authority and Description Identifier (ADID) is
associated with every registered convention. See reference \[E5\] for
the list of conventions and related ADIDs.

The conventions adopted in this document for the data representation on
a medium are the following:

− In multi-octet elements, the first octet is drawn in the leftmost
position and is called "Octet Zero". Successive octets are assigned
successively larger numbers.

− Within an octet or binary field (not a multiple of octets), the first
bit is drawn in the leftmost position and is called "Bit Zero".

The following rule is applicable for a field representing an integer, an
exponent or a mantissa of a real: the bits of the field are not
necessarily provided in the right order (MSB to LSB) on the medium. The
aim is to reconstitute the proper bit ordering (MSB to LSB). To achieve
that, the initial field might be divided into an ordered sequence of
subfields for which the bit ordering is respected in each of them. The
order of the subfields provides the order of bits from the MSB to the
LSB of the whole field.

  -------------------- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
  Bit number           0     1     2     3     4     5     6     7     8     9

                                                                             

  Significance         26    25    24    23    22    29    28    27    21    20
  -------------------- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----

> The bit ordering for this field from the MSB to LSB is:
> 5-6-7-0-1-2-3-4-8-9. This can be summarized using the previous rule in
> 3 subfields according to the bit numbers in the following order: (5 ,
> 7) - (0 , 4) - (8 , 9).

Example 3-31: Bit Ordering 331

Using the previous conventions and rules, the binary representation of
numerics is described in the corresponding physical description part. It
contains:

− a fixed part declaring the types used to describe the representations
(INTEGER_PHYSICAL_DESCRIPTION and REAL_PHYSICAL_DESCRIPTION), this part
being always the same and present in any physical description part;

− a part declaring the actual representations used, i.e., a specific
part, depending on the nature of the numerics to be described.

> **type** NATURAL_NUMBER **is range** 0 .. 65535**;**\
> \
> **type** LOCATION_OF_SUBFIELD **is** \-- subfields composing an
> integer or the **\
> record** \-- exponent/mantissa of a real.\
> BEGINNING_AT_BIT_NUMBER: NATURAL_NUMBER;\
> ENDING_AT_BIT_NUMBER: NATURAL_NUMBER;\
> **end record;**\
> \
> MAXIMUM_NUMBER_OF_SUBFIELDS: **constant** := 255;\
> **type** SUBFIELD_NUMBER **is range**\
> 1 **..** MAXIMUM_NUMBER_OF_SUBFIELDS;\
> **\
> type** LOCATION_OF_FIELD **is array** (SUBFIELD_NUMBER **range \<\>**)
> **\
> of** LOCATION_OF_SUBFIELD;

Fixed Part 3-3 of the Physical Description: Location of Fields for
Numerics

NOTES

1 The MAXIMUM_NUMBER_OF_SUBFIELDS is set to 255. It is an arbitrary
value that is big enough to cover all the identified machine
architectures (i.e., the number of subfields that are necessary to
locate the bits of an integer can be up to 255).

2 The upper bound of NATURAL_NUMBER is set to 65535. It is an arbitrary
value that seems to be large enough in this context.

> **type** SIGN_CONVENTION **is** (UNSIGNED, SIGN_AND_MAGNITUDE,\
> ONES_COMPLEMENT, TWOS_COMPLEMENT);\
> \
> **type** LIST_OF_RECOGNIZED_CONVENTIONS **is** (FCSTC000, FCSTC001,\
> FCSTC0002, FCSTC0003); \-- this list is not exhaustive (see reference
> \[E5\])\
> \
> **type** INTEGER_PHYSICAL_DESCRIPTION (\
> number_of_subfields: SUBFIELD_NUMBER := 1) **is** **record**\
> COMPLEMENT: SIGN_CONVENTION;\
> LOCATION: LOCATION_OF_FIELD (1 .. number_of_subfields);\
> **end record;**\
> \
> **type** REAL_PHYSICAL_DESCRIPTION(\
> number_of_subfields_in_exponent: SUBFIELD_NUMBER := 1;\
> number_of_subfields_in_mantissa: SUBFIELD_NUMBER := 1)\
> **is record**\
> CONVENTION_USED: LIST_OF_RECOGNIZED_CONVENTIONS;\
> SIGN_BIT_NUMBER: NATURAL_NUMBER;\
> COMPLEMENT: SIGN_CONVENTION;\
> EXPONENT_BASE: NATURAL_NUMBER;\
> BIAS: NATURAL_NUMBER;\
> LOCATION_OF_EXPONENT: LOCATION_OF_FIELD (\
> 1 .. number_of_subfields_in_exponent);\
> LOCATION_OF_MANTISSA: LOCATION_OF_FIELD (\
> 1 .. number_of_subfields_in_mantissa);\
> **end record;**

Fixed Part 3-4 of the Physical Description: Binary Description for
Numerics

Each time the bits of an integer or the bits of the exponent or mantissa
are not contiguously located on the medium from the MSB to the LSB (see
Example 3-31), several subfields are necessary to locate the bits. In
these cases, BEGINNING_AT_BIT_NUMBER of the first element of the array
LOCATION_OF_FIELD is supposed to be the bit number of the MSB. Bit
numbers continue in sequence until ENDING_AT_BIT_NUMBER of the last
element of LOCATION_OF_FIELD, which is supposed to be the bit number of
the LSB.

The actual representation of the numerics is given by the declaration of
constants of the previous record types (INTEGER_PHYSICAL_DESCRIPTION for
the representation of integers and REAL_PHYSICAL_DESCRIPTION for the
representation of reals).

The actual representation of a numeric is therefore provided by a record
value (i.e., the value of the constant of the relevant record type:
INTEGER_PHYSICAL_DESCRIPTION or REAL_PHYSICAL_DESCRIPTION).

Figure 3-42 illustrates the syntax of a record value.

![](media/image44.emf)

Figure 3-42: Record Value Specification Diagram342

In the case of the record types used in the physical part of an EAST
description, the component value is either an enumeration literal, an
integer literal or an array value.

Figure 3-43 illustrates the syntax of an array value.

![](media/image45.emf)

Figure 3-43: Array Value Specification Diagram343

The index value is an integer literal. In the case of the array types
used in the physical part of an EAST description, the component value is
either an enumeration literal, an integer literal, an array value, or a
record value.

The following examples present real cases of two integers and a real
that must be described.

A 16-bit signed integer with the following physical representation
(big-endian representation):

  ----------------------------------- ------- ---------------------------------- -- --
  0 7                                 8 15                                          

  octet 0                             octet 1                                       

  ↓ 214                                       20                                    
  ----------------------------------- ------- ---------------------------------- -- --

Sign

− The sign position is bit 0.

− The bit ordering is (0,15), which means that the MSB is bit 1 (bit 0
being the sign bit) and the LSB is bit 15.

Example 3-32: Bit Ordering for the Above 16-Bit Signed Integer 332

Using the types declared in the fixed part of the physical description,
it is possible to declare the actual binary representation of this
integer. Assuming that for negative values the two's complement is used,
the actual binary representation is given by the following declaration:

> Binary_Representation_01: **constant** INTEGER_PHYSICAL_DESCRIPTION
> :=\
> (number_of_subfields =\> 1 ,\
> COMPLEMENT =\> TWOS_COMPLEMENT,\
> LOCATION =\> (1 =\> (0,15)));

Example 3-33: Actual Binary Representation of the Above 16-Bit Signed
Integer 333

In this example, the binary representation indicates that the sign bit
is the first bit encountered (bit 0). Then, a less significant bit is
the second bit encountered (bit 1) and so on till the sixteenth bit
(this bit being the LSB of the integer).

In the same way, a 16-bit unsigned integer with the following physical
representation (big-endian representation):

  ----------------------------------- ------- ---------------------------------- -- --
  0 7                                 8 15                                          

  octet 0                             octet 1                                       

  215                                         20                                    
  ----------------------------------- ------- ---------------------------------- -- --

− The bit ordering is (0,15), which means that the MSB is bit 0 and LSB
is bit 15.

Example 3-34: Bit Ordering for the Above 16-Bit Unsigned Integer 334

Using the types declared in the fixed part of the physical description,
it is possible to declare the actual binary representation of this
integer. The actual binary representation is given by the following
declaration:

> Binary_Representation_02: **constant** INTEGER_PHYSICAL_DESCRIPTION
> :=\
> (number_of_subfields =\> 1 ,\
> COMPLEMENT =\> UNSIGNED,\
> LOCATION =\> (1 =\> (0,15)));

Example 3-35: Actual Binary Representation of the Above 16-Bit Unsigned
Integer 335

In this example, the binary representation indicates that the most
significant is the first bit encountered (bit 0). Then, a less
significant bit is the second bit encountered (bit 1) and so on until
the sixteenth bit (this bit being the LSB of the integer).

If the range that is specified in the integer type definition (in the
logical part of the EAST description) allows negative values, then there
is a sign bit, and the SIGN_CONVENTION cannot be UNSIGNED. If this range
specifies only positive values, then there can be a sign bit (or not)
according to the SIGN_CONVENTION. If there is no sign bit, the first bit
number of the first subfield really corresponds to the MSB.

A 32-bit real with the following physical representation (little-endian
representation):

  ----------------- ----------------- ------------------ ------------------
  0 7               8 15              16 23              24 31

  octet 0           octet 1           octet 2            octet 3

  ← Mantissa →      ← Mantissa →      ↓ ← Mantissa →\    ↓ ← Exponent →\
                                      Exponent           Sign
  ----------------- ----------------- ------------------ ------------------

− The sign position is bit 24.

− The location of the exponent includes two subfields (25,31) and
(16,16), which means that the MSB of the exponent is bit 25 and the LSB
is bit 16.

− The location of the mantissa includes three subfields (17,23), (8,15)
and (0,7), which means that the MSB of the mantissa is bit 17 and the
LSB is bit 7.

Example 3-36: Bit Ordering for the Above 32-Bit Real 336

Using the types declared in the fixed part of the physical description,
it is possible to declare the actual binary representation of this real.
Assuming that the real is generated on a PC (which uses the IEEE 754
convention, identified by FCSTC000, see reference\[E5\]), the actual
binary representation is given by the following declaration:

> Binary_Representation_03: **constant** REAL_PHYSICAL_DESCRIPTION :=\
> (number_of_subfields_in_exponent =\> 2,\
> number_of_subfields_in_mantissa =\> 3,\
> CONVENTION_USED =\> FCSTC000, \-- IEEE 754\
> SIGN_BIT_NUMBER =\> 24,\
> COMPLEMENT =\> SIGN_AND_MAGNITUDE,\
> EXPONENT_BASE =\> 2,\
> BIAS =\> 127,\
> LOCATION_OF_EXPONENT =\> ( 1 =\> (25,31),\
> 2 =\> (16,16)),\
> LOCATION_OF_MANTISSA =\> ( 1 =\> (17,23),\
> 2 =\> (8,15),\
> 3 =\> (0,7)));

Example 3-37: Actual Binary Representation of a 32-Bit Real 337

In this example, the binary representation indicates that the most
significant bit of the exponent is the twenty-sixth bit encountered (bit
25). Then from bit 26 through bit 31 the bits encountered are less
significant, and bit 16 is the LSB of the exponent.

In the same way, the most significant bit of the mantissa is the
eighteenth bit encountered (bit 17). Then from bit 18 through bit 23,
and then from bit 8 through bit 15, and from bit 0 through bit 7, the
bits encountered are less significant, bit 7 being the LSB of the
mantissa.

NOTE − The name of the constant used to identify the binary
representation (Binary_Representation_01 or Binary_Representation_02)
could be any identifier (except a reserved keyword). The only
restriction is that a constant identifier cannot be defined twice in the
physical part.

Reference \[E5\] provides the way of calculating real values for the
conventions, mentioned in the definition of
LIST_OF_RECOGNIZED_CONVENTIONS.

#### ASCII Representation of Scalar Types

ASCII encoded types are sometimes used to increase the portability of
the data. Enumeration types, integer types, and real types can be
encoded using character strings. An ASCII encoded type is a character
string type with a specific format, depending on the nature of the type
(enumeration, integer, or real).

There is no difference (except the size) between the logical description
of a binary type and the logical description of an ASCII encoded type.
The physical description specifies the actual representation of the
scalar types. By default, a type is a binary encoded type. An ASCII
representation must be associated with the type name, if the type is
ASCII encoded.

The ASCII representation of an **enumeration** type provides all the
character strings associated with all the enumeration literals of the
type. The character strings, which are the coding values of the
enumeration type, have all the same length (NUMBER_OF_CHARACTERS). The
set of the coding values is therefore represented by a character string
list, which is also an array of characters, dimensioned by the
NUMBER_OF_OCCURRENCES of the enumeration type and the
NUMBER_OF_CHARACTERS of every occurrence.

The ASCII representation of an enumeration uses the following types:

> **type** STRING_LIST **is array**( NATURAL_NUMBER **range \<\>**,\
> NATURAL_NUMBER **range \<\>**) **of** CHARACTER;
>
> **type** ASCII_ENUMERATION_PHYSICAL_DESCRIPTION (\
> NUMBER_OF_OCCURRENCES: NATURAL_NUMBER := 0;\
> NUMBER_OF_CHARACTERS: NATURAL_NUMBER := 0) **is record**\
> REPRESENTATION: STRING_LIST ( 1 .. NUMBER_OF_OCCURRENCES,\
> 1 .. NUMBER_OF_CHARACTERS);
>
> **end record;**

Fixed Part 3-5 of the Physical Description: ASCII Description for
Enumeration Types

The number of characters used to encode the enumeration type must be the
same for every enumeration literal of the type. This number is known at
definition time.

All characters (i.e., the 256 characters of the Latin Alphabet No.
1.---see reference \[1\] and/or annex ) are allowed and are significant,
including the space character.

The physical representations of the enumeration literals are provided in
the order of their declaration in the logical part.

An enumeration type is either an ASCII encoded type (in this case, its
ASCII representation shall be present in the physical description part)
or a binary encoded type (in this case, an enumeration representation
clause can be present in the logical description part). In any case,
enumeration representation clause and ASCII representation are
exclusive: they must not be associated with the same enumeration type.

Using the types declared in the fixed part of the physical description,
it is possible to declare the actual ASCII representation of the
enumeration types.

For example, an enumeration type which has two permitted values:
"WORKING" and "IDLE", identifying a process, can be described in the
logical part as follows:

**type** PROCESS_IDENTIFICATION **is** (WORKING, IDLE);\
**for** PROCESS_IDENTIFICATION**'size use** 56; \-- bits, i.e., 7
characters

Example 3-38: ASCII Enumeration Type Logical Declaration338

and in the physical part as follows:

ASCII_Rep_01: **constant** ASCII_ENUMERATION_PHYSICAL_DESCRIPTION :=\
(NUMBER_OF_OCCURRENCES =\> 2, NUMBER_OF_CHARACTERS =\> 7,\
REPRESENTATION =\> ("WORKING" , "IDLE "));

Example 3-39: ASCII Enumeration Type Physical Description339

In this example, three space characters belong to the representation of
the enumeration value IDLE.

An ASCII Encoded Decimal Integer is a character string representing an
integer value. The format of the character string corresponding to an
ASCII encoded decimal integer is described in the Figure 3-44:

![](media/image46.emf)

Figure 3-44: ASCII Encoded Decimal Integer Format344

An ASCII Encoded Decimal Real is a string representing a real value. The
format of the character string corresponding to an ASCII encoded decimal
real is described in the Figure 3-45:

![](media/image47.emf)

Figure 3‑45: ASCII Encoded Decimal Real Format345

A digit is one of the following characters: '0', '1', '2', '3', '4',
'5', '6', '7', '8', '9'.

Only the normalized ASCII encoded numbers can be described using EAST.
There is no convention for the ASCII representation of infinite values
("+INF", "-INF" or "+ ∞", "- ∞") and no representation for "NaN" (Not a
Number).

The ASCII representation of an **integer** or **real** type specifies
the number of characters used for the integer or real values. The ASCII
representation of an integer or real uses the following type:

> **type** ASCII_NUMERIC_PHYSICAL_DESCRIPTION **is record**\
> NUMBER_OF_CHARACTERS: NATURAL_NUMBER;\
> **end record**;

Fixed Part 3-6 of the Physical Description: ASCII Description for
Numerics

Using the types declared in the fixed part of the physical description,
it is possible to declare the actual ASCII representation of the
numerics.

For example, a five-character ASCII decimal integer type can be
described in the logical part as follows:

**type** COUNTER **is range** -1 .. 16383;\
**for** COUNTER**'size use** 40; \-- bits, i.e., 5 characters

Example 3-40: ASCII Integer Type Logical Declaration340

and in the physical part as follows:

ASCII_Rep_02: **constant** ASCII_NUMERIC_PHYSICAL_DESCRIPTION :=\
(NUMBER_OF_CHARACTERS =\> 5);

Example 3-41: ASCII Integer Type Physical Description341

For example, an 11-character ASCII decimal real type can be described in
the logical part as follows:

**type** KILOMETERS **is digits** 5;\
**for** KILOMETERS**'size use** 88; \-- bits

Example 3-42: ASCII Real Type Logical Declaration342

and in the physical part as follows:

ASCII_Rep_03: **constant** ASCII_NUMERIC_PHYSICAL_DESCRIPTION :=\
(NUMBER_OF_CHARACTERS =\> 11);

Example 3-43: ASCII Real Type Physical Description343

NOTE − The name of the constant used to identify the ASCII
representation (ASCII_Rep_01 or ASCII_Rep_02 or ASCII_Rep_03) could be
any identifier (except a reserved keyword). The only restriction is that
a constant identifier cannot be defined twice in the physical part.

### RELATIONSHIP BETWEEN THE REPRESENTATION OF SCALAR TYPES AND LOGICAL TYPES

As seen in 3.3.3, a binary or ASCII representation is provided for some
basic types (enumeration, integer, or real types) defined in the logical
part of the DDR. The association of a type name with the corresponding
representation name also has to be provided in this physical description
part. See below how this association is implemented in EAST:

− an enumeration type gives all the basic type names, which are
previously defined in the logical description part and which need a
physical representation, by prefixing them with "USER_TYPE\_":

> **type** BASIC_TYPE_NAMES **is** (USER_TYPE_xxx , USER_TYPE_yyy ,\
> USER_TYPE_zzz, USER_TYPE_ttt);

− the different representations are declared as seen in 3.3.3.1 and
3.3.3.2:

> Binary_Representation_01: **constant** INTEGER_PHYSICAL_DESCRIPTION\
> := "value"; \-- integer type\
> Binary_Representation_02: **constant** REAL_PHYSICAL_DESCRIPTION\
> := "value"; \-- real type\
> ASCII_Representation_01: **constant\
> **ASCII_NUMERIC_PHYSICAL_DESCRIPTION\
> := "value"; \-- integer or real type\
> ASCII_Representation_02: **constant\
> **ASCII_ENUMERATION_PHYSICAL_DESCRIPTION\
> := "value"; \-- enumeration type\
> \... and so forth \...

− finally, the relation between the type names and their binary
representations is specified as follows:

> **type** RELATION(choice: BASIC_TYPE_NAMES) **is** **record**\
> **case** choice **is**\
> **when** USER_TYPE_xxx **=\>**\
> PHYS_xxx: INTEGER_PHYSICAL_DESCRIPTION\
> := Binary_Representation_01;\
> **when** USER_TYPE_yyy **=\>**\
> PHYS_yyy: REAL_PHYSICAL_DESCRIPTION\
> := Binary_Representation_02;\
> **when** USER_TYPE_zzz **=\>**\
> PHYS_zzz: ASCII_NUMERIC_PHYSICAL_DESCRIPTION\
> := ASCII_Representation_01;\
> **when** USER_TYPE_ttt **=\>**\
> PHYS_ttt: ASCII_ENUMERATION_PHYSICAL_DESCRIPTION\
> := ASCII_Representation_02;\
> and so forth \...**\
> end case;\
> end record;**

### TEMPLATE OF A PHYSICAL DESCRIPTION PART

This subsection gives an extended template for the physical description
part definition. The italicized part corresponds to the variable part of
the description, i.e., what changes from a physical part to another
physical part.

package *physical_package_name* is\
\
type ARRAY_STORAGE_METHOD is ( FIRST_INDEX_FIRST,\
LAST_INDEX_FIRST);\
ARRAY_STORAGE: constant ARRAY_STORAGE_METHOD :=\
*FIRST_INDEX_FIRST*;\
\
type BIT_ORDER is ( HIGH_ORDER_FIRST, \-- big-endian representation\
LOW_ORDER_FIRST); \-- little-endian representation\
OCTET_STORAGE: constant BIT_ORDER := *HIGH_ORDER_FIRST*;\
\
type LOCATION_OF_SUBFIELD is \-- subfields composing an integer or the\
record \-- exponent/mantissa of a real.\
BEGINNING_AT_BIT_NUMBER: NATURAL_NUMBER;\
ENDING_AT_BIT_NUMBER: NATURAL_NUMBER;\
end record;\
\
MAXIMUM_NUMBER_OF_SUBFIELDS: constant := 255;\
type SUBFIELD_NUMBER is range\
1 .. MAXIMUM_NUMBER_OF_SUBFIELDS;\
\
type LOCATION_OF_FIELD is array (SUBFIELD_NUMBER range \<\>)\
of LOCATION_OF_SUBFIELD;\
\
type SIGN_CONVENTION is (UNSIGNED, SIGN_AND_MAGNITUDE,\
ONES_COMPLEMENT, TWOS_COMPLEMENT);\
\
type LIST_OF_RECOGNIZED_CONVENTIONS is (*FCSTC000*);\
\
type INTEGER_PHYSICAL_DESCRIPTION (\
number_of_subfields: SUBFIELD_NUMBER := 1) is record\
COMPLEMENT: SIGN_CONVENTION;\
LOCATION: LOCATION_OF_FIELD (1 .. number_of_subfields);\
end record;

type REAL_PHYSICAL_DESCRIPTION(\
number_of_subfields_in_exponent: SUBFIELD_NUMBER := 1;\
number_of_subfields_in_mantissa: SUBFIELD_NUMBER := 1)\
is record\
CONVENTION_USED: LIST_OF_RECOGNIZED_CONVENTIONS;\
SIGN_BIT_NUMBER: NATURAL_NUMBER;\
COMPLEMENT: SIGN_CONVENTION;\
EXPONENT_BASE: NATURAL_NUMBER;\
BIAS: NATURAL_NUMBER;\
LOCATION_OF_EXPONENT: LOCATION_OF_FIELD (\
1 .. number_of_subfields_in_exponent);\
LOCATION_OF_MANTISSA: LOCATION_OF_FIELD (\
1 .. number_of_subfields_in_mantissa);\
end record;\
\
type STRING_LIST is array( NATURAL_NUMBER range \<\>,\
NATURAL_NUMBER range \<\>) of CHARACTER;\
type ASCII_ENUMERATION_PHYSICAL_DESCRIPTION (\
NUMBER_OF_OCCURRENCES: NATURAL_NUMBER := 0;\
NUMBER_OF_CHARACTERS: NATURAL_NUMBER := 0) is record\
REPRESENTATION: STRING_LIST ( 1 .. NUMBER_OF_OCCURRENCES,\
1 .. NUMBER_OF_CHARACTERS);\
end record;\
\
type ASCII_NUMERIC_PHYSICAL_DESCRIPTION is record\
NUMBER_OF_CHARACTERS: NATURAL_NUMBER;\
end record;\
\
*Binary_Representation_01*: constant INTEGER_PHYSICAL_DESCRIPTION :=\
(number_of_subfields =\> *1* ,\
COMPLEMENT =\> *TWOS_COMPLEMENT*,\
LOCATION =\> *(1 =\> (0,15)));\
Binary_Representation_02*: constant REAL_PHYSICAL_DESCRIPTION :=\
(number_of_subfields_in_exponent =\> *1*,\
number_of_subfields_in_mantissa =\> *1*,\
CONVENTION_USED =\> *FCSTC000*,\
SIGN_BIT_NUMBER =\> *0*,\
COMPLEMENT =\> *SIGN_AND_MAGNITUDE*,\
EXPONENT_BASE =\> *2*,\
BIAS =\> *127*,\
LOCATION_OF_EXPONENT =\> *( 1 =\> (1,8),*\
LOCATION_OF_MANTISSA =\> *( 1 =\> (9,31)));\
ASCII_Rep_01*: constant ASCII_ENUMERATION_PHYSICAL_DESCRIPTION :=\
(NUMBER_OF_OCCURRENCES =\> *2*, NUMBER_OF_CHARACTERS =\> *7*,\
REPRESENTATION =\> *("WORKING" , "IDLE"));\
ASCII_Rep_02*: constant ASCII_NUMERIC_PHYSICAL_DESCRIPTION :=\
(NUMBER_OF_CHARACTERS =\> *5*);\
\
type BASIC_TYPE_NAMES is (USER_TYPE\_*xxx* , USER_TYPE\_*yyy* ,\
USER_TYPE\_*zzz ,* USER_TYPE\_*ttt*);\
\
type RELATION(choice: BASIC_TYPE_NAMES) is record\
case choice is\
when USER_TYPE\_*xxx* =\>\
PHYS\_*xxx*: INTEGER_PHYSICAL_DESCRIPTION\
:= *Binary_Representation_01*;\
when USER_TYPE\_*yyy* =\>\
PHYS\_*yyy*: REAL_PHYSICAL_DESCRIPTION\
:= *Binary_Representation_02*;\
when USER_TYPE\_*zzz* =\>\
PHYS\_*zzz*: ASCII_ENUMERATION_PHYSICAL_DESCRIPTION\
:= ASCII_Rep_01;\
PHYS\_*ttt*: ASCII_NUMERIC_PHYSICAL_DESCRIPTION\
:= ASCII_Rep_02;\
end case;\
end record;\
end *physical_package_name*;

Most of the declarations are optional. Indeed only the types that are
used must be declared. As an example, the type REAL_PHYSICAL_DESCRIPTION
must be defined only if it is used in the physical part, i.e., if at
least one real type is defined in the logical part.

The following rules apply:

1 The array storage is optional (ARRAY_STORAGE_METHOD type and
ARRAY_STORAGE constant) if there is no multi-dimensional array in the
logical part, or if the method is FIRST_INDEX_FIRST (default value).

2 The octet storage is optional (BIT_ORDER type and OCTET_STORAGE
constant) if the method is HIGH_ORDER_FIRST (default value).

3 The type REAL_PHYSICAL_DESCRIPTION is optional if there is no binary
representation for real type to provide, i.e., if there is no binary
real type in the logical part.

4 The type INTEGER_PHYSICAL_DESCRIPTION is optional if there is no
binary representation for integer type to provide, i.e., if there is no
binary integer type in the logical part or if they are all considered to
be unsigned integers or two's-complement signed integers.

5 The type ASCII_ENUMERATION_PHYSICAL_DESCRIPTION is optional if there
is no ASCII representation for enumeration type to provide, i.e., if
there is no ASCII enumeration type in the logical part.

6 The type ASCII_NUMERIC_PHYSICAL_DESCRIPTION is optional if there is no
ASCII representation for integer or real type to provide, i.e., if there
is no ASCII integer type and no ASCII real type in the logical part.

7 The types BASIC_TYPE_NAMES and RELATION are optional if there is no
representation to provide.

# Number range chapitreRESERVED KEYWORDS

The following reserved keywords are not available for use as declared
identifiers. Some of them are reserved keywords of the Ada programming
language (see reference \[E3\]), but not of the EAST language. These
words are also reserved in order to avoid any problem in the case of an
Ada application accessing the data. Other words are reserved identifiers
of the EAST language and not of the Ada programming language.

**a) EAST and Ada Keywords**

  -------------- -------------- -------------- -------------- --------------
  array          digits         is             package        type

  at                                                          

                 end            null           range          use

  case                                         record         

  constant       for            of                            when

                                others         subtype        
  -------------- -------------- -------------- -------------- --------------

**b) Other Ada Keywords**

  -------------- -------------- -------------- -------------- --------------
  abort          delta          if             pragma         tagged

  abs            do             in             private        task

  abstract                                     procedure      terminate

  accept         else           limited        protected      then

  access         elsif          loop                          

  aliased        entry                         raise          until

  all            exception      mod            rem            

  and            exit                          renames        while

                                new            requeue        with

  begin          function       not            return         

  body                                         reverse        xor

                 generic        or                            

  declare        goto           out            select         

  delay                                        separate       
  -------------- -------------- -------------- -------------- --------------

**c) Pure EAST reserved identifiers**

  --------------- ---------------- -------------- ------------ -------------
  virtual\_\...   word_32_bits     word_16_bits                

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

NOTE − Any identifier beginning with "virtual\_" is reserved for virtual
component identifier only.

#  Number range chapitreCONFORMANCE

Data conforming to a Recommendation may be said to be in conformance at
some identified level. Identifying conformance levels provides a
standard way to classify the required capabilities of generating and
receiving systems.

The Recommendation for Data Description Language EAST Specification
recognizes only one conformance level, and that is the entire
specification. Therefore recipient systems which are said to be in
conformance to this Recommendation shall recognize the entire
specification.

# Annex A  ACRONYMS AND GLOSSARYA

(This annex **is** part of the Recommendation)

This annex defines key acronyms and the glossary of terms which are used
throughout this Recommendation to describe the Data Description Language
EAST.

**A 1 ACRONYMS**

ADID Authority and Description IDentifier\
ASCII American Standard Code for Information Interchange\
BNF Backus-Naur-Form\
DDR Data Description Record\
EAST Enhanced Ada SubseT\
ISO International Standards Organization\
LSB Least Significant Bit\
LSO Least Significant Octet\
MSB Most Significant Bit\
MSO Most Significant Octet

**A 2 GLOSSARY OF TERMS**

**ADID:** in the context of EAST, an ADID is an identifier of the EAST
Recommendation within the CCSDS organization. See reference .

**Array type:** an array type is a composite type whose components are
all of the same type. Components are selected by indexing.

**Based literal:** a based literal is a numeric literal expressed in a
form that specifies the base explicitly.

**Character literal:** a character literal is formed by enclosing a
graphic character between two apostrophe characters.

**Character type:** a character type is an enumeration type that
represents a character set.

**Composite type:** a composite type is a collection of components of
the same or different types.

**Constant:** a constant is a keyword that indicates that the identifier
it qualifies has a unique and specified value.

**Constrained array:** a constrained array is an array with a constant
number of elements.

**Discrete type:** a discrete type is either an integer type or an
enumeration type. Discrete types may be used, for example, in case
statements and as array indexes.

**Discriminant:** a discriminant is a component of a record type whose
value influences the structure of this record.

**Elementary type:** an elementary type does not have components.

**Enumeration representation clause:** an enumeration representation
clause specifies the bit pattern for each literal of the corresponding
enumeration type.

**Enumeration type:** an enumeration type is defined by the list of its
values, called enumeration literals, which may be identifiers or
character literals. All values for a given enumeration type are
different.

**Length clause:** a length clause specifies the amount of storage in
bits associated with a type.

**Literal:** a literal is a value represented by its value itself
instead of an identifier. A literal can be specialized as a numeric
literal, an enumeration literal, a character literal, or a string
literal.

**Marker**: a marker is a constant value provided by a data description.
This value will be found in the data as an end-delimiter of a
repetition.

**Numeric literal**: a numeric literal is the value of a number,
expressed by means of characters.

**Object:** an object is either a constant or a variable. An object
contains a value.

**Predefined type:** a predefined type is a type provided by EAST, that
is, a type that can be used in any EAST description without being
previously declared.

**Record representation clause:** a record representation clause
specifies the storage representation of the record type on the medium,
that is, the order, position and size of record components (including
discriminants, if any).

**Record type:** a record type is a composite type consisting of zero or
more named components, possibly of different types.

**Representation clause:** representation clauses specify the mapping
between types of the language and their physical representation.

**Scalar type:** scalar types are discrete types and real types.

**String literal:** a string literal is formed by a sequence of graphic
characters (possibly none) enclosed between two quotation marks used as
string brackets.

**Subtype:** a subtype is a type together with a constraint, which
constrains the values of the type to satisfy a certain condition. The
values of a subtype are a subset of the values of its type.

**Type:** a type is a named set of characteristics. This name can be
used to define sets of values.

**Unconstrained array:** an unconstrained array is an array with a
variable number of elements.

**Variable**: a variable is an identifier that represents a data item
occurrence.

**Variant part:** a variant part of a record specifies alternative
record components, dependent on the discriminant of the record. Each
value of the discriminant establishes a particular alternative of the
variant part.

**Virtual Discriminant:** a virtual discriminant is a discriminant that
is not included in the composite type that it discriminates.

# Annex B  CHARACTER DEFINITIONB

(This annex **is** part of the Recommendation)

This annex contains the definition of the character set used for the
EAST predefined type CHARACTER.

This character set is a subset of the 16-bit Basic Multilingual Plane
(BMP) of the ISO 10646 coded character set (reference \[2\]). This
subset is defined as the first 256 characters (row00) of the BMP, which
corresponds to the ISO 8859-1, which is an 8-bit single-byte coded
graphic character set, also known as "Latin Alphabet No. 1" (reference
\[1\]). The corresponding codes are shown in the following tables. *(The
code for each character (Char) is given in decimal (Dec), and
hexadecimal (Hex).)*

The whole of the ISO 8859-1 character set shown in the following tables
is permitted in the data that conforms to this Recommendation, although
for interpretation purposes the characters shaded in the following
tables are ignored and should not be displayed or printed.

The use of an ISO 8859-1 encoding to represent the natural language also
permits the incorporation of tables and figures that can be drawn with
the characters listed below. For these figures or tables to be presented
identically to any receiver, the interpretation of the control
characters (Vertical Tab, Horizontal Tab, Form Feed, Line Feed *(also
known as New Line)* and Carriage Return) must be standardized. The
following rules apply:

a\) A new line (positioning the next displayable character to the
leftmost displayable position and one line down) for presentation
purposes is understood to occur upon encountering the following
conditions:

1\) a Carriage Return, when it is not followed by a Line Feed;

2\) a Carriage Return/Line Feed pair, regardless of what follows;

3\) a Line Feed, when it is not followed by a Carriage Return;

4\) a Line Feed/Carriage Return pair, regardless of what follows.

b\) A Horizontal Tab character positions the next displayable character
onto the next character position that is a multiple of 8 *(i.e.,
character positions 8, 16, 24, 32 etc., where the leftmost displayable
character position is 0)*.

c\) A Form Feed character positions the next displayable character to
the leftmost displayable position and down to the beginning of the next
page. The definition of a page is as defined by the local device *(e.g.,
a new screen for a visual display unit (VDU) or a new piece of paper for
a printer)*.

d\) If the characteristics of the display device conflict with those of
the data, for example, line lengths may be greater than those permitted
by the device, then some adjustment to the layout of the data, as
determined by the device, will occur. *(Note also that some devices may
process or react to codes which this Recommendation specifies as being
ignored for presentation purposes.)*

NOTE − If the alignment of the displayed characters is significant to
the understanding of the information, then a fixed space font should be
used for presentation.

Some of the defined characters need some explanations: Space (SP),
No_Break_Space (NBSP), Soft_Hyphen (SHY) and Res.

a\) A space might be interpreted as a graphic character, or a control
character or both. As a graphic character, its representation consists
of no symbol, but it takes up display space.

b\) A No_Break_Space is a graphic character for which the representation
consists of no symbol. It shall be used when no break (new line) is
allowed.

c\) A Soft_Hyphen is a graphic character with the following
representation: "-". It occurs when a word is broken up because of a new
line.

d\) *Res* represents a reserved control character. It is anyway ignored
in EAST.

The language identified by the **ADID = CCSD0010** is EAST. The
character set to be used in EAST descriptions is a subset of the ISO
8859-1 (reference \[1\]). This subset is defined as **the first 128
characters** of the 8-bit single byte coded graphic character set (from
the decimal code 0 up to the decimal code 127 in the following tables).

NOTE − The character set used in EAST descriptions should not be
confused with the character set of the predefined type CHARACTER that
describes occurrences of data.

  ----------- ----- ----- ---- --------- ----- ----- ---- -------- ----- ----- ----- ----------- ----- -----
  Char        Dec   Hex        Char      Dec   Hex        Char     Dec   Hex         Char        Dec   Hex

  ***NUL***   0     00         *space*   32    20         **@**    64    40          **\`**      96    60

  ***SOH***   1     01         **!**     33    21         **A**    65    41          **a**       97    61

  ***STX***   2     02         **"**     34    22         **B**    66    42          **b**       98    62

  ***ETX***   3     03         **\#**    35    23         **C**    67    43          **c**       99    63

  ***EOT***   4     04         **\$**    36    24         **D**    68    44          **d**       100   64

  ***ENQ***   5     05         **%**     37    25         **E**    69    45          **e**       101   65

  ***ACK***   6     06         **&**     38    26         **F**    70    46          **f**       102   66

  ***BEL***   7     07         **'**     39    27         **G**    71    47          **g**       103   67

  ***BS***    8     08         **(**     40    28         **H**    72    48          **h**       104   68

  ***HT***    9     09         **)**     41    29         **I**    73    49          **i**       105   69

  ***LF***    10    0A         **\***    42    2A         **J**    74    4A          **j**       106   6A

  ***VT***    11    0B         **+**     43    2B         **K**    75    4B          **k**       107   6B

  ***FF***    12    0C         **,**     44    2C         **L**    76    4C          **l**       108   6C

  ***CR***    13    0D         **-**     45    2D         **M**    77    4D          **m**       109   6D

  ***SO***    14    0E         **.**     46    2E         **N**    78    4E          **n**       110   6E

  ***SI***    15    0F         **/**     47    2F         **O**    79    4F          **o**       111   6F

  ***DLE***   16    10         **0**     48    30         **P**    80    50          **p**       112   70

  ***DC1***   17    11         **1**     49    31         **Q**    81    51          **q**       113   71

  ***DC2***   18    12         **2**     50    32         **R**    82    52          **r**       114   72

  ***DC3***   19    13         **3**     51    33         **S**    83    53          **s**       115   73

  ***DC4***   20    14         **4**     52    34         **T**    84    54          **t**       116   74

  ***NAK***   21    15         **5**     53    35         **U**    85    55          **u**       117   75

  ***SYN***   22    16         **6**     54    36         **V**    86    56          **v**       118   76

  ***ETB***   23    17         **7**     55    37         **W**    87    57          **w**       119   77

  ***CAN***   24    18         **8**     56    38         **X**    88    58          **x**       120   78

  ***EM***    25    19         **9**     57    39         **Y**    89    59          **y**       121   79

  ***SUB***   26    1A         **:**     58    3A         **Z**    90    5A          **z**       122   7A

  ***ESC***   27    1B         **;**     59    3B         **\[**   91    5B          **{**       123   7B

  ***FS***    28    1C         **\<**    60    3C         **\\**   92    5C          **\|**      124   7C

  ***GS***    29    1D         **=**     61    3D         **\]**   93    5D          **}**       125   7D

  ***RS***    30    1E         **\>**    62    3E         **\^**   94    5E          **\~**      126   7E

  ***US***    31    1F         **?**     63    3F         **\_**   95    5F          ***DEL***   127   7F
  ----------- ----- ----- ---- --------- ----- ----- ---- -------- ----- ----- ----- ----------- ----- -----

  ----------- ----- ----- ---- -------- ----- ----- ---- ------- ----- ----- ----- ------- ----- -----
  Char        Dec   Hex        Char     Dec   Hex        Char    Dec   Hex         Char    Dec   Hex

  ***Res***   128   80         *nbsp*   160   A0         **À**   192   C0          **à**   224   E0

  ***Res***   129   81         **¡**    161   A1         **Á**   193   C1          **á**   225   E1

  ***Res***   130   82         **¢**    162   A2         **Â**   194   C2          **â**   226   E2

  ***Res***   131   83         **£**    163   A3         **Ã**   195   C3          **ã**   227   E3

  ***IND***   132   84         **¤**    164   A4         **Ä**   196   C4          **ä**   228   E4

  ***NEL***   133   85         **¥**    165   A5         **Å**   197   C5          **å**   229   E5

  ***SSA***   134   86         **\|**   166   A6         **Æ**   198   C6          **æ**   230   E6

  ***ESA***   135   87         **§**    167   A7         **Ç**   199   C7          **ç**   231   E7

  ***HTS***   136   88         **¨**    168   A8         **È**   200   C8          **è**   232   E8

  ***HTJ***   137   89         **©**    169   A9         **É**   201   C9          **é**   233   E9

  ***VTS***   138   8A         **ª**    170   AA         **Ê**   202   CA          **ê**   234   EA

  ***PLD***   139   8B         **«**    171   AB         **Ë**   203   CB          **ë**   235   EB

  ***PLU***   140   8C         **¬**    172   AC         **Ì**   204   CC          **ì**   236   EC

  ***RI***    141   8D         *shy*    173   AD         **Í**   205   CD          **í**   237   ED

  ***SS2***   142   8E         **®**    174   AE         **Î**   206   CE          **î**   238   EE

  ***SS3***   143   8F         **¯**    175   AF         **Ï**   207   CF          **ï**   239   EF

  ***DCS***   144   90         **°**    176   B0         **Ð**   208   D0          **ð**   240   F0

  ***PU1***   145   91         **±**    177   B1         **Ñ**   209   D1          **ñ**   241   F1

  ***PU2***   146   92         **²**    178   B2         **Ò**   210   D2          **ò**   242   F2

  ***STS***   147   93         **³**    179   B3         **Ó**   211   D3          **ó**   243   F3

  ***CCH***   148   94         **´**    180   B4         **Ô**   212   D4          **ô**   244   F4

  ***MW***    149   95         **μ**    181   B5         **Õ**   213   D5          **õ**   245   F5

  ***SPA***   150   96         **¶**    182   B6         **Ö**   214   D6          **ö**   246   F6

  ***EPA***   151   97         **·**    183   B7         **×**   215   D7          **÷**   247   F7

  ***Res***   152   98         **¸**    184   B8         **Ø**   216   D8          **ø**   248   F8

  ***Res***   153   99         **¹**    185   B9         **Ù**   217   D9          **ù**   249   F9

  ***Res***   154   9A         **º**    186   BA         **Ú**   218   DA          **ú**   250   FA

  ***CSI***   155   9B         **»**    187   BB         **Û**   219   DB          **û**   251   FB

  ***ST***    156   9C         **¼**    188   BC         **Ü**   220   DC          **ü**   252   FC

  ***OSC***   157   9D         **½**    189   BD         **Ý**   221   DD          **ý**   253   FD

  ***PM***    158   9E         **¾**    190   BE         **Þ**   222   DE          **þ**   254   FE

  ***APC***   159   9F         **¿**    191   BF         **ß**   223   DF          **ÿ**   255   FF
  ----------- ----- ----- ---- -------- ----- ----- ---- ------- ----- ----- ----- ------- ----- -----

The following tables assign a name (according to the ISO standard) to
each printable character of the set.

  ----- ---------------------------- ---- ----- ----------------------------
  Hex   Name                              Hex   Name

  09    Horizontal Tab                    3D    Equals Sign

  0A    Line Feed                         3E    Greater Than Sign

  0C    Form Feed                         3F    Question Mark

  0D    Carriage Return                   40    Commercial AT

  20    Space                             41    Capital Letter A

  21    Exclamation Mark                  42    Capital Letter B

  22    Quotation Mark                    43    Capital Letter C

  23    Number Sign                       44    Capital Letter D

  24    Dollar Sign                       45    Capital Letter E

  25    Percent Sign                      46    Capital Letter F

  26    Ampersand                         47    Capital Letter G

  27    Apostrophe                        48    Capital Letter H

  28    Left Parenthesis                  49    Capital Letter I

  29    Right Parenthesis                 4A    Capital Letter J

  2A    Asterisk                          4B    Capital Letter K

  2B    Plus Sign                         4C    Capital Letter L

  2C    Comma                             4D    Capital Letter M

  2D    Hyphen, Minus Sign                4E    Capital Letter N

  2E    Full Stop                         4F    Capital Letter O

  2F    Solidus                           50    Capital Letter P

  30    Digit Zero                        51    Capital Letter Q

  31    Digit One                         52    Capital Letter R

  32    Digit Two                         53    Capital Letter S

  33    Digit Three                       54    Capital Letter T

  34    Digit Four                        55    Capital Letter U

  35    Digit Five                        56    Capital Letter V

  36    Digit Six                         57    Capital Letter W

  37    Digit Seven                       58    Capital Letter X

  38    Digit Eight                       59    Capital Letter Y

  39    Digit Nine                        5A    Capital Letter Z

  3A    Colon                             5B    Left Square bracket

  3B    Semicolon                         5C    Reverse Solidus

  3C    Less Than Sign                    5D    Right Square Bracket
  ----- ---------------------------- ---- ----- ----------------------------

  ----- ---------------------------- ---- ----- ----------------------------
  Hex   Name                              Hex   Name

  5E    Circumflex Accent                 A1    Inverted Exclamation Mark

  5F    Low Line                          A2    Cent Sign

  60    Grave Accent                      A3    Pound Sign

  61    Small Letter a                    A4    Currency Sign

  62    Small Letter b                    A5    Yen Sign

  63    Small Letter c                    A6    Broken Bar

  64    Small Letter d                    A7    Paragraph Sign, Section Sign

  65    Small Letter e                    A8    Diaeresis

  66    Small Letter f                    A9    Copyright Sign

  67    Small Letter g                    AA    Feminine Ordinal Indicator

  68    Small Letter h                    AB    Left Angle Quotation Mark

  69    Small Letter i                    AC    Not Sign

  6A    Small Letter j                    AD    Soft Hyphen

  6B    Small Letter k                    AE    Registered Trade Mark Sign

  6C    Small Letter l                    AF    Macron

  6D    Small Letter m                    B0    Ring Above, Degree Sign

  6E    Small Letter n                    B1    Plus-Minus Sign

  6F    Small Letter o                    B2    Superscript Two

  70    Small Letter p                    B3    Superscript Three

  71    Small Letter q                    B4    Acute Accent

  72    Small Letter r                    B5    Micro Sign

  73    Small Letter s                    B6    Pilcrow Sign

  74    Small Letter t                    B7    Middle Dot

  75    Small Letter u                    B8    Cedilla

  76    Small Letter v                    B9    Superscript One

  77    Small Letter w                    BA    Masculine Ordinal Indicator

  78    Small Letter x                    BB    Right Angle Quotation Mark

  79    Small Letter y                    BC    Vulgar Fraction One Quarter

  7A    Small Letter z                    BD    Vulgar Fraction One Half

  7B    Left Curly Bracket                BE    Vulgar Fraction Three
                                                Quarters

  7C    Vertical Line                     BF    Inverted Question Mark

  7D    Right Curly Bracket               C0    Capital Latter A with Grave

  7E    Tilde                             C1    Capital Letter A with Acute
                                                Accent

  A0    No-Break Space                    C2    Capital Letter A with
                                                Circumflex
  ----- ---------------------------- ---- ----- ----------------------------

  ----- ---------------------------- ---- ----- ----------------------------
  Hex   Name                              Hex   Name

  C3    Capital Letter A with Tilde       E2    Small Letter a with
                                                Circumflex

  C4    Capital Letter A with             E3    Small Letter a with Tilde
        Diaeresis                               

  C5    Capital Letter A with Ring        E4    Small Letter a with
        Above                                   Diaeresis

  C6    Capital Diphthong A with E        E5    Small Letter a with Ring
                                                Above

  C7    Capital Letter C with             E6    Small Diphthong a with e
        Cedilla                                 

  C8    Capital Letter E with Grave       E7    Small Letter c with Cedilla
        Accent                                  

  C9    Capital Letter E with Acute       E8    Small Letter e with Grave
        Accent                                  Accent

  CA    Capital Letter E with             E9    Small Letter e with Acute
        Circumflex                              Accent

  CB    Capital Letter E with             EA    Small Letter e with
        Diaeresis                               Circumflex

  CC    Capital Letter I with Grave       EB    Small Letter e with
        Accent                                  Diaeresis

  CD    Capital Letter I with Acute       EC    Small Letter i with Grave
        Accent                                  Accent

  CE    Capital Letter I with             ED    Small Letter i with Acute
        Circumflex                              Accent

  CF    Capital Letter I with             EE    Small Letter i with
        Diaeresis                               Circumflex

  D0    Capital Icelandic Letter ETH      EF    Small Letter i with
                                                Diaeresis

  D1    Capital Letter N with Tilde       F0    Small Icelandic Letter ETH

  D2    Capital Letter O with Grave       F1    Small Letter n with Tilde
        Accent                                  

  D3    Capital Letter O with Acute       F2    Small Letter o with Grave
        Accent                                  Accent

  D4    Capital Letter O with             F3    Small Letter o with Acute
        Circumflex                              Accent

  D5    Capital Letter O with Tilde       F4    Small Letter o with
                                                Circumflex

  D6    Capital Letter O with             F5    Small Letter o with Tilde
        Diaeresis                               

  D7    Multiplication Sign               F6    Small Letter o with
                                                Diaeresis

  D8    Capital Letter O with             F7    Division Sign
        Oblique                                 

  D9    Capital Letter U with Grave       F8    Small Letter o with Oblique
        Accent                                  Stroke

  DA    Capital Letter U with Acute       F9    Small Letter u with Grave
        Accent                                  Accent

  DB    Capital Letter U with             FA    Small Letter u with Acute
        Circumflex                              Accent

  DC    Capital Letter U with             FB    Small Letter u with
        Diaeresis                               Circumflex

  DD    Capital Letter Y with Acute       FC    Small Letter u with
        Accent                                  Diaeresis

  DE    Capital Icelandic Letter          FD    Small Letter y with Acute
        THORN                                   Accent

  DF    Small German Letter Sharp s       FE    Small Icelandic Letter THORN

  E0    Small Letter a with Grave         FF    Small Letter y with
        Accent                                  Diaeresis

  E1    Small Letter a with Acute               
        Accent                                  
  ----- ---------------------------- ---- ----- ----------------------------

The following tables assign an identifier to each character of the set.
These identifiers are the constant names of each character.

  ----- ---------------------------- ---- ----- ----------------------------
  Hex   Constant Name                     Hex   Constant Name

  00    NUL                               20    Space

  01    SOH                               21    Exclamation

  02    STX                               22    Quotation

  03    ETX                               23    Number_Sign

  04    EOT                               24    Dollar_Sign

  05    ENQ                               25    Percent_Sign

  06    ACK                               26    Ampersand

  07    BEL                               27    Apostrophe

  08    BS                                28    Left_Parenthesis

  09    HT                                29    Right_Parenthesis

  0A    LF                                2A    Asterisk

  0B    VT                                2B    Plus_Sign

  0C    FF                                2C    Comma

  0D    CR                                2D    Hyphen or Minus_Sign

  0E    SO                                2E    Full_Stop

  0F    SI                                2F    Solidus

  10    DLE                               30    Digit_Zero

  11    DC1                               31    Digit_One

  12    DC2                               32    Digit_Two

  13    DC3                               33    Digit_Three

  14    DC4                               34    Digit_Four

  15    NAK                               35    Digit_Five

  16    SYN                               36    Digit_Six

  17    ETB                               37    Digit_Seven

  18    CAN                               38    Digit_Eight

  19    EM                                39    Digit_Nine

  1A    SUB                               3A    Colon

  1B    ESC                               3B    Semicolon

  1C    FS or IS4                         3C    Less_Than_Sign

  1D    GS or IS3                         3D    Equals_Sign

  1E    RS or IS2                         3E    Greater_Than_Sign

  1F    US or IS1                         3F    Question
  ----- ---------------------------- ---- ----- ----------------------------

  ----- ---------------------------- ---- ----- -----------------------------
  Hex   Constant Name                     Hex   Constant Name

  40    Commercial_At                     60    Grave

  41    UC_A                              61    LC_A

  42    UC_B                              62    LC_B

  43    UC_C                              63    LC_C

  44    UC_D                              64    LC_D

  45    UC_E                              65    LC_E

  46    UC_F                              66    LC_F

  47    UC_G                              67    LC_G

  48    UC_H                              68    LC_H

  49    UC_I                              69    LC_I

  4A    UC_J                              6A    LC_J

  4B    UC_K                              6B    LC_K

  4C    UC_L                              6C    LC_L

  4D    UC_M                              6D    LC_M

  4E    UC_N                              6E    LC_N

  4F    UC_O                              6F    LC_O

  50    UC_P                              70    LC_P

  51    UC_Q                              71    LC_Q

  52    UC_R                              72    LC_R

  53    UC_S                              73    LC_S

  54    UC_T                              74    LC_T

  55    UC_U                              75    LC_U

  56    UC_V                              76    LC_V

  57    UC_W                              77    LC_W

  58    UC_X                              78    LC_X

  59    UC_Y                              79    LC_Y

  5A    UC_Z                              7A    LC_Z

  5B    Left_Square_Bracket               7B    Left_Curly_Bracket

  5C    Reverse_Solidus                   7C    Vertical_Line

  5D    Right_Square_Bracket              7D    Right_Curly_Bracket

  5E    Circumflex                        7E    Tilde

  5F    Low_Line                          7F    DEL
  ----- ---------------------------- ---- ----- -----------------------------

  ----- ---------------------------- ---- ----- -----------------------------
  Hex   Constant Name                     Hex   Constant Name

  80    Reserved_128                      A0    No_Break_Space or NBSP

  81    Reserved_129                      A1    Inverted_Exclamation

  82    BPH                               A2    Cent_Sign

  83    NBH                               A3    Pound_Sign

  84    Reserved_132                      A4    Currency_Sign

  85    NEL                               A5    Yen_Sign

  86    SSA                               A6    Broken_Bar

  87    ESA                               A7    Section_Sign

  88    HTS                               A8    Diaeresis

  89    HTJ                               A9    Copyright_Sign

  8A    VTS                               AA    Feminine_Ordinal_Indicator

  8B    PLD                               AB    Left_Angle_Quotation

  8C    PLU                               AC    Not_Sign

  8D    RI                                AD    Soft_Hyphen

  8E    SS2                               AE    Registered_Trade_Mark_Sign

  8F    SS3                               AF    Macron

  90    DCS                               B0    Degree_Sign or Ring_Above

  91    PU1                               B1    Plus_Minus_Sign

  92    PU2                               B2    Superscript_Two

  93    STS                               B3    Superscript_Three

  94    CCH                               B4    Acute

  95    MW                                B5    Micro_Sign

  96    SPA                               B6    Pilcrow_Sign or
                                                Paragraph_Sign

  97    EPA                               B7    Middle_Dot

  98    Res                               B8    Cedilla

  99    Res                               B9    Superscript_One

  9A    Res                               BA    Masculine_Ordinal_Indicator

  9B    CSI                               BB    Right_Angle_Quotation

  9C    ST                                BC    Fraction_One_Quarter

  9D    OSC                               BD    Fraction_One_Half

  9E    PM                                BE    Fraction_Three_Quarters

  9F    APC                               BF    Inverted_Question
  ----- ---------------------------- ---- ----- -----------------------------

  ----- ---------------------------- ---- ----- -----------------------------
  Hex   Constant Name                     Hex   Constant Name

  C0    UC_A_Grave                        E0    LC_A_Grave

  C1    UC_A_Acute                        E1    LC_A_Acute

  C2    UC_A_Circumflex                   E2    LC_A_Circumflex

  C3    UC_A_Tilde                        E3    LC_A_Tilde

  C4    UC_A_Diaeresis                    E4    LC_A_Diaeresis

  C5    UC_A_Ring                         E5    LC_A_Ring

  C6    UC_AE_Diphthong                   E6    LC_AE_Diphthong

  C7    UC_C_Cedilla                      E7    LC_C_Cedilla

  C8    UC_E_Grave                        E8    LC_E_Grave

  C9    UC_E_Acute                        E9    LC_E_Acute

  CA    UC_E_Circumflex                   EA    LC_E_Circumflex

  CB    UC_E_Diaeresis                    EB    LC_E_Diaeresis

  CC    UC_I_Grave                        EC    LC_I_Grave

  CD    UC_I_Acute                        ED    LC_I_Acute

  CE    UC_I_Circumflex                   EE    LC_I_Circumflex

  CF    UC_I_Diaeresis                    EF    LC_I_Diaeresis

  D0    UC_Icelandic_Eth                  F0    LC_Icelandic_Eth

  D1    UC_N_Tilde                        F1    LC_N_Tilde

  D2    UC_O_Grave                        F2    LC_O_Grave

  D3    UC_O_Acute                        F3    LC_O_Acute

  D4    UC_O_Circumflex                   F4    LC_O_Circumflex

  D5    UC_O_Tilde                        F5    LC_O_Tilde

  D6    UC_O_Diaeresis                    F6    LC_O_Diaeresis

  D7    Multiplication_Sign               F7    Division_Sign

  D8    UC_O_Oblique_Stroke               F8    LC_O_Oblique_Stroke

  D9    UC_U_Grave                        F9    LC_U_Grave

  DA    UC_U_Acute                        FA    LC_U_Acute

  DB    UC_U_Circumflex                   FB    LC_U_Circumflex

  DC    UC_U_Diaeresis                    FC    LC_U_Diaeresis

  DD    UC_Y_Acute                        FD    LC_Y_Acute

  DE    UC_Icelandic_Thorn                FE    LC_Icelandic_Thorn

  DF    LC_German_Sharp_S                 FF    LC_Y_Diaeresis
  ----- ---------------------------- ---- ----- -----------------------------

# Annex C  EAST FORMAL SYNTAX SPECIFICATIONC

(This annex **is not** part of the Recommendation)

This annex describes the EAST syntax using a simple version of the
Backus-Naur-Form. See below the lexical rules, common to the whole
syntax specification:

**C 1 COMMON LEXICAL RULES**

\<underline\> ::= \_

\<digit\> ::= 0 \| 1 \| 2 \| 3 \| 4 \| 5 \| 6 \| 7 \| 8 \| 9

\<upper_case\> ::= A \| B \|\...\| Z

\<lower_case\> ::= a \| b \|\...\| z

\<letter\> ::= \<upper_case\> \| \<lower_case\>

\<letter_or_digit\> ::= \<letter\> \| \<digit\>

\<identifier\> ::= \<letter\> { \[ \<underline\> \] \<letter_or_digit\>
}

\<integer_literal\> ::= \<digit\> { \[ \<underline\> \] \<digit\> }

\<exponent\> ::= E \[ + \| ‑ \] \<integer_literal\>

\<floating_point_literal\> ::= \<integer_literal\>.\<integer_literal\>
\[ \<exponent\> \]

\<identifier_list\> ::= \<identifier\> { , \<identifier\> }

\<character\> ::= *nul* \| \... \| 0 \| 1 \| \... \| b \| \... \| \~ \|
*del*

\<character_literal\> ::= ' \<character\> '

\<based_literal\> ::= \<base\># \<based_integer\> \[ .
\<based_integer\>\] \# \[\<exponent\>\]

\<base\> ::= 2 \| 8 \| 16

\<based_integer\> ::= \<extended_digit\> {\[\<underline\>\]
\<extended_digit\>}

\<extended_digit\> ::= digit \| A \| B \| C \| D \| E \| F \| a \| b \|
c \| d \| e \| f

\<integer_based_literal\> ::= \<base\># \<based_integer\> \#
\[\<exponent\>\]

\<real_based_literal\> ::= ::= \<base\># \<based_integer\> .
\<based_integer\> \# \[\<exponent\>\]

\<simple_integer_based_literal \> ::= \<base\># \<based_integer\> \#

**C 2 DECLARATION OF THE LOGICAL DATA DESCRIPTION RECORD**

\<Logical Description\> ::= **package** \<identifier\> **is**\
{ \<constant_declaration\> \|\
\<type_declaration\> \| \<subtype_declaration\> \|\
\<representation_clause\> }\
{ \<variable_declaration\> \| \<constant_declaration\> }\
**end** \<identifier\> **;**

**C 2.1 Subtype Declaration**

\<subtype_declaration\> ::= **subtype** \<*subtype\_*identifier\> **is**
\<subtype_indication\> **;**

\<subtype_indication\> ::= \<type_mark\> \[ \<constraint\> \]

\<type_mark\> ::= \<predefined_type\> \| \<*subtype\_*identifier\> \|\
\<*type\_*identifier\>

**C 2.2 Type Declaration**

\<type_declaration\> ::= **type** \<*type\_*identifier\> \[
\<discriminant_part\> \] **is**\
\<type_definition\> **;**

\<discriminant_part\> ::= (\<discriminant_specification\>\
{ **;** \<discriminant_specification\> })

\<discriminant_specification\>::= \<identifier\> **:**
\<*discrete\_*type_mark\> := \<discriminant_value\>

\<discriminant_value\> ::= \<integer_literal\> \|
\<enumeration_literal\>

\<type_definition\> ::= \<integer_type_definition\> \|
\<real_type_definition\> \|\
\<array_type_definition\> \| \<record_type_definition\> \|\
\<enumeration_type_definition\>

**a) constraint declaration**

\<constraint\> ::= \<range_constraint\> \| \<floating_point_constraint\>
\|\
\<index_constraint\>

\<range_constraint\> ::= **range** \<range\>

\<range\> ::= \<integer_bound\> **..** \<integer_bound\> **;**

\<integer_bound\> ::= \[ + \| ‑ \] \<integer_literal\> \|
\<*integer_constant\_*identifier\>

\<floating_point_constraint\> ::= \[ **digits**
\<*positive\_*integer_literal\> \]\
\[ **range** \<real_bound\> **..** \<real_bound\> \] **;**

\<real_bound\> ::= \[ + \| ‑ \] \<floating_point_literal\> \|
\<*real_i*dentifier\>

\<index_constraint\> ::= **(** \<discrete_range\> {**,**
\<discrete_range\> } **)**

**b) integer type declaration**

\<integer_type_definition\> ::= \<range_constraint\>

**c) real type declaration**

\<real_type_definition\> ::= \<floating_point_constraint\>

**d) array type declaration**

\<array_type_definition\> ::= \<unconstrained_array_definition\> \|\
\<constrained_array_definition\>

\<unconstrained_array_definition\> ::= **array** **(**
\<index_subtype_definition\>\
{**,** \<index_subtype_definition\> } **)** **of** \<type_mark\> **;**

\<constrained_array_definition\> ::= **array (** \<discrete_range\>\
{**,** \<discrete_range\> } **)** **of** \<type_mark\> **;**

\<index_subtype_definition\> ::= \<discrete_type_mark\> **range \<\>**

\<discrete_range\> ::= \<discrete_type_mark\> \| \<constrained_index\>

\<discrete_type_mark\> ::= \<*integer*\_type_mark\> \|
\<*enumeration*\_type_mark\>

\<constrained_index\> ::= \<index_bound\> .. \<index_bound\>

\<index_bound\> ::= \[+\|‑\] \<integer_literal\> \|
\<*integer_constant\_*identifier\> \|\
\<enumeration_literal\>

**e) record type declaration**

\<record_type_definition\> ::= **record** \<component_list\> **end
record** **;**

\<component_list\> ::= \<component_declaration\> {
\<component_declaration\> }\|\
{ \<component_declaration\> } \<variant_part\> \|\
**null ;**

\<component_declaration\> ::= \<identifier\> **:**
\<subtype_indication\> **;**

\<variant_part\> ::= **case** \<*discriminant\_*identifier\> **is**\
\<variant\> { \<variant\> }\
**end case ;**

\<variant\> ::= **when** \<choice\> { **\|** \<choice\> } **=\>**\
\<component_list\>

\<choice\> ::= \[‑\] \<integer_literal\> \| \<discrete_range\> \|
**others** \|\
\<enumeration_literal_specifiation\>

**f) enumeration type declaration**

\<enumeration_type_definition\> ::= **(** \<enumeration_literal\> {
**,** \<enumeration_literal\> } **)**

\<enumeration_literal\>::= \<identifier\> \| \<character_literal\>

**g) predefined types**

\<predefined_type\> ::= **character** \| **string \| EOF**

**C 2.3 Object Declaration**

\<constant_declaration\> ::= \<identifier\> : **constant**
\[\<type_mark\>\]\
\[ := \<constant_value\> \]**;**

\<constant_value\> ::= \<integer_literal\> \|\
\<floating_point_literal\> \|\
\<enumeration_literal\> \|\
\<string_literal\> \|\
\<static_expression\> ;

\<static_expression\> ::= { (\<term\>) \| \<term\> }

\<term\> ::= \[unary_operator\] \<number\>
\[\<binary_operator\>\<number\>\]

\<unary_operator\> ::= + \| -

\<binary_operator\> ::= + \| - \| \* \| / \| \*\*

\-- See section 3.2.3.2 of the present Recommendation for further
constraints on operators.

\<number\> ::= \<integer_literal\> \| \<floating_point_literal\> \|\
\<*integer_constant*\_identifier\> \| \<*real_constant*\_identifier\>

\<variable_declaration\> ::= \<identifier\> : \<type_mark\>;

**C 2.4 Representation Clause**

\<representation_clause\> ::= \<length_clause\> \|\
\<enumeration_representation_clause\> \|\
\<record_representation_clause\>

**a) length clause**

\<length_clause\>::= **for** \<*type\_*identifier\>'**size use**
\<integer_literal\> **;**

**b) enumeration representation clause**

\<enumeration_representation_clause\>::= **for**
\<*enumeration_type\_*identifier\> **use**\
\<aggregate\>**;**

\<aggregate\> ::=**(**\<component_association\> {**,**
\<component_association\>} **)**

\<component_association\> ::= \<enumeration_literal\> **=\>**
\<bit_pattern\>

\<bit_pattern\> ::= \<integer_literal\> \|
\<simple_integer_based_literal \>

**c) record representation clause**

\<record_representation_clause\> ::= **for**
\<*record_type\_*identifier\> **use**\
**record**\
\<component_clause\> { \<component_clause\>}\
**end record ;**

\<component_clause\> ::= \<*component\_*identifier\> **at**
\<distance\>**\
range** \<*static\_*range\> **;**

\<distance\> ::= \<word_number\> \* **word_32_bits** **\|\
**\<word_number\> \* **word_16_bits \|** 0

\<word_number\> ::= \<integer_literal\>

**C 3 DECLARATION OF THE PHYSICAL DATA DESCRIPTION RECORD**

\<Physical Description\> ::= **package** \<identifier\> **is**\
\<declaration_part\>\
**end** \<identifier\> **;**

\<declaration_part\> ::= { \<constant_declaration\> \|\
\<type_declaration\> \| \<subtype_declaration\> }

\<constant_declaration\> ::= \<identifier\> : **constant** \<type_mark\>
:= \<constant_value\> **;**

\<constant_value\> ::= \<integer_literal\> \| \<floating_point_literal\>
\|\
\<enumeration_literal\> \|\
\<array_value\> \| \<record_value\>

\<record_value\> ::= **(** \<record_component_value\> { **,**
\<record_component_value\> } **)**

\<record_component_value\> ::= \<*component*\_identifier\> =\>
\<constant_value\>

\<array_value\> ::= **(** \<array_component_value\> { **,**
\<array_component_value\> } **)**

\<array_component_value\> ::= \<integer_literal\> =\> \<constant_value\>

Other BNF rules needed for the physical data description record, if not
defined above in this section, are identical to those specified for the
logical data description record.

# Annex D  MAIN DIFFERENCES BETWEEN ADA AND EASTD

(This annex **is not** part of the Recommendation)

This annex describes the main differences between EAST and the Ada
programming language:

− the Ada features not retained in EAST;

− the Ada syntax elements which have another semantic in EAST;

− the EAST syntax restrictions vs. Ada.

**D 1 ADA FEATURES NOT RETAINED IN EAST**

No algorithmic features of the Ada programming language have been
retained in EAST.

In Ada, a program unit can be a procedure, a function, a package or a
task. Only packages are allowed in EAST: a package structure is used to
implement the logical description part; another package implements the
physical description part.

Within the declarative part, some Ada **predefined types** have been
**excluded** for the data description:

− The predefined type BOOLEAN, because no enumeration representation
clause is provided for this type in the Ada STANDARD package. Any bit
pattern may therefore be used for the implementation of a Boolean value.

− The predefined type INTEGER, because its definition depends on the
implementation (size, bounds, etc.). For the same reason, other integer
types such as LONG_INTEGER or SHORT_INTEGER are also forbidden.

− The subtypes of INTEGER: POSITIVE and NATURAL depend on the definition
of INTEGER and so depend on the implementation.

− The predefined type FLOAT, because its definition depends on the
implementation (size, number of digits, etc.). For the same reason,
other floating-point types such as LONG_FLOAT or SHORT_FLOAT are also
forbidden.

− The predefined type DURATION and any fixed-point type, because their
size depends on the implementation. Consequence: a real type in EAST is
always considered to be a floating-point type.

Access types and derived types are not considered to be useful in a Data
Description Record.

In the same way, generics have not been retained in EAST.

In Ada, a pragma is used to convey information to Ada compilers. As
such, pragma use is not justified in EAST.

**D 2 ADA SYNTAX ELEMENTS THAT HAVE A DIFFERENT MEANING IN EAST**

A length clause is defined by the following declaration:

**for** type_identifier'**size use** static_expression **;**

In Ada, the value of the expression specifies an upper bound for the
number of bits to be allocated to objects of the given type. In EAST,
the expression specifies the exact number of bits that any object of the
given type occupies.

In Ada, a record representation clause specifies the storage
representation of records in memory, that is, the order, position, and
size of record components in memory of a given machine. In EAST, the
record representation clause specifies the actual storage representation
on the medium.

**D 3 EAST SYNTAX RESTRICTIONS VS. ADA**

In Ada, the base for based numeric literals can be any number between 2
and 16. In EAST the base can only be 2, 8 or 16.

In Ada the values specified in a range constraint within an integer or
real type definition can be a simple_expression. In EAST the values may
only be a numeric literal or an identifier naming an appropriate numeric
constant.

In Ada, a constant declaration allows a list of identifiers. EAST allows
only a single identifier.

# Annex E  INFORMATIVE REFERENCESE

(This annex **is not** part of the Recommendation)

Informative references \[E2\]-\[E5\] below contain information showing
how EAST descriptions can be used in the SFDU standard or presenting the
Ada language, which is the basis of this Recommendation.

\[E1\] *Procedures Manual for the Consultative Committee for Space Data
Systems*. CCSDS A00.0-Y-7. Yellow Book. Issue 7. Washington, D.C.:
CCSDS, November 1996.

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

\[E3\] *Information Technology---Programming Languages---Ada*.
International Standard, ISO/EIC 8652:1995. Geneva: ISO, 1995.

\[E4\] *The Data Description Language EAST---A Tutorial*. Report
Concerning Space Data System Standards, CCSDS 645.0-G-1. Green Book.
Issue 1, May 1997.

\[E5\] *The Data Description Language EAST---List of Conventions*.
Report Concerning Space Data System Standards, CCSDS 646.0-G-1. Green
Book. Issue 1, May 1997.

# INDEX {#index .Annex-Heading-1}

Array storage method, 3-41

Array type, 3-11, 3-12, 3-13, 1

ASCII Representation, 3-50, 3-51, 3-53, 3-54, 3-59

Based literal, 3-4, 3-5, 1

Binary Representation, 3-43, 3-48, 3-49, 3-50

BNF, 1-2, 1-4, 1, 6

Character literal, 1

Character type, 1

Comment, 3-1

Composite type, 2-3, 1

Constant, 3-7, 3-9, 3-10, 3-24, 3-25, 3-26, 3-27, 3-28, 3-32, 3-37,
3-38, 3-39, 3-41, 3-43, 3-44, 3-45, 3-48, 3-49, 3-50, 3-52, 3-54, 3-56,
3-58, 1, 2, 8, 9, 10, 11, 2, 3, 4, 6, 2

Constraint array type, 3-13

Decimal literal, 3-2, 3-3, 3-4

Delimiter, 1-3, 1-4, 3-1, 2

Discrete type, 1

Discriminant, 3-16, 3-17, 3-18, 3-19, 3-32, 3-35, 2, 3, 2, 4

Distance, 3-32, 3-38, 3-39, 5

Enumeration constraint, 3-23

Enumeration representation clause, 3-30, 2

Enumeration type, 3-8, 3-9, 3-50, 3-51, 3-52, 2

Identifier, 1-1, 1-3, 3-1, 3-2, 3-7, 3-8, 3-9, 3-10, 3-12, 3-15, 3-18,
3-24, 3-25, 3-26, 3-27, 3-40, 3-44, 3-50, 3-54, 4-1, 1, 2, 3, 8, 1, 2,
3, 4, 5, 6, 2

Index, 2-1, 2-3, 3-11, 3-12, 3-13, 3-15, 3-41, 3-47, 2, 3

Integer constraint, 3-24

Integer type, 2-3, 3-8, 3-9, 3-10, 3-11, 3-13, 3-15, 3-17, 3-18, 3-25,
3-28, 3-33, 3-49, 3-50, 3-54, 3-58, 3-59, 1, 3, 1

Length clause, 3-29, 2

Logical description, 2-2, 3-21, 2

Marker, 3-28, 2

Numeric literal, 2

Numeric type, 2-3

Object, 1-3, 2-2, 2-3, 3-7, 3-26, 3-41, 2, 4, 2

Package, 2-1, 2-2, 3-7, 3-40, 3-56, 3-58, 2, 6, 1

Physical description, 2-2, 3-41, 3-43, 3-45, 3-46, 3-51, 3-52, 3-53,
3-54, 6

Predefined type, 3-8, 2

Real constraint, 3-25

Real type, 3-10, 3-54

Record representation clause, 3-31, 3-32, 3-34, 3-35, 3-36, 3-38, 3-39,
2

Record type, 3-13, 3-14, 3-15, 3-17, 2

Representation clause, 2-3, 3-29, 3-30, 3-31, 3-32, 3-34, 3-35, 3-36,
3-38, 3-39, 2, 5

Scalar type, 3-22, 3-50, 2

Separator, 3-1

Subtype, 2-3, 3-7, 3-23, 3-24, 3-25, 3-26, 3-27, 2, 3, 6

Unconstrained array type, 3-13

Variable, 1-4, 3-7, 3-26, 3-27, 3-28, 3-29, 3-32, 3-33, 3-38, 3-56, 2,
3, 2, 4

Variant, 1-2, 1-4, 3-16, 3-17, 3-32, 3-37, 3-38, 3, 4

Virtual discriminant, 3-18, 3-19, 3-21, 3-32, 4-1, 3

WORD_16_BITS, 3-39, 4-1, 5

WORD_32_BITS, 3-39, 4-1, 5