DEBAT : Development of EAST Based Access
Tools
EAST current applications technical note
Contract : 16562/02/I-LG
Reference : SS/DEBAT/EAST_TN
Issue : 1.0
Date : 14/01/2003
Prepared by :
Date :
Frederic Berriri
Jérôme Candat
Checked by :
Date :
Maud Granet
Approved by :
Date :
Carlos Guerreiro
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference
Issue
Date
Page
: SS/DEBAT/EAST_TN
: 1.0
: 14/01/2003
:i
Document Status Sheet
Document Title
Document Reference Number
Issue
Revision
Date
1
0
14/01/2003
0
3
12/12/2002
0
2
19/11/2002
0
1
31/10/2002
EAST current applications Technical Note
SS/DEBAT/EAST_TN
Reason for change
First version
Third draft version
Second Draft Version
First Draft Version
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference
Issue
Date
Page
: SS/DEBAT/EAST_TN
: 1.0
: 14/01/2003
: ii
Document Change Records
Document Title
Document Reference Number
Document Issue/Revision Number
Page Paragraph
All
First version
EAST current applications Technical Note
SS/DEBAT/EAST_TN
1.0
Reason for change
EAST current applications Technical Note
Document Title
SS/DEBAT/EAST_TN
Document Reference Number
0.3
Document Issue/Revision Number
Page Paragraph
Reason for change
All
Third Draft Version : inclusion of ESRIN comments
Document Title
Document Reference Number
Document Issue/Revision Number
Page Paragraph
All
Second Draft Version
EAST current applications Technical Note
SS/DEBAT/EAST_TN
0.2
Reason for change
Document Title
Document Reference Number
Document Issue/Revision Number
Page Paragraph
All
First Draft Version
EAST current applications Technical Note
SS/DEBAT/EAST_TN
0.1
Reason for change
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference
Issue
Date
Page
: SS/DEBAT/EAST_TN
: 1.0
: 14/01/2003
: iii
Table of contents
DOCUMENT STATUS SHEET ....................................................................................................... I
DOCUMENT CHANGE RECORDS .............................................................................................. II
TABLE OF CONTENTS................................................................................................................ III
TABLE OF FIGURES ...................................................................................................................... V
ACRONYMS AND ABBREVIATIONS ...................................................................................... VII
APPLICABLE DOCUMENTS ........................................................................................................ X
REFERENCE DOCUMENTS ....................................................................................................... XI
1. INTRODUCTION .......................................................................................................................... 1
1.1 OBJECTIVES ................................................................................................................................. 1
1.2 SCOPE .......................................................................................................................................... 1
1.3 STRUCTURE OF THE DOCUMENT ................................................................................................... 1
2. POSITION OF THE EAST TECHNOLOGY WITHIN THE DATA LIFE CYCLE ............. 3
2.1 MODELLING ................................................................................................................................. 4
2.2 GENERATING/SIMULATING .......................................................................................................... 4
2.3 PROCESSING ................................................................................................................................. 4
2.4 POST-PROCESSING ........................................................................................................................ 4
2.5 DISTRIBUTION .............................................................................................................................. 4
2.6 POSITION OF EAST ...................................................................................................................... 5
3. BACKGROUND INFORMATION.............................................................................................. 6
3.1 THE OASIS TOOL ........................................................................................................................ 6
3.2 THE DATA UPDATE WIZARD (DUW) TOOL ................................................................................. 9
3.3 EAST INTERPRETER AND GENERATOR API ............................................................................... 10
3.4 ASCII_DUMP AND DATA_CHECKER .................................................................................. 10
4. ANALYSIS ................................................................................................................................... 12
4.1 ENVISAT ................................................................................................................................. 12
4.1.1 ENVISAT Basic types ......................................................................................................... 13
4.1.2 ENVISAT Data products general features ......................................................................... 20
4.1.3 MERIS ................................................................................................................................ 29
4.1.4 SCIAMACHY ...................................................................................................................... 33
4.2 CRYOSAT ................................................................................................................................... 38
4.2.1 Cryosat file structure .......................................................................................................... 38
4.3 AMS-2....................................................................................................................................... 44
4.3.1 DATA_CHECKER with ERS products ............................................................................... 47
4.3.2 API checking capabilities and ERS products ..................................................................... 49
5. IDENTIFICATION OF TECHNICAL LIMITATIONS/EVOLUTIONS ............................. 50
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference
Issue
Date
Page
: SS/DEBAT/EAST_TN
: 1.0
: 14/01/2003
: iv
5.1 TYPE LIBRARY ........................................................................................................................... 52
5.2 DEFAULT VALUES ...................................................................................................................... 53
5.3 NON-STATIC CONSTRAINT .......................................................................................................... 53
5.4 EAST PERFORMANCE ................................................................................................................. 54
5.5 FORMAT SPECIFICATION ............................................................................................................. 54
5.6 OASIS GRAPHICAL INTERFACE .................................................................................................. 55
5.7 ELEMENT LOCALISATION PROBLEMS .......................................................................................... 56
5.8 DATA CHECKING ........................................................................................................................ 57
6. EVOLUTIONS AND LIMITATIONS TECHNICAL ANALYSIS ........................................ 58
6.1 TYPE LIBRARY ........................................................................................................................... 58
6.2 DEFAULT VALUES ...................................................................................................................... 58
6.3 NON-STATIC CONSTRAINTS ........................................................................................................ 59
6.4 EAST TOOLS PERFORMANCE ..................................................................................................... 60
6.5 FORMAT SPECIFICATION ............................................................................................................. 61
6.6 ELEMENT LOCALISATION PROBLEMS .......................................................................................... 62
6.7 DATA CHECKING ........................................................................................................................ 63
7. CONCLUSION............................................................................................................................. 65
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference
Issue
Date
Page
: SS/DEBAT/EAST_TN
: 1.0
: 14/01/2003
:v
Table of figures
Figure 2-1 Data life cycle..................................................................................................................... 3
Figure 3-1 OASIS Main window ......................................................................................................... 7
Figure 3-2 OASIS modelling and the EAST/DEDSL norms .............................................................. 7
Figure 3-3 Example of EAST technology use to read data.................................................................. 8
Figure 3-4 DUW tool screenshot ......................................................................................................... 9
Figure 3-5 Output of ASCII_DUMP ................................................................................................. 10
Figure 3-6- Example of the DATA_CHECKER use. ........................................................................ 11
Figure 4-1 ENVISAT Character types ............................................................................................... 13
Figure 4-2 OASIS element model and associated type...................................................................... 14
Figure 4-3 ENVISAT Integer types ................................................................................................... 14
Figure 4-4. ENVISAT Integer type OASIS model. ........................................................................... 15
Figure 4-5 Creating an unsigned integer with OASIS ....................................................................... 16
Figure 4-6 An integer represented in ASCII mode ............................................................................ 17
Figure 4-7 ENVISAT Real types ....................................................................................................... 17
Figure 4-8 ENVISAT Real type OASIS model ................................................................................. 18
Figure 4-9 Real types encoded in ASCII format................................................................................ 19
Figure 4-10 EAST Generator functioning using a format file ........................................................... 19
Figure 4-11 ENVISAT - Data products evolution ............................................................................. 20
Figure 4-12 ENVISAT - Generalised Product Structure ................................................................... 21
Figure 4-13 MPH Keyword modelling with OASIS ......................................................................... 22
Figure 4-14 Quote mark modelling with OASIS ............................................................................... 23
Figure 4-15 Meter unit OASIS modelling ......................................................................................... 23
Figure 4-16 New line Character OASIS modelling ........................................................................... 24
Figure 4-17 Product OASIS model .................................................................................................... 24
Figure 4-18 X_Position OASIS model .............................................................................................. 24
Figure 4-19 Related information groups in the MPH header............................................................. 25
Figure 4-20 Correspondence between OASIS elements and data product contents .......................... 25
Figure 4-21 ENVISAT MPH generic OASIS model ......................................................................... 26
Figure 4-22 ENVISAT generic DSD OASIS model ......................................................................... 28
Figure 4-23 MERIS Data Products .................................................................................................... 30
Figure 4-24 MERIS Data Products tree ............................................................................................. 30
Figure 4-25 MERIS level 1B high-level model ................................................................................. 30
Figure 4-26 MERIS Level 1B product SPH decomposition .............................................................. 31
Figure 4-27 MERIS LEVEL-1B SPH OASIS model ....................................................................... 31
Figure 4-28 MERIS Level-1B Attached Data Sets OASIS model .................................................... 32
Figure 4-29 SCIAMACHY data products ......................................................................................... 33
Figure 4-30 SCIAMACHY data product tree .................................................................................... 34
Figure 4-31 SCIAMACHY high-level OASIS model ....................................................................... 34
Figure 4-32 SCIAMACHY Level1B SPH Descriptors OASIS model .............................................. 35
Figure 4-33 SCIAMACHY SPH Level1B DSDs OASIS model ....................................................... 36
Figure 4-34 SCIAMACHY Level1B Data Sets OASIS model ......................................................... 37
Figure 4-35 Cryosat Level 1B high-level OASIS model ................................................................... 39
Figure 4-36 CRYOSAT SPH descriptors OASIS model ................................................................... 40
Figure 4-37 One DSD OASIS model ................................................................................................. 41
Figure 4-38Another modelling of the DSDs. ..................................................................................... 41
Figure 4-39 Cryosat Level 1B Attached Data Sets OASIS model .................................................... 42
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference
Issue
Date
Page
: SS/DEBAT/EAST_TN
: 1.0
: 14/01/2003
: vi
Figure 4-40 Complete Cryosat Level 1B product file OASIS model ................................................ 43
Figure 4-41 AMS-2 use of the EAST technology.............................................................................. 44
Figure 4-42 User_header model ......................................................................................................... 45
Figure 4-43 Block_adr_descriptor model .......................................................................................... 45
Figure 4-44 ERS_record model ......................................................................................................... 46
Figure 4-45 User_header.dc produced by DATA_CHECKER ......................................................... 48
Figure 4-46 Logbook produced by DATA_CHECKER (extract) ..................................................... 48
Figure 5-1 Type library use for MERIS OASIS models .................................................................... 52
Figure 5-2 Specification of integer and real formats ......................................................................... 54
Figure 6-1 Format included in the EAST core ................................................................................... 61
Figure 6-2 Formats with OASIS generating the FRT file ................................................................. 61
Figure 6-3 - DEBAT data checking ................................................................................................... 63
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference
Issue.
Date
Page
: SS/DEBAT/EAST_TN
: 1.0
: 14/01/2003
: vii
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
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
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
FAQ
FAR
FAT
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
URD
WSDL
WWW
XML
XSL
Reference
Issue
Date
Page
: SS/DEBAT/EAST_TN
: 1.0
: 14/01/2003
: viii
Frequently Asked Question
Factory Acceptance Review
Factory Acceptance Tests
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
User Requirements Document
Web Service Description Language
World Wide Web
eXtensible Mark-up Language
eXtensible Stylesheet Language
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
XSLT
Reference
Issue
Date
Page
: SS/DEBAT/EAST_TN
: 1.0
: 14/01/2003
: ix
eXtensible Stylesheet Language Transformation
DEBAT – Development of EAST Based Access Tools
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
:x
EAST current applications
Technical Note
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
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: xi
Reference Documents
Title
Issue
Date
Products
3
16/10/1997
RD1 ENVISAT-1
Specifications. Volume 5 : Products
Structures
Products
3
20/11/2000
RD2 ENVISAT-1
Specifications. Volume 16 :
Auxiliary Data Files
Products
3
27/05/97
RD3 ENVISAT-1
Specifications. Annex A : Product
Data Conventions
Products
3
20/11/2000
RD4 ENVISAT-1
Specifications. Volume 11: MERIS
Products Specifications
Products
3
13/11/2000
RD5 ENVISAT-1
Specifications. Volume 15 :
SCIAMACHY
Products
Specifications
RD6 CRYOSAT Ground Segment. 1.9 12/07/2002
Instrument Processing Facility L1b.
1.0 01/07/2002
RD7 IPF1 Detailed Processing Model
RD8 DEBAT - EAST TM/TC Technical 1.0 14/01/2003
Note
RD9 DEBAT - Requirements Collection 1.0 14/01/2003
Technical Note
Archive
Management 1.2 04/04/2000
RD10 AMS-2
System.
Architectural
Design
Document
Archive
Management 1.0 18/05/1999
RD11 AMS-2
System. Product Formatting and
Sub-setting technical note.
Reference
PO-RS-MDA-GS-2009
PO-RS-MDA-GS-2009
PO-RS-MDA-GS-2009
PO-RS-MDA-GS-2009
PO-RS-MDA-GS-2009
CS-RS-ACS-GS-5106
CS-TN-ACS-GS-5105
SS/DEBAT/TMTC_TN
SS/DEBAT/RC_TN
AMS-2/ADD_001
AMS-2/TN-005
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
:1
1. Introduction
1.1 Objectives
This document takes place in the frame of the DEBAT (Development of EAST Based Access
Tools) project. DEBAT is aimed at building a set of enhanced tools based upon the EAST
technology to support the entire data life cycle for various kind of users.
This study comes as a companion of the “EAST for TM/TC processing technical note” [RD8]
study. The goal of this study is to determine if the EAST language and associated tool (i.e. OASIS)
are capable of modelling high-level data products extracted from raw data. To achieve this goal,
this study is based on the following products :
 ENVISAT,

CRYOSAT,

AMS2 (ERS data).
1.2 Scope
This document presents the “EAST current applications technical note” study, which describes how
ENVISAT and CRYOSAT data products can be modelled with EAST/OASIS. Regarding AMS2
data (ERS products), the study is mainly focused on the improvements of the data checking
capabilities of EAST technology.
This document also details the EAST/OASIS technical limitations encountered while modelling
these products and presents the associated solutions.
1.3 Structure of the document
The chapter “Position of EAST technology within the data life cycle” introduces the potential use
of the different EAST tools from the specification stages to the operational processing of data.
The chapter “Background Information” presents the EAST tools used in the frame of this study.
The chapter “Analysis” details the following data products and explain how they can be modelled
with the actual EAST/OASIS technology :
 ENVISAT,

CRYOSAT,

AMS2 (Archive Management System).
The chapter “Identification of technical limitations/evolutions” details all the EAST/OASIS
weaknesses encountered while modelling the data products in the previous chapter. It also
establishes all the updates required to solve the encountered EAST/OASIS limitations.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
:2
Finally, the chapter “Evolutions and limitations technical analysis” performs a technical analysis
of the potential solutions able to solve the problems encountered when modelling data products with
EAST technologies.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
:3
2. Position of the EAST technology within the data life cycle
A generic data life cycle is composed of five successive stages:
1.
2.
3.
4.
5.
Modelling,
Generating/Simulating,
Processing,
Post-processing,
Distribution.
The DATA is produced
at the end of the
generating/simulation
phase.
1
2
Modelling
Generating /
Simulation
DATA
The DATA is used as
input of the postprocessing phase.
4
Processing
5
PostProcessing
Distribution
3
PROCESSED
DATA
MODEL
Figure 2-1 Data life cycle
The arrow on the left (between Modelling and Model) explains the fact that the model is created as
output of the first phase but can be modified later if problems are detected during the following
phases.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
:4
2.1 Modelling
The aim of this phase is to specify a non ambiguous, exhaustive, understandable, evolutionary
description of the data according to two points of view:
 the syntactic aspect of the data describing the structure of the data (logical and physical).

the semantic aspect of the data describing the “metadata” associated to the data, giving it a
sense (i.e. unit, physical meaning, alias).
2.2 Generating/Simulating
The following phase consists in generating data based on the model developed in the first phase. It
allows the validation of the model. This phase shall be automated to simplify and accelerate the data
products generation for simulation.
2.3 Processing
Once the data has been generated, it is important to validate the model. It is then useful to be able to
edit and check the data using the model. As a result, the model defined in the first phase may be
modified. User can also modify the information read in the data product. For example, they may
want to use the data product to test an application with specific values.
Furthermore, users may only be interested in data subsets. The extracting and querying
functionalities are then used to extract information from a data product. The subsets thus created
correspond to a subset of the defined model.
All of these functions shall be platform independent to be able to process heterogeneous types of
data. These functions may process both syntactic and semantic information.
This phase is not mandatory since the data generated can be used as such for the following phase or
for simulation purposes.
2.4 Post-processing
This phase concerns all domain-oriented processing.
Data product content can then be transformed (some values can then be calculated upon two or
more other values in the data product) and/or processed using domain-oriented tools. The data
produced in this part may not follow the model anymore.
This last phase then leads to the production of synthesised data that can be either human-legible or
directly interpretable using an auxiliary tool (e.g. using a image viewer tool).
2.5 Distribution
The goal of this part is to distribute the processed data to end-users.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
:5
It includes any means (e.g. CD-ROM, Internet) that can be used to present the data products to
users.
2.6 Position of EAST
EAST technology can be used in most of the phases previously mentioned. The following table
summarises the applicable tools for each phase.
Phase
Modelling
Generating & simulating
Processing
Post-processing
Distribution
Associated EAST tools
OASIS
DUW (rather limited) & APIs
APIs (rather limited) & Data_Checker
-
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
:6
3. Background information
This chapter provides some background information about the EAST technology and tools so as to
allow the reader to easily understand the concepts handled in this study.
East technology is mainly composed of the following tools :
Tool
Main functionality
OASIS
OASIS is a front-end GUI tool providing syntactic and semantic description
of data and generating EAST and DEDSL (PVL) descriptions as outputs. It
offers:
 A structural aspect: tree-like view where the nodes are structure entities
(arrays, lists, discriminates, …) and the leaves are the data values.

A syntactic aspect: physical description (data type, limits,…).

DUW
A semantic aspect: the meaning of the data (associated units, real
meaning,…).
DUW is a front-end GUI tool allowing the production/modification of data
files according to an EAST description.
 It allows to display the values of a data file in a tree view following an
EAST description,

It offers some generation schemes of simulated (random values, fixed
values),

It provides support for modifying the value of a given value in a data
file.
INTERPRETER & Low level APIs that provide services for reading and writing data files
according to an EAST description.
GENERATOR
DATA_CHECKER Command-line tools that check a data file (DATA_CHECKER) and
& ASCII_DUMP generate an ASCII representation of a data file (ASCII_DUMP) according
to an EAST description.
Each tool is further detailed in the following sections.
3.1 The OASIS tool
OASIS is an EAST tool that enables data modelling and description. This tool was designed for
space data description and modelling, but its utilisation can be extended to any kind of data. The
data description is built as a hierarchic tree and the knowledge of the EAST (ADA-like) syntax is
not mandatory.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Main window
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
:7
Implantation window (view as byte flow)
Information
window
Syntactic
information
Semantic
information
Data model window (view as hierarchic tree)
Figure 3-1 OASIS Main window
Users can at the same time describe the syntactic and semantic aspect of the data with OASIS.
DATA file
OASIS
Syntactic
description in
the EAST
language
EAST tools
Semantic
description in
the DEDSDL
format
DEDSL
Processor
Extracted
information
OASIS model
Documentation
about the data
elements
Figure 3-2 OASIS modelling and the EAST/DEDSL norms
It is to be noted that even if EAST/OASIS can model any kind of data, there are many things that
the users have to know before choosing EAST technology to model their data. Indeed, it is often
better to think of the EAST modelling before really specifying the data contents since OASIS offers
many ways to express the same features of a data product. In fact, there is more than one way to
model the data. The modelling phase is thus very important since it will be used as a basis for
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
:8
further processing. A non-optimised model could then result as an increase of the response
times in all other EAST tools.
Some important recommendations could be given (“best practices”) to model data with OASIS :
1. The data product shall only contain data of interest. The semantic information are to be
entered by the user in the OASIS tool and managed using the DEDSL norm. Of course, the
data product is not directly human-legible using a text editor but it will greatly reduce the
size of the product and then leverage the performance of the processing with the EAST
tools. The other OASIS tools like the DUW are then here to enable users to read the data
content.
For example, the ENVISAT and CRYOSAT products contain a lot of constant data (e.g.
keyword, quotation mark, equal sign). Of course, the product files are human-readable but
this leads to huge data products files whereas only few information are of interest for a thirdparty application. Separating the syntactic and semantic information insures that the data
could be easily modelled and manipulated (since the data content is simplified and small)
and that users could also understand the significance of the information read in the data file.
Actually, it is often better to think about the OASIS model before specifying the data
product content so that only relevant information is modelled with OASIS.
2. EAST tools can be used from third-party applications trough the API provided. This time,
users must be particularly careful about the type they give to their data. If an element is
declared as an integer, then the EAST API will return an integer to the calling application.
But if this element is modelled as a string, the EAST API will return the value as a string
element and it will be up to the application to convert it from string to integer (see example
below). Choosing convenient types for the elements will then reduce the size of
programs and speed up the development process.
Data File
1254
12.569e+20
…
OASIS model
Field1 : String
Field2 : String.
…
EAST interpreter
Application
Read Field1 value in the data file and
convert the string read to Integer to
use it.
Read Field2 value in the data file and
convert it to a real element.
Figure 3-3 Example of EAST technology use to read data
In the previous figure, the first integer value (i.e. 1254) has been modelled as a String. The
same way, the following real value (i.e. 12.569e+20) has been also modelled as a String.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
:9
The main problem here is that EAST will read the data and present it to the application as
String elements. It will then be up to the application to convert these elements to the integer
or real types to be able to manipulate the values. It then induces a huge overhead in the
application code and also at runtime.
The good solution is to model the parameter as an integer (or a real) and to specify to
OASIS that this parameter has to be encoded in an ASCII form. This way, the value
returned to the calling application will be directly received as an integer (or a real).
3.2 The Data Update Wizard (DUW) tool
DUW can generate simulated data depending on an EAST description.
Functions to
manipulate the
tree structure.
Operation selection
Depending on the
operation selected,
users have to select
input and output files
Access to the main
functionalities of
the tool.
Tree structure corresponding to the
model selected
Figure 3-4 DUW tool screenshot
DUW is a front-end GUI tool allowing the production/modification of data files according to an
EAST description.
 It allows to display the values of a data file in a tree view according to an EAST description,

It offers some generation scheme of simulated data according to an EAST description (random
values, fixed values),

It provides support for modifying the values of a given data file.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 10
3.3 EAST Interpreter and Generator API
The Interpreter and the data Generator are two low-level API the EAST tools suite offers to
develop an application which needs to read/write data. They are available for different languages :
ADA, C and FORTRAN. They both have a set of functions and procedures to read, check and write
some data according to an EAST description. The interpreter offers some services to read or check
the data. This data can be read in a file or directly addressed in the memory. The generator offers
several services to write the data according to an EAST description.
3.4 ASCII_DUMP and DATA_CHECKER
Both command-line tools are based on the Interpreter API and have three common inputs : the
name of the EAST description file, the name of the data file and the name of the result file.
ASCII_DUMP generates an ASCII representation of binary data files. It produces a file
containing one line per field of the data file. On this line, are indicated the name of the field
(complete EAST pathname ) and the corresponding value read in the data file. This value is written
in an ASCII format. This tool is very useful in the debugging or validating phases.
---------------------------------------DUMP INFORMATIONS
Execution Directory : C:\EAST_3.2.7\bin
Data File Name : telemetry3.data
DDR File Name : telemetry3.eas
DDR Informations :
---------------------------------------Dump Generation Date :
2002/ 10/ 17: 40963.710967606
---------------------------------------Dump of Block
1
VERSION : 3
HEADER.DATE.DAY : 34542
HEADER.DATE.SECOND : 4665
HEADER.DATE.MILLISECOND : 5.988855859E+004
HEADER.SENSOR : S2
DATA.NB_ELETS : 2
DATA.LOCALIZATION.ANGLE : 1.1635603904724
DATA.LOCALIZATION.DISTANCE : 5.682281250E+005
DATA.DATA_S2(1) : 534
DATA.DATA_S2(2) : 402
BLANC : 3
Figure 3-5 Output of ASCII_DUMP
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 11
The DATA_CHECKER checks the conformity of a data file with respect to its EAST
description. It produces a file containing the errors found in the data file. It first asks for the
maximum number of errors to detect and the number of the first block (in an EAST sense) where to
start the checking. If errors are detected, the DATA_CHECKER will display a message indicating
the number of errors.
Figure 3-6- Example of the DATA_CHECKER use.
To have further information about the detected errors users have to open the result file. It indicates,
for each wrong value, the complete field EAST path and the value read in the data file.
---------------------------------------DUMP INFORMATIONS
Execution Directory : D:\EAST\bin
Data File Name : check.data
DDR File Name : test_checker.eas
DDR Informations :
---------------------------------------Dump Generation Date :
2002/ 11/ 21: 48622.896748590
---------------------------------------Check of Block
1
RECORD.AN_INTEGER ascii value --> '999'
RECORD.AN_ENUMERATION ascii value --> '03
'
Note : The data checking can also be done programmatically since the EAST API offers some
checking services. In fact, the EAST API checking functions have been developed specifically for
the DATA_CHECKER tool.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 12
4. Analysis
This chapter is mainly interested in modelling the data products from the following projects :
 ENVISAT (i.e. MERIS and SCIAMACHY data products),

CRYOSAT,

AMS2 (ERS data products).
The analysis performed in this chapter will allow to determine if the EAST technologies can be
successfully applied to the modelling of such data products.
The chapter “ENVISAT” describes the ENVISAT mission and the associated data products. It also
explains how data is refined from raw data to produce directly interpretable data.
The chapter “CRYOSAT” describes the Cryosat data product structures and their associated
OASIS models.
The chapter “AMS2” introduces the AMS2 mission and explain how data products can be checked
with the current EAST/OASIS technology. It also identifies the areas of improvements of the
checking capabilities of EAST.
4.1 ENVISAT
The ENVISAT mission has been defined to endow Europe with enhanced capability to:
 monitor and study the Earth’s environment and climate changes,

manage and monitor the Earth’s resources,

develop a better understanding of the structure and dynamics of the Earth’s crust and interior.
The goal of this section is to model the ENVISAT data products using the OASIS tool and detect
any lacks/weaknesses that may appear in this process.
The first part called “ENVISAT Basic Types” introduces the ENVISAT basic types and their
associated OASIS model.
The second part called “ENVISAT Data Products General Features” describes the common
characteristics of all ENVISAT data products.
Nine instruments have been placed onboard the ENVISAT-1 satellite, but only two of them are
studied here: MERIS and SCIAMACHY. These data products have been chosen because they are
considered to be representative enough of the complexity of all ENVISAT data products. We make
the assumption that if we succeed in modelling these data products, the other ones could be
modelled with no peculiar problems.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 13
Thus, the third part introduces MERIS data products and details their associated OASIS models
while the fourth part finally details the SCIAMACHY data products and presents their associated
OASIS models.
4.1.1 ENVISAT Basic types
This section explains how all ENVISAT basic data types can be modelled with OASIS. These types
are re-used in all ENVISAT data products (whatever the instrument). Therefore, it is very important
to be able to model these types before modelling any data product.
According to the [RD3] document there are three basic types in ENVISAT:
 Character,

Integer,

Real.
Each type is further detailed in the following sections. Each time the associated OASIS models are
described.
4.1.1.1 Character
The ENVISAT Character type is divided into two subtypes whether it is signed or not.
Variable Type
Character
Type
Char
Abbreviation
sc: signed char
uc: unsigned char
Range
-128 to 127
0 to 255
Figure 4-1 ENVISAT Character types
Note : The Variable Type column stands as the name of the type. The Type represents the type
name in the C programming language. The Abbreviation column represents the name used in all
ENVISAT documents to reference these types. The Range column represents the values this type
can take.
It is to be noted that the String type is simulated in ENVISAT by an array of Character elements.
The String type is furnished natively in OASIS.
The two ENVISAT Character subtypes can be easily modelled with OASIS.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 14
Figure 4-2. ENVISAT Character type modelled using the native OASIS character type.
As shown in the upper figure, the user can specify a type name for this element (i.e.
CHARACTER_TYPE here). This type could then be re-used to type other elements in the current
model. The type information appears just under the element name in the OASIS tree model.
Figure 4-2 OASIS element model and associated type
4.1.1.2 Integer
The Integer is divided into six subtypes according to their sizes and signs .
Variable Type
2 byte integer
Type
short
4 byte integer
long
8 byte integer
long long
Abbreviation
Range
ss: signed short integer
-32768 to 32767
us: unsigned short integer 0 to 65535
sl: signed long integer
-2147483648
to
2147483647
ul: unsigned long integer 0 to 4294967295
sd: signed long long -9223372036854775808
integer
to
9223372036854775807
ud: unsigned long long 0
to
integer
18446744073709551615
Figure 4-3 ENVISAT Integer types
As OASIS offers Integer as a native type, all of the ENVISAT Integer subtypes can be easily
modelled with OASIS.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 15
The range of the
Integer can be specified
by
the
user
or
calculated by OASIS.
As for character
type, EAST can
handle binary and
ASCII integers.
The size of the field can be
fixed by users or OASIS can
also make the calculation.
Figure 4-4. ENVISAT Integer type OASIS model.
Though all basic ENVISAT Integer types can be modelled, the OASIS graphical interface is
somewhat disconcerting especially when creating unsigned elements. Actually, to create unsigned
integers (i.e types called ul and ud in the previous table), users have to select the Full Range option
and type zero in the Begin field though this latter is visually disabled.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 16
The Full Range
option
is
selected here.
These fields look
like
they
are
disabled though a
value
can
be
entered in the
Begin field (i.e. 0
here).
Figure 4-5 Creating an unsigned integer with OASIS
As a result, the Integer element presented in the upper figure could then take any value from zero to
232-1. Of course, the type is generated with the correct values in the EAST description file :
type AN_INTEGER_TYPE is range 0 .. (2**32) -1 ;
for AN_INTEGER_TYPE'size use 32 ;
Note: It is to be noted that all elements in a description will be typed during the EAST description
generation phase under OASIS. In the upper figure, the type of the element has been left blank but
an associated type has been automatically created (i.e. called AN_INTEGER_TYPE in the above
EAST code example).
Until now in this clause, the Integer types have been represented as binary. However the encoding
can also be in ASCII mode. This time, the range of the elements will be shorter since a number is
represented by one octet. For example, the short integer type (signed and unsigned) will be
represented in the following way :
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 17
Figure 4-6 An integer represented in ASCII mode
An element with this type could then take the values from -99999 to +99999 since the sign is
included in the definition of the Integer (and takes one octet in size).
4.1.1.3 Real
The Real type is composed of two subtypes according to its precision .
Variable Type
Type
4-byte single precision float
floating point
8-byte double precision double
floating point
Abbreviation
fl
do
Range
3.4028e+38 (max)
1.17549e-38 (min)
1.79e+308 (max)2.22e308 (min)
Figure 4-7 ENVISAT Real types
OASIS offers the Real type natively so that both subtypes can be easily modelled with OASIS.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 18
The range of this element
Relative precision
Representation and size
Figure 4-8 ENVISAT Real type OASIS model
An error have been detected with real elements and the way OASIS generate the associated EAST
code. Indeed, the resulting EAST description file is not compliant with the EAST norm since the
exponent (i.e. symbolized by the e character in the code below) should be uppercase.
type A_REAL_TYPE is digits 6 range 1.17549e-038 .. 3.4028e+038 ;
for A_REAL_TYPE'size use 64 ;
As a result the DUW tool displays an error when trying to read the EAST description generated by
OASIS and the EAST description file is then not usable.
Furthermore, real elements can also be encoded in ASCII mode with OASIS. This time, the sign
and the exponent (and its associated sign) will be considered as characters. For example, to model a
single precision floating point element, we will need fifteen bytes : SX.XXXXXXXXESXX where
S is the sign, E stands as the exponent and X is a digit in ASCII format from 0 to 9.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 19
To create this type, the ASCII encoding has to be selected and the size has to be set to fifteen :
Figure 4-9 Real types encoded in ASCII format
However, it is not possible with OASIS to specify a format for a real element (encoded in
ASCII). It is then not possible to precise the number of digit before and after the dot. It is not a
problem when the description is used to read a real element in a data file but becomes a problem
when generating data since the relative precision is not used by any EAST tool.
However, a functionality is provided by the EAST generator to solve this problem. Currently, users
have to write an ancillary file which contain the definition of the formats for the elements that will
be used as input of the EAST generator to produce data in the correct format.
Ancillary file
describing elements
formats.
Type_Name1 SF2.3
Type_Name2 F4.4
EAST Descriptive
EAST Generator
Data generated in the
right format.
+33.256
4256.6598
…
Figure 4-10 EAST Generator functioning using a format file
The elements are identified using their types. In the upper figure, the string SF2.3 means that the
real to be generated begins with a sign and have two number before the dot and three after (e.g.
+33.256). However, this mechanism is usually tedious, time consuming and can easily lead to
errors.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 20
4.1.2 ENVISAT Data products general features
The ENVISAT data products are developed from the raw instrument data in several stages .
Level 2 product
Type A
Level 2 product
Type N
Browse Product
Level 1 B product
Level 0 product
Processing using specific algorithms
RAW
Figure 4-11 ENVISAT - Data products evolution
The Raw data is not considered as a product and its structure is not defined in the ENVISAT
documents.
The Level-0 product contains Annotated Instrument Source Packets (AISPs) as received from the
instrument. Each Data Set record also contains a time stamp that gives the onboard sensing time of
that packet.
Level-1B products are geolocated engineering foundation products in which data has been
converted to engineering units, auxiliary data has been separated from measurements and selected
calibrations applied to the data.
The Level-0 product is transformed into a Level-1B product by application of algorithms and
calibration data to form a baseline “engineering product”. The Level-1B product is then transformed
into one or more Level-2 products through higher-level processing to convert engineering units into
geophysical quantities to form a directly interpretable and useful measurement data set.
Browse products are severely decimated images.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 21
All of the upper ENVISAT products follows the same basic structure whatever the instrument
producing the data. This structure consists of three main parts:
 A Main Product Header (MPH) which is in ASCII format and contains information common to
all ENVISAT instruments (e.g. identification, orbit, position).

A Specific Product Header (SPH) which is also in ASCII format and contains information
describing a specific product. Thus, it will vary between instruments and between different
products for each instrument. It will also contain Data Set Descriptors (DSD) used to point to
and describe the Data Sets making up a product.

One or more Data Sets (DS) which are in mixed ascii-binary format and consist of one or more
records.
MPH
SPH
ASCII format
DS Descriptor #1
DS Descriptor #2
…
…
DS Descriptor #N
Record #1
…
Record #1
Mixed ASCIIbinary format
…
Record #1
…
Data Set #1
Data Set #2
Data Set #N
Figure 4-12 ENVISAT - Generalised Product Structure
4.1.2.1 Main Product Header
The MPH identifies the product and its main characteristics. It is of fixed length and format for all
products.
The ENVISAT [RD1] document clearly describe (i.e. types and sizes are defined) all single
elements composing the MPH header which can be re-used for all instruments in the frame of the
ENVISAT mission. The MPH is then produced in ASCII format using a keyword-value<units>terminator approach like in the following example :
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 22
PRODUCT="MER_RR__1PTACR20000620_104318_00000104X000_00000_00000_0000.N1"
PROC_STAGE=T
X_POSITION=-7162215.231<m>
Each line can be modelled under OASIS using a record. It has been chosen to group the keyword
and the equal sign together to simplify the description and since it is not the data of interest here. To
be able to easily read and write data products, these elements will then be modelled as an
enumeration having only one value. For example, the first keyword shown in the example above
will be modelled a such:
There is only one element
in the enumeration here.
The size of the element is
fixed
A value is given for a
particular element of the
enumeration
Figure 4-13 MPH Keyword modelling with OASIS
The quotation mark has to be modelled on its own since it is not possible to have a quote in a
enumerated value. Indeed, a part of the corresponding EAST code is the following :
REPRESENTATION => ( "PRODUCT=") )
As shown, the value is surrounded by two quotation marks. If a quotation mark was present in the
value of the enumeration, the other EAST tools like the DUW couldn’t read the description file.
The main problem here is that OASIS doesn’t detect this as an error. This way, users can put
quotation marks in an enumeration value without OASIS detecting the problem. Moreover,
OASIS will generate the corresponding EAST description file without any error. Of course,
this EAST description is not usable useless since the other EAST tools cannot read and exploit it.
The quotation mark has therefore to be modelled on its own as a single character.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 23
Figure 4-14 Quote mark modelling with OASIS
As a following, the value will be modelled. Of course, depending on its type, it will be coded either
as an integer, as a string, etc… In the first line of the above example, the value will be modelled as a
string with a size of 62 octets while the third line value will be modelled as a float having an ASCII
representation.
Then, the unit has to be modelled. To be able to generate correct units, it has been chosen to model
this element as an enumeration having one possible value.
Figure 4-15 Meter unit OASIS modelling
Finally, the terminator is here represented by the new line character. It will then be modelled as a
single character with the correct ASCII code.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 24
Figure 4-16 New line Character OASIS modelling
As a conclusion, the first line of the example will be modelled as a record containing the following
elements:
PRODUCT="MER_RR__1PTACR20000620_104318_00000104X000_00000_00000_0000.N1"
Figure 4-17 Product OASIS model
The same way, the third line of the example will be modelled like :
X_POSITION=7162215.231<m>
Figure 4-18 X_Position OASIS model
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 25
Furthermore, to simplify the model, related information have been tied together in groups. In the
MPH header, eight groups have been defined.
MPH
Product
Identification
Information
Data
Acquisition
and
Processing
information
Time of data
information
Envisat
SBT to UTC Leap second
orbit and
conversion information
position
information
information
Product
confidence
data
information
Product size
information
Figure 4-19 Related information groups in the MPH header
The following figure establishes a relation between real elements that can be found in any
ENVISAT data product and the groups defined in the upper table :
Data product file content
PRODUCT="MER_RR__1PTACR20000620_104318_00000104X000_00000_00000_0000.N1"
PROC_STAGE=T
REF_DOC="PO-RS-MDA-GS-2009_3/B "
ACQUISITION_STATION="ENVISAT SampleData#4"
PROC_CENTER="F-ACRI"
PROC_TIME="22-FEB-2000 23:59:42.000000"
SOFTWARE_VER="MEGS/4.3 "
SENSING_START="20-JUN-2000 10:43:18.219360"
SENSING_STOP="20-JUN-2000 10:45:02.234592"
PHASE=X
CYCLE=+000
REL_ORBIT=+00000
ABS_ORBIT=+00000
STATE_VECTOR_TIME="20-JUN-2000 10:06:52.269120"
DELTA_UT1=+.000000<s>
X_POSITION=-7162215.231<m>
Y_POSITION=+0208912.061<m>
Z_POSITION=-0000004.200<m>
X_VELOCITY=+0056.067000<m/s>
Y_VELOCITY=+1629.960000<m/s>
Z_VELOCITY=+7377.421000<m/s>
VECTOR_SOURCE="00"
Corresponding group
These elements (including the last
blank line) is grouped in the
Product
Identification
Information record; each element
following the keyword-value<units>-terminator approach.
These elements are gathered in the
Data Acquisition and Processing
group.
These elements are grouped in the
Time of Data group.
These fields are grouped in the
SBT To UTC Conversion group.
UTC_SBT_TIME="20-JUN-2000 06:29:50.343648"
SAT_BINARY_TIME=+0000000000
CLOCK_STEP=+3906250000<ps>
These elements are grouped in the
Leap Second Information group.
Figure 4-20 Correspondence between OASIS elements and data product contents
Each group will be modelled as a record containing one or more fields (see figure below). Creating
groups also ease the correction and modification of the model.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 26
The following figure fully models the contents of the MPH:
Figure 4-21 ENVISAT MPH generic OASIS model
This model can then be re-used to model any ENVISAT data product. The model above is quite
large and only represents the MPH header. This is because non relevant information such as
keywords or new lines have been modelled along with the information of interest. The model is
then three to four times bigger than it should be.
It is a problem with the EAST technology for three main reasons :
 The MPH is tedious to model with OASIS and could lead to many errors.
 The EAST interpreter will then take more time to read and interpret the model.
 It will finally slow down the data reading/generating.
The keyword-value-<units>-terminator concept is convenient because data products are
human-legible but isn’t really adapted to an EAST automatic processing.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 27
4.1.2.2 Specific Product Header
The SPH is included with every product. It contains information specific to the product itself,
which means that its structure is specific to each data product. It may contain information applying
to the whole product as well as relevant processing parameters.
An OASIS model has to be constructed to represent the SPH for every data product. There will be
as many SPH OASIS models as possible data products. This study doesn't exhaustively describe
and model all possible SPH : it has been chosen to model the most relevant SPHs both for MERIS
and SCIAMACHY.
The construction of these SPH is also based on the keyword-value-<units>-terminator approach.
Exactly as in 4.1.2.1, related information will be tied together to form high-level groups.
Furthermore, one SPH must may contain at least one Data Set Descriptor (DSD). The DSD
structure is fixed for all ENVISAT data product which means that it can be easily modelled once
and reused for all data product.
4.1.2.2.1
Data Set Descriptor
A Data Set Descriptor is used to describe an attached Data Set or to provide references to external
files relevant to the current product (e.g. ancillary data used in processing but not included with the
product). There must be exactly one DSD per Data Set or per reference to an external file.
The DSD is also in ASCII format and its structure (i.e. format and size) will be the same for all
products and all instruments. The ASCII formats conventions are the same as those used to model
the MPH (see 4.1.2.1). As such, the DSD can be easily modelled with OASIS (see OASIS model
below) and re-used.
For example, the following elements have been modelled as :
DS_NAME="Quality ADS
"
DS_TYPE=A
FILENAME="
DS_OFFSET=+00000000000000011189<bytes>
DS_SIZE=+00000000000000000165<bytes>
NUM_DSR=+0000000005
DSR_SIZE=+0000000033<bytes>
DEBAT – Development of EAST Based Access Tools
"
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 28
Figure 4-22 ENVISAT generic DSD OASIS model
This model could then be re-used for any Data Set Descriptor in all ENVISAT data products
without any changes.
4.1.2.3 Data Set
The Data Sets contains the data of interest. It is composed of Data Set Records (DSR) whose
number depends on the product type. Furthermore, the size of the Data Sets may vary within a
product.
Two types of Data Sets have been defined in ENVISAT :
 Measurement Data Sets (MDS) which consists of records containing instrument or processed
data and

Annotation Data Sets (ADS) which consists of records containing auxiliary data.
The Data Set is in a mixed ASCII-Binary format. It may then consist of integers, floats, characters
and ASCII strings at the same time.
The Data Set structure is different from one level to another and from one instrument to another.
They have thus to be modelled case by case.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 29
4.1.3 MERIS
The Medium Resolution Imaging Spectrometer (MERIS) instrument produces multi-spectral
images obtained in a downward viewing push broom imaging manner.
MERIS measurement data are used to derive information including :
 Ocean colour parameter in open and coastal water (e.g. chlorophyll),

Characteristics of clouds,

The presence of vegetation,

Atmosphere parameters (e.g. aerosol type).
The MERIS instrument may operate at Full Resolution (FR) or at Reduced Resolution (RR). RR
data is acquired on a global basis whereas FR data is acquired regionally by direct reception.
As shown in 4.1.2, relevant data are extracted from the raw data to obtain directly interpretable data
products. The first part here will detail all possible data products used with MERIS to obtain legible
data.
Furthermore, as part of the ENVISAT project, all MERIS data products have the same format (see
4.1.2). The second part here will then explain how MERIS specific information are modelled in the
SPH and DS parts (the MPH and DSD are common to all ENVISAT instruments).
4.1.3.1 MERIS data products
To extract the relevant information from raw data, twelve data products have been defined for
MERIS.
Instrument / mode
MERIS / RR
Product ID
MER_RV__0P
MER_CA__0P
MER_RR__0P
MER_RR__1P
MER_RR__2P
MER_LRC_2P
MER_RRC_2P
Description
MERIS Level 0 Reduced Field of
View
MERIS Level 0 Calibration (all
calibration modes)
MERIS Level 0 Reduced Resolution
Reduced Resolution Geolocated and
Calibrated TOA Radiance.
Reduced Resolution Geophysical
Product for Ocean, Land and
Atmosphere.
Extracted Cloud Thickness and Water
Vapour for Meteo Users.
Extracted Cloud Thickness and Water
Vapour (non-Meteo Users). Level 2
product extracted from MER_RR__2P
(Cloud thickness and water vapour
content at nominal RR resolution) for
NRT distribution.
DEBAT – Development of EAST Based Access Tools
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 30
EAST current applications
Technical Note
MER_RRV_2P
Extracted Vegetation Indices. Level 2
product extracted from MER_RR__2P
(Vegetation
indices
including
atmospheric corrections for selected
land regions) for NRT distribution.
Browse (covers FR and RR
requirements).
MERIS Level 0 Full Resolution
Full Resolution Geolocated and
Calibrated TOA Radiance.
Full Resolution Geophysical Product
for Ocean, Land and Atmosphere.
MER_RR__BP
MERIS /FR
MER_FR__0P
MER_FR__1P
MER_FR__2P
Figure 4-23 MERIS Data Products
As explained in 4.1.2, high-level products are derived from lower level products.
MER_RRC_2P
MER_LRC_2P
MER_RRV_2P
Level 2 Products
MER_RR_BP
MER_RV_0P
MER_RR_2P
MER_FR_2P
MER_RR_1P
MER_FR_1P
MER_RR_0P
MER_FR_0P
Level 1 Products
MER_CA_0P
Level 0 Products
Figure 4-24 MERIS Data Products tree
Due to the important number of data products defined here, it is not possible to model them all in
the frame of this study. Therefore, only the MER_RR_1P data product will be studied in the
following sections. This data product has been chosen since it is a general product which contains
heterogeneous type of information and seems to be the most representative of the complexity of the
data. Actually, higher-level products are derived from this one and have the same format.
4.1.3.2 MERIS data products OASIS models
The MERIS L1b OASIS model will then be composed of three main parts as shown below :
Figure 4-25 MERIS level 1B high-level model
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 31
As explained previously, the MPH and DSD structures are always the same for all MERIS products
(see 4.1.2.1 and 4.1.2.2.1).
They only have to be modelled once for Level-0 products and then re-used for all other products.
On the contrary, the SPH and DS structures vary from one product to another. As shown in the
previous section, there are twelve different data products each defined in the [RD4] document.
However, each product is quite large and modelling all these products is out of the scope of the
study. Instead, the Level-1b MER_RR_1P SPH and DS parts will be modelled here using the basic
types defined previously in section 4.1.1.
4.1.3.2.1
MERIS SPH OASIS model
In the frame of this study, it has then been chosen to model the SPH defined in the Level-1B
MER_RR_1P Product.
The contained information can also be tied together to form higher-level groups.
SPH
Product time
Product
description information positioning
information
information
SPH
Product
Quality
information
Additional
Product
information
DSDs for
included
Data Sets
DSDs for
Referenced
files
Figure 4-26 MERIS Level 1B product SPH decomposition
Each group will then contain one or more fields; each field following the keyword-value-<units>terminator convention.
Based on the information defined in the [RD4] document, the MERIS Level-1B SPH has been
modelled the following way :
Figure 4-27 MERIS LEVEL-1B SPH OASIS model
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 32
In the model above, only three included data sets descriptors have been modelled since the DSD
format is generic for all level and all ENVISAT instruments. The same way, only three referenced
data sets have been modelled. The only thing that will change between three or much more data sets
descriptors will be the necessary time for OASIS to verify this model and generate the associated
EAST descriptive file. This is a normal behaviour since the bigger the model is, the more time the
tool will spend in processing it.
4.1.3.2.2
MERIS DS OASIS model
Many DS have been defined in the MERIS document [RD4]. Only the first three defined in the
Level-1B Product will be modelled here since they are heterogeneous and rather large. This way,
the performance of the OASIS tool can be tested during the EAST description generation phase and
the EAST interpreter and generator can also be tested.
Figure 4-28 MERIS Level-1B Attached Data Sets OASIS model
According to the preceding section (see 4.1.3.2.1), only three attached data sets have been modelled
here since they are considered to be the most representative ones.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 33
4.1.4 SCIAMACHY
The Scanning Imaging Absorption Spectrometer for Atmospheric Cartography (SCIAMACHY)
instrument provides spectra measured from light transmitted, back scattered or reflected by trace
gases in the atmosphere. The instrument is designed for the global measurement of trace gases in
the troposphere and stratosphere by means of a spectrometer scanning the atmosphere either at nadir
or in limb.
Exactly as for the MERIS instrument, the first part here will detail the SCIAMACHY data products
as defined in the [RD5] document.
The second part will then detail how SCIAMACHY specific information have been modelled in the
SPH and DSD parts with OASIS.
4.1.4.1 SCIAMACHY data products
The SCIAMACHY products may also be classified as Level 0, 1B and 2 products
Instrument
SCIAMACHY
Product ID
SCI_NL_0P
SCI_NL_1P
SCI_NL_2P
SCI_OL_2P
SCI_RV_2P
Description
SCIAMACHY Level 0 product
Geolocated and Calibrated Spectra
It contains: Geolocated and Radiometrically and
Spectrally Calibrated Limb and Nadir radiance
spectra
Geolocated vertical column amounts
Geolocated vertical column amounts from off-line
processing, cloud-top pressure, cloud fractional cover
and aerosols parameters
Selected Vertical Column Amounts for Meteo users
Figure 4-29 SCIAMACHY data products
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 34
As explained in the ENVISAT general features presented in chapter 4.1.2, high-level products are
derived from lower level products.
SCI_RV_2P
SCI_NL_2P
SCI_OL_2P
SCI_NL_1P
SCI_NL_0P
Figure 4-30 SCIAMACHY data product tree
The Level-0 is composed of time ordered and annotated Instrument Source Packets and is the basis
of all data processing to create higher level products.
The Level-1 product is geolocated spectra, radiometrically and spectrally calibrated radiance for
nadir, limb, and sun/moon occultation geometries.
There are three data products at the end of the processing chain according to the algorithms applied
to the Level-1 product.
4.1.4.2 SCIAMACHY data products OASIS models
SCIAMACHY products have the same overall structure as ENVISAT products. Then, they are
composed by :
 a Main Product Header,

a Specific Product Header,

one or more Data Sets.
Figure 4-31 SCIAMACHY high-level OASIS model
As explained in the section 4.1.2, the MPH and DSD always have the same format for all
ENVISAT products whatever the instrument. Basic types modelled in section 4.1.1 will also be
reused here. As for the MERIS instrument, only the level-1B data product have been modelled in
this part since it contains heterogeneous information and is used as basis to create higher-level
products. Thus, this data product is much more larger than any other higher-level product and could
then be used to test the performance of all EAST tools.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
4.1.4.2.1
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 35
SCIAMACHY Specific Product Header OASIS model
The level-1B product SPH will be modelled in this part. Its content is defined in the SCIAMACHY
volume (see [RD5]). The SPH can be divided in six main parts :
SPH
description
information
Product
location
information
SCIAMACHY Level 1B SPH
Data version Product quality
DSDs for
information
information
attached Data
Sets
DSDs for
referenced
files.
The SPH descriptors contain information specific to the product file while DSDs describe the
attached Data Sets in the product file. Though modelling is long, the first four parts can be easily
designed with OASIS.
Figure 4-32 SCIAMACHY Level1B SPH Descriptors OASIS model
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 36
Furthermore, in the SCIAMACHY level-1B SPH, many DSDs have been defined. Here, only the
first three of them have been modelled since they all have the same format.
Figure 4-33 SCIAMACHY SPH Level1B DSDs OASIS model
In the DSD model, only the content of the DS_NAME record vary from one DSD to another
according to the name of this DSD. Furthermore, the NUM_DSR record will here be used later as a
discriminant to express the number of records contained in the associated Data Set.
4.1.4.2.2
SCIAMACHY Data Set OASIS model
As seen in the previous clause (see 4.1.4.2.1), three DSDs have been modelled using OASIS. In this
part, the three corresponding DS have then been modelled (see figure below). These three DSDs
have been chosen since they contain heterogeneous types of information and are enough
representative to efficiently test all the EAST tools.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 37
Figure 4-34 SCIAMACHY Level1B Data Sets OASIS model
In this model, the sizes of the SUMMARY_QUALITY_DS, GEOLOCATION_DS and
LEAKAGE_CURRENT_CONSTANT_DS arrays are determined using the DS_NAME field
content of the associated DSD.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 38
4.2 Cryosat
Cryosat is a three-year radar altimeter mission, scheduled for launch in 2004, to determine
variations in the thickness of the Earth’s continental ice sheets and marine ice cover. Its primary
objective is to test the prediction of thinning arctic ice due to global warming.
This part is based on the [RD6] document, which describes the format of all the Level-1 products
generated inside the Payload Data Segment (PDS) for the Cryosat mission.
The Level-1 Cryosat products are derived form the SIRAL instrument Level-0 data, applying the
IPF1 processing algorithms defined in [RD7].
The first section called “Cryosat File Structure” presents the formats of all Level-1 Cryosat products
and their associated OASIS model.
4.2.1 Cryosat file structure
Each Cryosat Level-1 product is composed of two files :
 XML Header file,

Product file.
The XML Header file is an auxiliary ASCII file that users can easily access for identifying the
product without needing to look inside the Product File.
The Product File is the real product containing meaningful data and ASCII headers used by ad hoc
standard tools for inspecting the product’s content. In order to use tools already developed for the
ENVISAT mission, the product structure for Cryosat follows the structure of the ENVISAT
products as far as possible.
4.2.1.1 XML Header File
The XML Header file contains information identifying the product and is easy to read as it is based
on a standard syntax which could be accessed by common tools available for visualising its content.
The XML syntax has been chosen for the scope of the PDS.
The XML Header file is composed by:
 a Fixed Header which is the common header for all files managed into the PDS and

a Variable Header, with format and content depending on the file type and kind of product.
Each of these components is completely ASCII and based on XML syntax and conventions
proposed in the [AD1] document. Users can then easily identify the product without needs to look
inside the Product File.
Though the XML information can be modelled with OASIS, it is useless since the XML world
already offers lots of free viewer tools and since the contained information are redundant with the
contents of the product file.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 39
4.2.1.2 Product File
The Product File structure follows the one defined for the ENVISAT level-0 products as much as
possible.
Then, as shown in section 4.1.2, each product file is composed by:
 A Main Product Header (MPH),

A Specific Product Header (SPH),

One or more Data Sets (DS).
The main differences between ENVISAT and CRYOSAT MPH are :
1. The size of one of the Spare field (i.e. number 30) is different.
2. The CRYOSAT product file contains one CRC field.
The Cryosat Level 1B product file OASIS model is also composed of three main parts as shown
below :
Figure 4-35 Cryosat Level 1B high-level OASIS model
It shall be noted that, in Cryosat Level-1B product, the maximum number of Data Set in a product is
three. This is why the DATA_SETS element in the upper figure only contains three elements.
It is then not necessary to re-create the MPH model from scratch. The model defined in section
4.1.2.1 has been re-used and modified to model Cryosat Level 1B products.
The same way, the sizes of the Data Sets Descriptors fields are different though their names and
contents are similar from ENVISAT to CRYOSAT. Then, the models developed for the
ENVISAT product file can be reused here for MPH and DSD since few changes are to be
made (mainly concerning elements’ sizes).
On the contrary, the SPH and DS CRYOSAT structures have few in common with the ENVISAT
ones. Then, they have to be re-created from scratch.
The two following sections introduce the Cryosat SPH and DS and present their associated OASIS
models.
4.2.1.2.1
CRYOSAT Specific Product Header OASIS model
The SPH is composed of two main parts:
 SPH descriptors which contain information specific to the product file and

One or more DSDs (Data Set Descriptor) which describe the Data Sets in the product file.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 40
The SPH descriptors can be modelled with OASIS as follows.
Figure 4-36 CRYOSAT SPH descriptors OASIS model
Cryosat products files follow the ENVISAT standard for DSD formats. The associated OASIS
models will then be quite the same.
Furthermore, there are two different types of DSD called Measurement and Reference DSDs (of
course both having the same format). Measurements DSDs contain description about the attached
Data Sets while Reference DSDs contain description of information contained in external files.
In ENVISAT, Spare DSD have been also introduced for future use. On the contrary, it is here
proposed to have a variable SPH size to avoid oversizing the number of Reference DSDs. Then to
be able to read the SPH contents, two MPH sub-fields are used :
 The field number 38 called NUM_DSD which contains the total number of DSDs.

The field number 40 called NUM_DATA_SETS which contains the number of attached Data
Sets.
The NUM_DSD field then indicates how many DSDs are contained in the SPH while the
NUM_DATA_SETS indicates how many of them are of the Measurement type and then correspond
to Data Sets attached in the product file. This way, the number of Reference DSDs present in the
SPH is calculated upon these two fields. It is a problem since EAST doesn’t have any calculation
capabilities since this value should be evaluated to read the content of a product file.
Actually all DSDs have the same structure. Then only one OASIS model should be used for all
DSDs of both Measurement and Reference types. They should be modelled as an array containing
this structure.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 41
Figure 4-37 One DSD OASIS model
However, as shown later in this document, DSDs fields will be used as discriminants mainly for
Data Sets fields. In fact, the value of the DS_NAME parameter identify the structure of the attached
Data Sets. However, with the actual EAST technology, it is not possible to use array elements as
discriminants. This model has then been abandoned.
Another solution then has been to separate Measurement DSDs from Reference DSDs (see figure
below).
All of these elements have the
same structure ; only the content
of the DS_NAME parameter
differs from one to another.
Figure 4-38Another modelling of the DSDs.
The three measurements DSDs (i.e. DSD1, DSD2 and DSD3) are here discriminated by the
NUM_DATA_SETS field contained in the MPH. This time the same structure is copied four times.
What changes from one to another is the content of the DS_NAME field. This field will then be
used to select which Data Set will be present in the remaining of the product file.
This solution causes two main problems :
 One problem is the size of the REFERENCE_DSDS array. It has been demonstrated in the
beginning of this part that this size shall be calculated. However, as EAST has no calculation
capabilities, this size cannot be evaluated. But, it has been chosen to keep this model (the size
of the array has been arbitrary fixed) and continue with the modelling of the Cryosat Level 1B
product simply to verify that the whole product file can be modelled.

Then, a problem appeared with the discriminant. Actually, two or more distinct discriminants
can have the same name but this will result as an incorrect interpretation of the description file
by the EAST tools. Indeed, a discriminant is not identified by its whole EAST path but only by
its name. This way, when several discriminants have the same name (even though their EAST
paths are different), their values may collide. Therefore, for the three Measurements DSDs,
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 42
some fields (i.e. the ones used as discriminant) had to be renamed to be unique. A necessary
evolution of the EAST technology is therefore to be able to distinguish two discriminants by
their full paths and not only by their names.
4.2.1.2.2
Data Set OASIS model
There are twenty one different Data Set structures defined in the Cryosat document (see figure
below). These structures are discriminated by the DS_NAME fields located in the DSD1, DSD2
and DSD3 fields.
Figure 4-39 Cryosat Level 1B Attached Data Sets OASIS model
Each Data Set stands as an array where each element is a record. Of course, all records belonging to
one array have the same structure. Then the size of this array is determined by the DSR_NUMBER
field value located in the corresponding DSD element.
4.2.1.2.3
Complete Cryosat Level 1B OASIS model
Combining the MPH, SPH and Data Sets OASIS models detailed previously in this chapter, the
following complete OASIS model is obtained :
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 43
Figure 4-40 Complete Cryosat Level 1B product file OASIS model
Note : This OASIS model isn’t fully correct according to the definition of the product file. Actually,
the size of the REFERENCE_DSDS array has been fixed while it should be calculated upon other
fields values.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 44
4.3 AMS-2
The AMS-2 (Archive Management System) is an upgrade of the AMS-LR system. AMS-LR is an
archive system capable of managing heterogeneous data sets stored on heterogeneous media. It has
been developed by MS&I (Matra Systèmes & Information) based on the in-house SatSTORE tool.
SatSTORE is a COTS solution for the management of an archiving system.
AMS-2 introduces the use of the EAST technology for the data retrieval service. This function
allows to extract data portions whatever its type according to relevant extraction algorithms. The
use of the EAST technology is embedded in the SatSTORE tool.
USER INTERFACE
Extracted/Archived
DATA
Archiving/Retrieval
requests
SatSTORE
EAST
Interpreter
The SatSTORE doesn’t
directly access to
archived data
Archived DATA
Figure 4-41 AMS-2 use of the EAST technology
The main goal of this chapter is not to model the AMS2 data but to use the existing models and data
(from ERS) defined in the frame of the AMS-2 system to test the EAST data checking capabilities.
The data checking has been tested in two ways :
 by directly using the DATA_CHECKER,

and by developing a specific application upon the Interpreter API.
The study has been based on the data named user_header, block_adr_descriptor and ers_record.
This data are extracted from ERS samples of data archived in the AMS2 system. Their tree
representation with OASIS are given in the following figures.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 45
Figure 4-42 User_header model
Figure 4-43 Block_adr_descriptor model
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 46
Figure 4-44 ERS_record model
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 47
4.3.1 DATA_CHECKER with ERS products
We have first checked some data files corresponding to the description seen previously. These data
files were produced during the development of AMS2. For these data files, no errors were found. A
copy of the window where the command ‘data_checker’ has been executed follows.
data_checker
...
Name of EAST File :
../DDR/ers_record.eas
...
Name of Data File :
../DATA/ers_record.data
...
Name of Result File
:
ers_record.dc
...
What is the first data block number you want to check ? :
All data blocks will be checked
...
How many errors do you want to display (1) ? :
10
0 error(s) detected
We then modify the range of the type SHORT in the user_header description in order to obtain
some errors with data_checker. With the modified user_header.eas (the range of SHORT was from
0 to 10), we have had the following dialog.
data_checker
...
Name of EAST File :
../DDR/user_header.eas
...
Name of Data File :
../DATA/user_header.data
...
Name of Result File
:
user_header.dc
...
What is the first data block number you want to check ? :
All data blocks will be checked
How many errors do you want to display (1) ? :
...
10
2 error(s) detected
After the execution of data_checker, new files have been created that give information about the
errors found in the data file. The first one is user_header.dc and the second one is the
logbook produced by the Interpreter API used by the DATA_CHECKER tool. These two files are
shown in the following figures.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 48
---------------------------------------DUMP INFORMATIONS
Execution Directory : /users/east/bin
Data File Name : ../DATA/user_header.data
DDR File Name : ../DDR/user_header.eas
DDR Informations :
-- date generation : Tue May 25 19:14:13 1999
Dump Generation Date :
2002/ 11/ 8: 40024.633677000
---------------------------------------Check of Block
1
GROUND_STATION_AND_TRANSCRIPTION_SYSTEM.STATION_ID binary value->0000000001100110 ascii value --> ' 102'
GROUND_STATION_AND_TRANSCRIPTION_SYSTEM.STATION_DT_ID
binary
value-->0000000000100011 ascii value --> ' 35'
Figure 4-45 User_header.dc produced by DATA_CHECKER
*****************************************************************
*************
13:11:02_16:38:4
format_converter.controler_valeur_entier
E 4113 60
61
CONVERSION ERROR : INTEGER VALUE NOT ALLOWED FOR THE TARGET TYPE
AN INTEGER EXPECTED BETWEEN 0 AND 10
*****************************************************************
*************
*****************************************************************
*************
13:11:02_16:38:4
format_converter.controler_valeur_entier
E 4113 60
61
CONVERSION ERROR : INTEGER VALUE NOT ALLOWED FOR THE TARGET TYPE
AN INTEGER EXPECTED BETWEEN 0 AND 10
*****************************************************************
*************
Figure 4-46 Logbook produced by DATA_CHECKER (extract)
We can see that DATA_CHECKER detects the errors in the data file but gives some information
about each error in the file chosen (here user_header.dc) and the rest in the logbook.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 49
4.3.2 API checking capabilities and ERS products
We have tested the services the interpreter API offers to check some data file. There are eight
services which enable the check of data from a file or from memory. Their signatures are :
Check_end_of_current_block_from_file (Data_file, Error_file, Nb_max_error)
Check_end_of_current_block_from_memory (Address, Error_file, Nb_max_error)
Check_next_data_block_from_file (Data_file, Error_file, Nb_max_error)
Check_next_data_block_from_memory (Address, Error_file, Nb_max_error)
Check_next_record_from_file (Data_file, Error_file, Nb_max_error)
Check_next_record_from_memory (Address, Error_file, Nb_max_error)
Get_errors_number()
Get_errors_number_in_current_block().
All the checking functions check the data and generate errors in the Error_file file with a
maximum of Nb_max_error errors.
The application developed for checking the ERS data files (previously checked by
DATA_CHECKER) gives the same results than the on-line tool. Then, the detected errors can only
be found in the error file (which name is passed as a parameter of the checking functions) and
cannot be used directly in the application.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 50
5. Identification of technical limitations/evolutions
So far, no major problems appeared while modelling the ENVISAT data products. The only
main problem was in the use of the OASIS tool which is tedious and time-consuming (e.g. not
intuitive graphical interface).
On the contrary, it has not been possible to model the CRYOSAT level-1 data product as such
since EAST doesn’t have any calculation capabilities (this only concerns one field in the whole
model).
The following table summarises all the detected problems and details all the features of
EAST/OASIS that should be improved to be able to easily model all data products whatever their
level and instrument.
Limitations/Evolutions
Description
It has been quite simple to create the OASIS models
but very tedious and time-consuming since data
products are huge. Furthermore, common structures
Re-usability problems (type library concept) cannot be reused.
To be able to reuse (parts of) EAST description, it
would be interesting to share “type libraries”.
There is no possibility to give default values in the
syntactic description.
Default values
It would be interesting to be able to specify default
values usable by the EAST tools.
Non-static constraint
It is not possible to describe calculations on
constraints using functions/operators.
EAST Performance
Low performances have been obtained while
manipulating data products and associated OASIS
models
with
OASIS
and
the
EAST
interpreter/generator tools.
Format specification
It is not possible to specify a format that describes the
ASCII form encoding of a number.
Problems
interface
with
the
OASIS
Elements localisation problems
The graphical interface is not convenient for users
graphical who have no knowledge of the technology and can be
sometimes disconcerting. It is not reliable enough
and some functionalities are not working properly.
Some elements of the OASIS models are not
referenced with their complete EAST paths but only
with their names. This causes many problems with
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 51
discriminants for instance.
Data Checking
The first problem with the data checker tool concerns
errors return. It is very difficult to locate errors since
messages are scattered in two files. Furthermore, the
EAST API for data checking is rather limited (only
structures and ranges) and could be improved.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 52
5.1 Type library
It was not difficult to model the data products as such (with a few restrictions explained in the
previous chapter) but it has been tedious and time-consuming to re-create basic types and
common headers (e.g. Main Product Header for ENVISAT) for all data products. For example, in
the ENVISAT mission, the Main Product Header is common to all data products whatever their
level.
These common structures were created from scratch for each new model (this is really a waste
of time) since newly created structures and types are bound to one OASIS model and thus can not
be shared between several models.
To be able to re-use OASIS models across products, it would be interesting to have a type library.
This way, for example, the MPH, SPH and DSD models of MERIS could be registered as types and
reused to construct models for all other defined products. Only the DS would be different and
would have to be re-created at each level. It will then speed-up the creation of the OASIS models
for all the data products defined for a particular mission.
Level-2 product
DS OASIS model
Only DS structures are modelled at
each level since MPH, SPH and DS
models can be reused.
OASIS Type Library
Level-1 product
DS OASIS model
Basic Types
MPH OASIS model
SPH OASIS model
DSD OASIS model
Level-0 product
DS OASIS model
Figure 5-1 Type library use for MERIS OASIS models
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 53
5.2 Default values
For most of the fields in a data product, there is a default value (indicating, for example, the value
when the field is not significant). When using OASIS, it is currently not possible in the syntactic
description to indicate what are the default values.
If EAST and its associated tools (in particular the generator) are able to handle this concept, the
values of fields that are not significant, will not be calculated at runtime, since the given default
values could be used. This will then speed-up the generation process.
Furthermore, these default values could be used to create more realistic test data files.
5.3 Non-static constraint
In the current state of the technology, there are only three ways to constrain data:
 The data existence can be discriminated by another field’s value if it is a discrete value (integer
or enumeration).

The size of an array can be indicated by the value of an integer field (represented earlier in the
description).

The range of an integer or real value is set by two constant values. In this case, these values can
be named to be reused for another field.
However, in the case of the MERIS SPH, the documentation indicates that the value of the
SLICE_POSITION field is smaller or equal to the value of the NUM_SLICES field. This kind of
constraint cannot be expressed in the EAST descriptive since EAST has no processing
capabilities.
In the case of CRYOSAT, the size of the Reference Data Sets array (see 4.2.1.2.1) should be
calculated at runtime. The size value is the difference between the NUM_DSD and
NUM_DATA_SETS of the MPH fields. This kind of calculation can neither be used to set the
size of an array with OASIS.
The addition of “non-static constraints” to the EAST language will allow to model more kind of
data and improve the data checking.
It would be really useful to have algorithmic capabilities to describe, for example :
 a range or a size of an array computed from the values of other fields,

some arithmetic operation (e.g. +,- but also >,…) to calculate constraints at runtime.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 54
5.4 East Performance
It has been possible in this study to create complete OASIS models of the data products. It has then
been possible to generate the associated EAST description file to test the complete EAST tools
suite.
The first performance problem appeared while trying to generate the EAST file for the Cryosat
Level 1B model (see model in section 4.2.1.2.3). The generation lasted nearly thirty minutes
though the verification of this model was nearly immediate.
Another performance problem appeared when using the EAST generator tool. To verify the models,
some test data have been generated and it appeared that this operation was requiring a really long
time (from some seconds to many hours depending on the values of the discriminants).
In order to be operational, the DEBAT environment should rely on fast and reliable East tools.
5.5 Format specification
OASIS does not directly provide any means to enter “formats” that specifies the ASCII format
encoding of integer or real field values. Indeed, the formats have to be expressed in an ancillary file
used by the EAST generator. Users have then to create this file by hand which is tedious, timeconsuming and can lead to many errors.
FRT auxiliary file
OASIS
EAST descriptive
EAST Generator
Data file
Integer and real elements
have the correct format.
Figure 5-2 Specification of integer and real formats
Without this FRT file, the only information used by the generator is the length of the field.
It would be useful to improve the format handling of integer and real values without needing to
create the FRT file using a text editor.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 55
5.6 OASIS graphical interface
The OASIS MMI is not user-friendly enough and is disconcerting for users who have no knowledge
of the technology.
The table below summarises all the functionalities that need to be corrected/improved to make
OASIS more user-friendly, reliable and complete:
Element
Description
Undo/Redo function
Copy/Pate function
Context dependent menu
Data model and Information windows
Search capabilities
Short cuts
Help to semantic information
Errors messages
This function is not working properly.
This would enhance the management of the
active OASIS model.
OASIS should fully support the copy/paste
functionality that is not working in the current
tool.
The main menu shall be modified for most of the
functionalities to be accessible whatever the
active window is, and then not be contextdependent anymore.
These two windows have to be tied together.
This means that if the Data model window
becomes active, the associated Information
window shall also become active. This is
specially important when manipulating two or
more descriptions at the same time.
The goal of this function is to enhance the
navigation through large models. It can also be
tied to error messages in order to easily locate
fields which create errors.
The aim is to provide keyboard shortcuts for the
main functionalities.
The goal is to have an enhanced editor for
semantic information in order to be able to add
complex descriptive attributes. Currently, it is
really difficult to edit semantic information (too
small text fields, no copy/paste, etc.).
The error messages are not explicit enough. Most
of the time, they are truncated which makes it
difficult for users to have a precise knowledge of
the error source. Moreover, it is difficult to
search through the whole tree structure to find
the element which cause this problem (no search
capabilities are provided).
A rather complete list of the problems encountered with the OASIS MMI is given in the document
[RD9].
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 56
5.7 Element localisation problems
Within an EAST model, some elements are not referenced with their complete EAST path (but only
with their name).
For example, the discriminants are only identified by their names. This is a problem when several
discriminants have the same name in a model because the EAST tools (and notably the Interpreter
and Generator tools) are not capable to choose the right discriminant (in fact, the nearest is used).
The only solution with the current technology is to rename each of these elements which is
really tedious.
Furthermore, this fact precludes to re-use generic structures or predefined types in which some
elements are used as discriminants.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 57
5.8 Data checking
There are several problems with the EAST tools suite concerning the data checking.
The first lacks are related to the DATA_CHECKER tool.
The first problem is that the information about an incorrect value is truncated in two files: the first
part is stored in the file containing the encountered errors; the other part is stored in the logbook. In
the error file, the name and the value of the incorrect field are written while in the logbook, there
are the expected values (the range for a scalar and the different possible values for an enumeration).
It is tedious to have to open two files to obtain all information about the detected errors.
The second problem is that users can not specify their own values. The DATA_CHECKER only use
ranges and values found in the EAST description file.
The second restriction concerns the data checking functions offered in the EAST API. In fact, these
functions have been firstly designed to code the DATA_CHECKER tool. Then, they are not
adapted to check data directly in an application.
The following points should be addressed to offer full data checking capabilities in the EAST API :
 The data checking results are not directly accessible since errors are written in a file. It is
then complicated to use the data checking result programmatically.
 It is not possible to directly check a particular field. Developers have to write a lot of
code to be able to check a particular element, especially when discriminants are present.
 It shall be interesting to get the possible values of a particular field (e.g. range for a
scalar, enumerated values for an enumeration).
 The data checking is processed using information found in the EAST description file
(e.g. range for a scalar). It is then not possible to check data using computed constraints
or with different bounds.
 It shall be interesting to be able to compare two elements values without loading these
elements in the application.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 58
6. Evolutions and Limitations technical analysis
The following clauses detail the technical analyses carried out for the limitations/evolutions
encountered.
6.1 Type library
The analysis of this evolution is done in the [RD8] document.
6.2 Default values
Default values have only to be considered for character, string, integer or real types.
There is no particular technical difficulty to add this concept in the OASIS tool. This implies :
 adding a place for this value in the information window (e.g. an input text field),

adding it into the internal description of a terminal node of the tree, and,

reading/writing this value from/to the EAST description.
The value could be indicated on the same line as the declaration of the field in a comment part. This
solution will not induce a modification of the EAST CCSDS recommendation.
The value could also be indicated using the ADA affectation syntax. But, in this case the EAST
norm should be modified. The following example shows the two solutions.
Type MY_RECORD is record
MY_INTEGER : INTEGER ; -- DEFAULT : 0
MY_REAL : SLICE_NUMBER_TYPE ; -- DEFAULT : 0.0
MY_STRING : STRING ; -- DEFAULT : « ABC »
end record ;
OR
Type MY_RECORD is record
MY_INTEGER : INTEGER := 0 ;
MY_REAL : SLICE_NUMBER_TYPE := 0.0 ;
MY_STRING : STRING := « ABC » ;
end record ;
This value could also be added in the DEDSL semantic description but it would lead to a
modification of the DEDSL recommendation.
The adding of default values in the EAST core is a little more difficult.
The EAST analyser should be modified. It would be necessary to analyse the end of a line (in which
a field is declared) to find the default value. This value should be memorised to be used later. In
compensation, the interpreter should not be modified.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 59
Then, the write function of the generator have to be modified in order to take into account the
default value when needed. Currently, if a field has no value, the write function raises an exception.
Once modified, this function will check if a default value exists before raising the exception.
6.3 Non-static constraints
The goal of this evolution is to take into account algorithms capabilities. This will allow to define
values that will be calculated at runtime from other values indicated earlier in an EAST description.
The first step of this evolution is the addition of calculated values in the data description. The
second step is the use of this calculated value to improve data checking capabilities.
The goal is to provide a few simple operations that could be apply on fields in order to obtain a new
value.
OASIS should be modified so that it can manage this kind of operation. In each information
window that is associated to a field having a calculated parameter (range of an integer or a real, size
of an array and existence condition), an entry field should be provided in order to let users define
the calculation formula. With a drag and drop mechanism (the same as the one used to define
constants in an integer or real range), it will be easy to create function using other fields’ values (or
sizes) as inputs. Then, this formula should be written in the EAST description.
The following implementation (that keeps the EAST description computable) is suggested:
 The new value is declared as a variable,

The name of the variable is preceded by the pattern COMPUTED_,

The formula is given in another variable which is a string,

The name of this second variable is preceded by the pattern FORMULA_,

The values used in the formula are referenced by their full EAST path.
Example :
COMPUTED_ARRAY_SIZE : INTEGER ;
FORMULA_ARRAY_SIZE : STRING := “HEADER.NUMBER_1 – HEADER.NUMBER_2” ;
The computed value could be use as a size of an array.
Example :
Type DATA_ARRAY is array (1.. COMPUTED_ARRAY_SIZE) of DATA ;
In order to improve the data checking, a computed value can also be used as a min or max of a
range.
Example :
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 60
COMPUTED_RANGE_MAX : REAL ;
FORMULA_RANGE_MAX : STRING := “DATA.VALUE_1” ;
Type VALUE_2 is digits 2 range 0.0 .. COMPUTED_RANGE_MAX ;
Remark : In addition to the four basic operations (+,-,*,/), we could use some predefined name to
add some useful operations like sin, cos, tan or is_odd, is_even, etc … The formula could also
contain some parenthesis to express more complicated expressions.
In order to take into account the calculation capability, the EAST core should also be modified.
First the computed value should be detected when the description is analysed, then the formula
should be stored in the internal form used by the EAST core to describe the model. The formula
would be parsed by the interpreter and the generator when the calculation has to be processed.
6.4 EAST Tools performance
The generation of the Cryosat description has highlighted some strong weaknesses in the OASIS
performance. The problems have to be investigated in order to detect where the software takes so
much time.
The use of the EAST generator tool to create data products has also shown performance problems.
In fact, the generator has not been modified nor updated concerning its performance while the
performance of the Interpreter tool has been greatly improved. This is mainly because the projects
already using EAST (e.g. SPOT, HELIOS,..) have returned many feedback on the subject. This
time, the problems of the Generator tool have to be investigated.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 61
6.5 Format specification
There are two different solutions to take formats for integer and real values into account in the
EAST/OASIS technology :

Firstly, the format can be included in the EAST description so that it will totally be
transparent to users. This implies a modification of the EAST CCSDS recommendation.
OASIS
Specifying syntaxtic
information and
patterns.
EAST descriptive file
containing syntactic and
pattern information.
Figure 6-1 Format included in the EAST core

EAST generator
Correctly
formatted data
file.
Secondly, users can directly specify the formats in the OASIS tool and this latter will
automatically generate the FRT file used by the EAST generator to produce correct
elements.
OASIS
EAST description file
Specifying syntaxtic
information and
patterns.
EAST generator
FRT file
Correctly
formatted data
file.
Figure 6-2 Formats with OASIS generating the FRT file
The first solution requires some important modifications of both OASIS and the EAST core.
Therefore, it could lead to worse performances for the generation.
The second solution does not require any modification of the EAST core. It is the current way it
runs.
Some modifications of OASIS are required. These modifications are :
 add a check-box to indicate that the sign must be always written,

add a way to indicate, for a real value, if there must have an exponent with a “D” (FORTRAN),
a “E”, a “e” or no exponent,
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note

Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 62
be able to generate the FRT file corresponding to a description file.
The formats used by the EAST core are the following ones.
For an integer, the format is described by :
[S]Im
where the optional S indicates that the sign will be always written (and the left space will be filled
by some “0” instead of some “ “ without FRT file). The “I” indicates that it is an integer format.
The number m indicates the number of characters (except the sign) to use when writing the value.
For a real value, the format is described by :
[S]{F|D|E}m.n
where the optional S indicates that the sign will always be written. One of the letter F, D or E is
used to indicate that there is no exponent (F), an exponent prefixed by E or an exponent prefixed by
D. The number m indicates the whole number of characters (with the sign) to use when writing the
value. The number n indicates the number of digits after the point.
The adding of the character ‘e’ for the exponent is a minor modification.
6.6 Element localisation problems
In order that the full pathname of discriminant fields is used by EAST and its associated tools, the
EAST norm has to be modified.
First, OASIS will have to generate an EAST description with the full pathname for each
discriminant. This is not difficult because OASIS stores this pathname.
Then the EAST analyser must be modified to analyse this full pathname. This modification can be
costly because the handling of the discriminants is one of the more complex feature of the EAST
core.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 63
6.7 Data checking
Concerning the DATA_CHECKER, the main improvement is in the result file. This file should
contain all information required to fully understand the source of the errors without having to look
neither at the data file nor at the EAST description :
 The complete EAST path for each field creating an error has to be expressed.
 The associated wrong values have to be tied to the previous EAST paths.
 The expected values shall also be presented.
It shall be simple since all of these information are already accessible. The only thing to do is to
write the expected values in the result file and not in the logbook anymore.
Another improvement will consist as allowing users to specify values and ranges. The
DATA_CHECKER will then use these information instead of the ones found in the EAST
description file. This could be done using a file that will contain the element to check (i.e. its EAST
path) with the associated ranges or values.
MODEL.AN_INTEGER 10..12
MODEL.RECORD.A_REAL 1.0..2.0
MODEL.RECORD.AN_ENUMERATION ONE
The DATA_CHECKER will check all elements present in the EAST description file but will use
user values when checking the specified elements.
The creation of these file can be done manually or be guided by the DEBAT Producer & Editor tool
that will automatically generate this file.
DEBAT Data
Editor &
Producer
File
containing
some
elements to check with
associated user values or
ranges.
EAST
description
file
DATA_CHECKER
Data file
Figure 6-3 - DEBAT data checking
DEBAT – Development of EAST Based Access Tools
Result file
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 64
Furthermore the Interpreter API should be improved in order to make the data checking much more
easier. The existing functions will be kept as such since they are used by the DATA_CHECKER
tool.
The following functionalities shall be added in the EAST API :
 A direct access to the detected errors shall be provided to software. It shall be simple
since all errors are stored by the EAST core. This way, when checking an element, a
return code will be provided.
 The checking of an element should be possible with one single instruction. The
localisation of the element in the data file will then be up to the EAST core. This part
shall be difficult especially when dealing with discriminants. The EAST core will then
have to calculate the location of this element in the data file.
 The possible values of each field have to be available for the application. When
manipulating character, real or integer elements, the possible values will consist as a set
identified by its bounds. For an enumeration, it will be all possible values that this
element can take. It shall be simple since these information are stored in the EAST core.
 It shall be possible to check an element with specific bounds different from the limits
expressed in the EAST file. It shall be simple to add one single function to insure this
checking.
 Finally, the comparison between two elements shall be possible without loading these
values in the application. This way, it will be possible to compare one value with
another. This latter may be calculated upon other values or may be another element of
the data file. There will be three functions created here to verify if one element is
inferior, equals or superior to another elements.
DEBAT – Development of EAST Based Access Tools
EAST current applications
Technical Note
Reference : SS/DEBAT/EAST_TN
Issue
: 1.0
Date
: 14/01/2003
Page
: 65
7. Conclusion
First, we must say that this study of the EAST technology, based upon the ENVISAT, CRYOSAT
and ERS examples, has shown many bugs to correct in the different EAST tools in order to produce
a reliable DEBAT tools suite.
We also found some restrictions in the EAST tools, the major being the unavailability of
calculation capabilities (compulsory to model Cryosat data as specified). We experienced many
performance problems both in the EAST core and in the other graphical tools used (i.e. OASIS and
DUW). The first performance problems concerned the generation of the Cryosat description file
which took a very long time (i.e. about thirty minutes). The other performance problems came from
the data reading/generating in some particular cases (e.g. when many discriminants are present in
the model).
It is to be noted that many performance problems have already been detected by the projects that
have used EAST so far (SPOT, HELIOS, CDPP,…) and keep using it despite of these problems. In
fact, all of these projects have pointed that since EAST is generic, it can’t be as fast as specific
developments and that the EAST tools are getting faster and faster. Their main concerns were about
the data management features EAST offer and mainly the possibility to read heterogeneous data
from heterogeneous systems (and this transparently to users).
In spite of these abnormalities and restrictions, we were able to model and to generate the chosen
ENVISAT products. CRYOSAT data have also been modelled though not exactly as specified in
the documentation. We have also successfully tested the data checking on the ERS products though
EAST lacks of powerful checking functions.
Furthermore, for all of these limitations, we saw that there are solutions to implement the needed
evolutions. The most important modifications will concern the OASIS tool and the EAST core.
In conclusion of this study, we can say that the EAST technology enables the modelling, the
generation/simulation and the processing of complex data products like ENVISAT, CRYOSAT and
ERS ones with few restrictions. With some improvements and also some new developments based
on the EAST technology, a powerful and reliable complete tools suite for all the data life cycle
could be created.
DEBAT – Development of EAST Based Access Tools