DEBAT: Development of EAST Based Access Tools
EAST Language Changes
Contract: 16562/02/I-LG
Reference: SS/DEBAT/ELC
Issue: 1.0
Date: 14/10/2003
Prepared by:
Date:
DEBAT Team
Checked by:
Date:
Josiane Denailhac
Approved by:
Date:
Laurent Cohen
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue
: 1.0
Date
: 14/10/03
Page
:i
Document Status Sheet
Document Title
Document Reference Number
Issue
Revision
Date
1
0
14/10/03
EAST Language Changes
SS/DEBAT/ELC
Reason for change
First version
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
: ii
Document Change Records
Document Title
Document Reference Number
Document Issue/Revision Number
Page Paragraph
All
First version
EAST Language Changes
SS/DEBAT/ELC
1.0
Reason for change
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
: iii
Table of contents
DOCUMENT STATUS SHEET ....................................................................................................... I
DOCUMENT CHANGE RECORDS .............................................................................................. II
TABLE OF CONTENTS................................................................................................................ III
ACRONYMS AND ABBREVIATIONS ....................................................................................... IV
APPLICABLE DOCUMENTS ...................................................................................................... VI
REFERENCE DOCUMENTS ...................................................................................................... VII
1. INTRODUCTION.......................................................................................................................... 1
1.1 PURPOSE ...................................................................................................................................... 1
1.2 SCOPE .......................................................................................................................................... 1
1.3 STRUCTURE OF THE DOCUMENT ................................................................................................... 1
1.4 DEFINITIONS ................................................................................................................................ 2
2. EAST LANGUAGES CHANGES ................................................................................................ 3
2.1 VERSION MANAGEMENT............................................................................................................... 3
2.1.1 Rationale .............................................................................................................................. 3
2.1.2 Changes to the EAST language ............................................................................................ 3
2.2 DEFAULT VALUES ........................................................................................................................ 3
2.2.1 Rationale .............................................................................................................................. 3
2.2.2 Changes to the EAST language ............................................................................................ 3
2.3 CONSTANTS AND STRING CONSTANTS .......................................................................................... 4
2.3.1 Rationale .............................................................................................................................. 4
2.3.2 Changes to the EAST language ............................................................................................ 5
2.4 UNIQUELY IDENTIFYING ELEMENTS ............................................................................................. 6
2.4.1 Rationale .............................................................................................................................. 6
2.4.2 Changes to the EAST language ............................................................................................ 6
2.5 CALCULATION CAPABILITIES ....................................................................................................... 7
2.5.1 Rationale .............................................................................................................................. 7
2.5.2 EAST language changes ....................................................................................................... 8
2.5.2.1
Array lengths ............................................................................................................ 8
2.5.2.2
Discriminants ........................................................................................................... 9
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue
: 1.0
Date
: 14/10/03
Page
: iv
Acronyms and Abbreviations
ADD
AMS
API
AR
ATP
CA
CAID
CAO
CAOS
CDF
CDR
CEOS
CFI
CNES
COTS
CCSDS
DEAL
DEBAT
DEBAT-DM
DEBAT-DPE
DEBAT-DEQ
DEBAT-PPT
DEBAT-UT
DDR
DDU
DDF
DED
DEDSL
DEW
DIP
DJF
DUW
DW
EAST
ECSS
EO
ESA
ESRIN
ERS
ESA
EVA
FA
FAQ
FAR
FAT
Architectural Design Document
Archive Management System
Application Program Interface
Acceptance Review
Authorisation To Proceed
Control Authority
Control Authority Identifier
Control Authority Office
Control Authority Office System
Common Data Format
Critical Design Review
Committee on Earth Observation Science
Customer Furnished Item
Centre National D’Etudes Spatiales (French Space Agency)
Commercial Off The Shelf
Consultative Committee for Space Data Systems
Display EAST Access List
Development of EAST Based Access Tools
DEBAT Data Modeller
DEBAT Data Producer & Editor
DEBAT Data Extractor & Querying
DEBAT Post Processing Tools
DEBAT Utilities
Data Description Record
Data Description Unit
Design Definition File
Data Entity Dictionary
Data Entity Description Specification Language
Data Extractor Wizard
Dissemination Information Package
Design Justification File
Data Update Wizard
DEBAT Workshop
Enhanced ADA Sub SeT
European Cooperation for Space Standardization
Earth Observation
European Space Agency
European Space Research INstitute
European Remote Sensing satellite
European Space Agency
ESA Virtual Archive
Final Acceptance
Frequently Asked Question
Factory Acceptance Review
Factory Acceptance Tests
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
FDIR
FP
FPA
GUI
HDF
HTML
HTTP
HW
ICD
IDVP
IR
ITT
JSP
KOM
MACAO
MMI
NAS
OAIS
OASIS
OSAT
PAP
PDR
PMP
PUS
PVL
RB
RID
RTD
SCMP
SIP
SOAP
SOW
SPMP
SRR
SVG
TM/TC
TS
UDDI
SRD
URD
WSDL
WWW
XML
XSL
XSLT
Fault Detection, Isolation and Recovery
Final Presentation
Final Presentation and Acceptance
Graphical User Interface
Hierarchical Data Format
Hyper Text Mark-up Language
Hyper Text Transfer Protocol
Hardware
Interface Control Document
Implementation, Diffusion and Validation Plan
Interface Requirements
Invitation To Tender
Java Server Pages
Kick Off Meeting
Member Agency Control Authority Office
Man-Machine Interface
Network Attached Storage
Open Archival Information System
Space Data Modelling Help Tool
On Site installation and Acceptance Tests
Product Assurance Plan
Preliminary Design Review
Project Management Plan
Packet Utilisation Standard
Parameter Value Language
Requirements Baseline
Review Item Discrepancy
Research and Technology Development
Software Configuration Management Plan
Submission Information Package
Simple Object Access Protocol
Statement of Work
Software Project Management Plan
System Requirements Review
Scalable Vector Graphic
Telemetry / Telecommand
Technical Specifications
Universal Description Discovery and Integration
Software Requirements Document
User Requirements Document
Web Service Description Language
World Wide Web
eXtensible Mark-up Language
eXtensible Stylesheet Language
eXtensible Stylesheet Language Transformation
DEBAT – Development of EAST Based Access Tools
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
:v
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
: vi
EAST Language Changes
Applicable Documents
Title
AD1 ESRIN SOW “Development
EAST Based Access Tools”
Issue
of 1.1
Date
Reference
18/03/2002 GSPS-RTDA-EOAD-SW-02-0001
AD2 Fax received from ESA
07/06/2002 IMT-CR/9021/02/I-LG
AD3 CS SI Proposal "DEBAT"
21/06/2002 CSSI/111-1/CG/LM/2/453-1
AD4 Minutes of Kick-off Meeting
17/09/2002 /CRR/SS/DEBAT/001
–
Space
Engineering
AD5 ECSS
Standards – Software ECSS-E-40B
ECSS-E-40B
AD6 CS SI Proposal for Phase 2
March 2003 CSSI/111-1/CG/PKV/3/140
AD7 Minutes of Phase 2 Kick-off
meeting (Authorisation To Proceed)
30/04/2003 /CRR/SS/DEBAT/006
DEBAT – Development of EAST Based Access Tools
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
: vii
EAST Language Changes
Reference Documents
Title
Issue
RD1 DEBAT - Project Management Plan 1.2
Date
Reference
08/07/2003 SS/DEBAT/PMP
RD2 DEBAT - Product Assurance Plan
1.2
08/07/2003 SS/DEBAT/PAP
RD3 DEBAT –
Document
Requirements
1.2
10/03/2003 SS/DEBAT/URD
RD4 DEBAT – Software Requirements
Document
1.1
10/03/2003 SS/DEBAT/SRD
RD5 DEBAT – Architectural Design
Document
RD6 DEBAT – Interface Control
Document
RD7 The Data Description Language
EAST Specification (CCSD0010).
Blue Book.
1.1
16/09/2003 SS/DEBAT/ADD
1.1
16/09/2003 SS/DEBAT/ICD
2.0
November
2000
CCSDS 644.0-B-2
RD8 The Data Description Language
EAST - A Tutorial. Green Book.
1.0
May 1997
CCSDS 645.0-G-1
RD9 The Data Description Language
EAST - List of Conventions. Green
Book.
1.0
May 1997
CCSDS 646.0-G-1
RD10 Data Entity Dictionary Specification
Language (DEDSL) - Abstract
Syntax (CCSD0011). Blue Book.
1.0
June 2001
CCSDS 647.1-B-1
RD11 Data Entity Dictionary Specification
Language (DEDSL) - PVL Syntax
(CCSD0012). Blue Book.
RD12 Data Entity Dictionary Specification
Language (DEDSL) - XML/DTD
Syntax (CCSD0013). Blue Book.
1.0
June 2001
CCSDS 647.2-B-1
1.0
January
2002
CCSDS 647.3-B-1
User
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue
: 1.0
Date
: 14/10/03
Page
:1
1. Introduction
1.1 Purpose
This document describes the changes made to the EAST language in the frame of the DEBAT
project. The proposed changes guarantee an ascending compatibility of the EAST descriptions
(previous descriptions are compatible with the proposed changes) and do not make any major
change to the main concepts of the current language.
These changes are going to be submitted to the CCSDS panel(s) for review/approval.
1.2 Scope
The current paper gives a preliminary vision of these changes. It does not deal with technical
implementation issues affecting the tools that support the EAST language. It gives examples that
are expected to be self-explanatory.
1.3 Structure of the document
This document is structured as follows:
Chapter 1: Introduction
The current chapter gives the objectives, scope, definitions and structure of the document.
Chapter 1: EAST languages changes
This chapter describes the changes made to the EAST languages starting from the rationale and
detailing the proposed change.
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
:2
1.4 Definitions
Data Model
The data model is the name of the DEBAT Data Modeller internal
format of a data format description. This internal format (often
called IF) contains all the syntactic and semantic information of
the data. It is created, modified and read by the DEBAT Data
Modeller and is used to generate the EAST and DEDSL
description files.
IF
Internal Format: this is the old internal format used by OASIS (the
old Modeller). This file follows an in-house textual formalism that
is difficult to read and handle.
XML-IF
XML-Internal Format: this is the new internal format used by the
Modeller to store the data model information under the form of an
XML document.
EAST description file
The EAST description file contains the syntactic information of a
data model in the EAST format. This file conforms to the EAST
CCSDS recommendation. It is created by the DEBAT Data
Modeller and is used by all the other tools to read, generate,
extract, check data products.
DEDSL description file
The DEDSL description file contains the semantic information of
a data model in the DEDSL format. This file conforms to the
DEDSL CCSDS recommendation. It is created by the DEBAT
Data Modeller and is used by all the other tools when the semantic
information of a data product are managed.
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
:3
2. EAST languages changes
2.1 Version management
2.1.1 Rationale
The goal of this change is to be able to express the version of the EAST recommendation and of
the DEBAT suite of tools in the EAST description. This information is not currently available in the
description, and it could be useful for the tools that need to process this information.
2.1.2 Changes to the EAST language
This change could be implemented as follows:
EAST_VERSION : constant STRING := “1.0”;
DEBAT_VERSION : constant STRING := “2.1”;
The version of EAST/DEBAT is defined before any constant or type declaration (within the
Declaration of Types Section of the logical package) by a STRING constant. Therefore, this change
implies the addition of a reserved word EAST_VERSION/DEBAT_VERSION in the language.
2.2 Default values
2.2.1 Rationale
The goal of this change is to be able to indicate default values for the variables of the
description. This feature is useful (notably for the EAST Data Generator) when generating data
conforming to an EAST description (currently, if a value is not set for a specific field, the EAST
generator raises and error).
NB: This feature has not to be understood as a way to express that if a peculiar field is absent from
a data file, it should take the default value.
2.2.2 Changes to the EAST language
This change could be implemented as follows:
type N1_TYPE is range 0 .. 10 ;
for N1_TYPE'size use 32 ;
type N2_TYPE is range 0 .. 10 ;
for N2_TYPE'size use 32 ;
type USER_ARRAY_TYPE is array (N1_TYPE range <> ) of CHARACTER ;
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
:4
type A_FIELD_TYPE (N1 : N1_TYPE := 0) is record
N2 : N2_TYPE := 1 ;
USER_ARRAY : USER_ARRAY_TYPE ( 1 .. N1 ) ;
end record ;
for A_FIELD_TYPE use
record
N1 at 0 * WORD_16_BITS range 0 .. 31 ;
N2 at 2 * WORD_16_BITS range 0 .. 31 ;
end record ;
subtype ANOTHER_FIELD_TYPE is CHARACTER range '0' .. '9' ;
A_FIELD : A_FIELD_TYPE ;
ANOTHER_FIELD : ANOTHER_FIELD_TYPE := '4' ;
In this example, the field N2 has a default value 2, and the field ANOTHER_FIELD has the default
value 4. When generating data conforming to this description, if no value is set for these fields, the
default values will be generated in the data file.
The default value can only be of integer, real, enumeration, character or string type. It can also be a
constant of the allowed types defined previously in the description.
2.3 Constants and string constants
2.3.1 Rationale
In the current EAST, constants can appear in several places in an EAST description. They have
different meanings and purposes according their location in the description.
Constants can appear in the Section for the Declaration of Types.
They are declared in this section an can be used:
 in type or subtype declarations to the specification of range bounds,
 in constants declarations for the specification of values
 in record type definitions: in this case they have a special meaning: they are used as end
marker for lists.
Constants can appear in the Section for the Declaration of Variables.
 in this case they are also used as end markers for lists.
The following examples show how the constants are currently used.
a) Declaration of constants in the Section for the Declaration of Types
A_CONSTANT : constant STRING := “HELLO”
MIN : constant : 0 ;
MAX : constant := 500 ;
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
:5
b) Use for the specification of range bounds in the Section for the Declaration of Types
type INTERVAL is array (MIN..MAX) of CHARACTER ;
c) Use in constants declarations for the specification of values in the Section for the Declaration of
Types
DOUBLE_MAX : constant := MAX * 2 ;
d) Use in record type definitions in the Section for the Declaration of Types (as end marker for
lists)
type CLIENT_ADDRESS is record
ONE_CHARACTER : CHARACTER ;
END_OF_ADDRESS : constant CHARACTER := ‘$’ ;
end record ;
d) Use in the Section for the Declaration of Variables (as end marker)
PARAGRAPH : SENTENCE; -- SENTENCE is defined previously
END_OF_PARAGRAPH_MARKER : constant STRING := ASCII.CR; -- Carriage return
The goal of this change is to extend the use of the constants in the Declaration of Types Section and
in the Declaration of Variables Section (that is currently limited to the specification of range
bounds) to be able to express the fact that a given component of the data description is a constant.
2.3.2 Changes to the EAST language
The proposed change consists in being able to specify a constant that is part of the data product, but
that has not to be understood and interpreted as a marker indicating the end of a list.
To be able to make the difference between a constant and a constant used as end-marker, the
keyword "constant" is removed from the description.
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
:6
Package logical_ENERGY_SUN_FCSTC000
NULL_CHARACTER : constant STRING := “\0”;
type C_STRING is record
CHR : CHARACTER;
FINAL_ZERO := NULL_CHARACTER;
End record;
…
The FINAL_ZERO field is a string constant set by a string constant name (and it is not an endmarker for a list). In the example, the C_STRING type is a record of two elements (CHR and
FINAL_ZERO): it is not a list of CHR elements ended by a FINAL_ZERO element.
This is different from the following example where the FINAL_ZERO element is used as a list endmarker. In this example, the C_STRING type is a list of CHR elements that ends with the
FINAL_ZERO element.
Package logical_ENERGY_SUN_FCSTC000
NULL_CHARACTER : constant STRING := “\0”;
type C_STRING is record
CHR : CHARACTER;
FINAL_ZERO : constant STRING := NULL_CHARACTER;
End record;
…
2.4 Uniquely identifying elements
2.4.1 Rationale
In a description, some records may contain components whose size (for arrays) or existence
depends on the value of another component, with a discrete type, called a “discriminant”. If this
“discriminant” is not part of the record, it is called a “virtual discriminant”.
The goal of the change is to avoid the possible confusion between two components with same name
used as “virtual discriminants”: in the current EAST, only the last discriminant encountered
before a record is used. This leads to problems, as EAST is sometimes not able to choose the right
discriminant.
2.4.2 Changes to the EAST language
To deal with this problem, one possible solution is to write the whole EAST path for each virtual
discriminant in a description. This information can be written in a comment part of the EAST
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
:7
description or, with a modification of the norm, in the declaration of the “virtual discriminant”. In
the following example, the first solution is used in the R_3 record and the second one in the R_4
record. In the second solution, each dot of the EAST path is replaced by a double underscore. This
second solution also implies a modification of the EAST norm in order to modify the syntax of a
discriminant identifier.
type USER_SIZE is range 0 .. 10 ;
type R_1_TYPE is record
NB : USER_SIZE ;
end record ;
type R_2_TYPE is record
NB : USER_SIZE ;
end record ;
type ELEM_TYPE is digits 2 range 0.0 .. 9.0 ;
type ARRAY_1_TYPE is array (USER_SIZE range <> ) of ELEM_TYPE ;
type R_3_TYPE (VIRTUAL_NB : USER_SIZE := 0) is record
-- VIRTUAL_NB = R_1.NB
ARRAY_1 : ARRAY_1_TYPE ( 1 .. VIRTUAL_NB ) ;
end record ;
type ARRAY_2_TYPE is array (USER_SIZE range <> ) of ELEM_TYPE ;
type R_4_TYPE (VIRTUAL_R_2__NB : USER_SIZE := 0) is record
ARRAY_2 : ARRAY_2_TYPE ( 1 .. VIRTUAL_R_2__NB) ;
end record ;
R_1 : R_1_TYPE ;
R_2 : R_2_TYPE ;
R_3 : R_3_TYPE ;
R_4 : R_4_TYPE ;
In the previous example, the size of ARRAY_1 is given by R_1.NB and the size of ARRAY_2 is
given by R_2.NB. Before this evolution, the EAST core took R_2.NB for both sizes (because it is
the last discriminant encountered before the record containing the array).
2.5 Calculation capabilities
2.5.1 Rationale
The goal of this change is to enhance the descriptive capabilities of the language by adding the
capability to specify computed values for:
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
:8
 Array lengths: the size of an array could thus be discriminated by a computed valued
involving other fields of the description.
 Discriminants: the existence of fields could be thus discriminated by a computed value.
2.5.2 EAST language changes
2.5.2.1 Array lengths
An example is given in the next figure:
In this description, the size of the USER_ARRAY element shall be discriminated by a computed
value (N1 + N2). In the current EAST, this is not possible. This capability is implemented in the
new EAST.
This addition could be implemented as follows:
type N1_TYPE is range 0 .. 10 ;
for N1_TYPE'size use 32 ;
type N2_TYPE is range 0 .. 10 ;
for N2_TYPE'size use 32 ;
type USER_ARRAY_TYPE is array (INTEGER range <> ) of CHARACTER ;
function A_COMPUTED_VALUE return INTEGER is
begin
return A_FIELD .N_1 + A_FIELD .N_2;
end A_COMPUTED_VALUE;
type A_FIELD_TYPE (COMPUTED_USER_ARRAY : A_COMPUTED_VALUE:= 0) is
record
N1 : N1_TYPE;
N2 : N2_TYPE;
USER_ARRAY : USER_ARRAY_TYPE ( 1 .. COMPUTED_USER_ARRAY ) ;
end record ;
for A_FIELD_TYPE use
record
N1 at 0 * WORD_16_BITS range 0 .. 31 ;
N2 at 2 * WORD_16_BITS range 0 .. 31 ;
end record ;
A_FIELD : A_FIELD_TYPE ;
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
:9
Supported operators are: + , - , * , / , ** (exponent), is_odd, is_even, cos, sin, tan, acos, asin, atan,
log, ln, cosh, sinh, tanh, acosh, asinh, atanh, ( , ) , ! (factorial).
2.5.2.2 Discriminants
An example is given in the next figure:
FIRST_DATA, SECOND_DATA, THIRD_DATA, and FOURTH_DATA are discriminated by N1
and N2:
 FIRST_DATA exists if N1 in 0 .. 10
 SECOND_DATA exists if N1 in 11 .. 20
 THIRD_DATA exists only if N1 is in 21 .. 40 and cos(N2)+sin(N2)=0.4
 FOURTH_DATA exists in the other cases
In the current recommendation, the discrimination of FIRST_DATA and SECOND_DATA is
possible, but the discrimination of THIRD_DATA and FOURTH_DATA is not possible.
This feature is implemented as follows:
type N1_TYPE is range 0 .. 60 ;
for N1_TYPE'size use 32 ;
type N2_TYPE is range 0 .. 10 ;
for N2_TYPE'size use 32 ;
subtype FIRST_DATA_TYPE is CHARACTER range 'A' .. 'Z' ;
type SECOND_DATA_TYPE is range 0 .. 25 ;
for SECOND_DATA_TYPE'size use 5 ;
subtype THIRD_DATA_TYPE is CHARACTER range 'A' .. 'Z' ;
subtype FOURTH_DATA_TYPE is CHARACTER range 'C' .. 'S' ;
type A_RECORD_TYPE (VIRTUAL_N1 : N1_TYPE := 0, VIRTUAL_N2 : N2_TYPE) is record
case VIRTUAL_N1 is
when 0 .. 10 =>
FIRST_DATA : FIRST_DATA_TYPE ;
when 11 .. 20 =>
SECOND_DATA : SECOND_DATA_TYPE ;
when others =>
-- (20 < N1 ) & (N1 <= 40) & (NEW1.N2=3) & cos(N2)+sin(N2)=0.4
DEBAT – Development of EAST Based Access Tools
EAST Language Changes
Reference : SS/DEBAT/ELC
Issue.
: 1.0
Date
: 14/10/03
Page
: 10
THIRD_DATA : THIRD_DATA_TYPE ;
-- no condition
FOURTH_DATA : FOURTH_DATA_TYPE ;
end case ;
end record ;
for A_RECORD_TYPE use
record
FIRST_DATA at 0 * WORD_16_BITS range 0 .. 7 ;
SECOND_DATA at 0 * WORD_16_BITS range 0 .. 4 ;
THIRD_DATA at 0* WORD_16_BITS range 0 .. 7 ;
FOURTH_DATA at 0* WORD_16_BITS range 0 .. 7 ;
end record ;
N1 : N1_TYPE ;
N2 : N2_TYPE ;
A_RECORD : A_RECORD_TYPE ;
The condition discriminating THIRD_DATA is expressed in a comment. This part is stored and
computed at runtime by the EAST core.
The following example presents a record structure that is determined by a Boolean condition. This
time the condition is expressed with a function.
type boolean is ( FALSE, TRUE );
.
.
.
function A_COMPUTED_CHOICE return boolean is
begin
return is_even(R1.data);
end A_COMPUTED_CHOICE;
type R1(Virtual_Val1 : A_COMPUTED_CHOICE := FALSE ) is record
case Virtual_Val1 is
when FALSE =>
data1 : Data1Type;
when TRUE =>
data2 : Data2Type;
end case;
end record;
DEBAT – Development of EAST Based Access Tools