debat : development of east based access toolsdebat.c-s.fr/project/documents/doc/urd1.2.doc ·...

DEBAT : Development of EAST Based Access Tools

User Requirements Document

Contract : 16562/02/I-LGReference : SS/DEBAT/URDIssue : 1.2Date : 10/03/2003

Prepared by :

Olivier QueyrutJérôme Candat

Date :

Checked by :

Maud GranetDate :

Approved by :

Carlos GuerreiroDate :

DEBAT – Development of EAST Based Access Tools

User Requirements Document Reference : SS/DEBAT/URD Issue : 1.2 Date : 10/03/2003 Page : i

Document Status Sheet

Document Title User Requirement DocumentDocument Reference Number SS/DEBAT/URD

Issue Revision Date Reason for change1 2 10/03/2003 Second revision of the document after negotiation of End of

Phase 1 meeting1 1 04/03/2003 First revision of the document for end of phase 11 01 07/02/2003 Draft revision for inclusion of ESA comments after SRR

(System Requirements Review)1 0 14/01/2003 First version0 2 20/12/2002 Second draft version0 1 12/12/2002 First draft version


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : ii

Document Change Records

Document Title User Requirements DocumentDocument Reference Number SS/DEBAT/URDDocument Issue/Revision Number 1.2

Page Paragraph Reason for change21 UR 18-19 A note has been added47 UR 103-104 A note has been added48 Addition of UR 308 and 309.

Clarification of UR 10749 Clarification of UR 10868 UR 172-173 A note has been added80 UR 209-210 A note has been added97 UR 269 Clarification of the note

97,98 Clarification of UR 270,271,272,273


Page Paragraph Reason for changeAll First revision of the document for end of phase 1 formal delivery


Page Paragraph Reason for changeAll Draft revision for inclusion of ESA comments after SRR


Page Paragraph Reason for changeAll First version


Page Paragraph Reason for changeAll Second draft version


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : iii


Page Paragraph Reason for changeAll First draft version


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : iv

Table of contents

DOCUMENT STATUS SHEET........................................................................................................I

DOCUMENT CHANGE RECORDS..............................................................................................II

TABLE OF CONTENTS................................................................................................................IV

TABLE OF FIGURES...................................................................................................................VII

ACRONYMS AND ABBREVIATIONS.....................................................................................VIII

APPLICABLE DOCUMENTS........................................................................................................X

REFERENCE DOCUMENTS........................................................................................................XI

1. INTRODUCTION..........................................................................................................................1

1.1 OBJECTIVES.................................................................................................................................11.2 SCOPE..........................................................................................................................................21.3 CONVENTIONS.............................................................................................................................41.4 DEFINITIONS................................................................................................................................51.5 STRUCTURE OF THE DOCUMENT..................................................................................................5

2. GENERAL DESCRIPTION.........................................................................................................6

2.1 PRODUCT PERSPECTIVE...............................................................................................................62.2 GENERAL CAPABILITIES...............................................................................................................9

2.2.1 DEBAT Tools........................................................................................................................92.2.2 DEBAT features..................................................................................................................10

2.3 GENERAL CONSTRAINTS............................................................................................................112.4 USER CHARACTERISTICS............................................................................................................112.5 APPLICATION DOMAINS.............................................................................................................112.6 OPERATIONAL ENVIRONMENT...................................................................................................122.7 ASSUMPTIONS AND DEPENDENCIES...........................................................................................13

3. CAPABILITY REQUIREMENTS.............................................................................................14

3.1 DEBAT.....................................................................................................................................153.1.1 Installation..........................................................................................................................153.1.2 Version management..........................................................................................................163.1.3 Data Life Cycle...................................................................................................................193.1.4 Compatibility......................................................................................................................203.1.5 Internationalisation............................................................................................................223.1.6 Online Help.........................................................................................................................233.1.7 GUI functionalities.............................................................................................................233.1.8 Documentation generation.................................................................................................253.1.9 Printing functionalities.......................................................................................................27

3.2 DEBAT INTEGRATED ENVIRONMENT.......................................................................................283.2.1 DEBAT framework..............................................................................................................29


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : v

3.2.2 Plug-in system.....................................................................................................................303.2.3 Project management...........................................................................................................32

3.3 WEB INTERFACE........................................................................................................................343.3.1 Local Web Site....................................................................................................................353.3.2 Web Services.......................................................................................................................40

3.4 EAST CORE...............................................................................................................................443.4.1 General requirements.........................................................................................................443.4.2 EAST Description Handling...............................................................................................473.4.3 Data Handling....................................................................................................................49

3.5 DEBAT MODELLER..................................................................................................................553.5.1 General requirements.........................................................................................................563.5.2 Model Handling..................................................................................................................583.5.3 Type handling.....................................................................................................................623.5.4 Graphical User Interface....................................................................................................633.5.5 Generation..........................................................................................................................67

3.6 DEBAT PRODUCER & EDITOR.................................................................................................703.6.1 EAST description Handling................................................................................................713.6.2 Data Handling....................................................................................................................733.6.3 Graphical User Interface....................................................................................................79

3.7 DEBAT EXTRACTOR & QUERYING..........................................................................................833.7.1 EAST description handling.................................................................................................843.7.2 Data handling.....................................................................................................................853.7.3 Graphical User Interface....................................................................................................933.7.4 Batch processing.................................................................................................................94

3.8 DEBAT UTILITIES.....................................................................................................................963.8.1 General requirements.........................................................................................................963.8.2 ASCII_DUMP.....................................................................................................................973.8.3 DEAL..................................................................................................................................973.8.4 EASTcrc..............................................................................................................................983.8.5 DATA_CHECKER..............................................................................................................983.8.6 Comparison tool...............................................................................................................100

3.9 DEBAT POST-PROCESSING TOOLS.........................................................................................1013.9.1 2D graphical tool..............................................................................................................1013.9.2 Quick looks.......................................................................................................................1023.9.3 CAOS................................................................................................................................1033.9.4 Database interface............................................................................................................1043.9.5 Format transformation.....................................................................................................104

3.10 DEBAT DISTRIBUTION.........................................................................................................1073.11 TM/TC & SCOS-2000..........................................................................................................109

3.11.1 TM/TC modelling............................................................................................................1103.11.2 SCOS-2000 database import..........................................................................................1103.11.3 Simulation of the SCOS-2000 TM/TC processing chain................................................112

4. CONSTRAINT REQUIREMENTS.........................................................................................115

4.1 PERFORMANCES REQUIREMENTS.............................................................................................1164.2 ENVIRONMENT REQUIREMENTS...............................................................................................1174.3 EXTERNAL REQUIREMENTS......................................................................................................1174.4 RELIABILITY REQUIREMENTS..................................................................................................118


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : vi

4.5 USABILITY REQUIREMENTS.....................................................................................................1184.6 SAFETY REQUIREMENTS..........................................................................................................119

4.6.1 Legal requirements...........................................................................................................119

5. LIST OF USER REQUIREMENTS.........................................................................................121


User Requirements Document Reference : SS/DEBAT/URD Issue : 1.2 Date : 10/03/2003 Page : vii

Table of figures

Figure 1-1 Requirements collection process........................................................................................1Figure 1-2 Data life cycle.....................................................................................................................3Figure 2-1 DEBAT as a data workshop...............................................................................................7Figure 2-2 DEBAT architecture connecting to real world...................................................................7Figure 2-3 DEBAT as a generic data infrastructure.............................................................................8Figure 2-4 DEBAT for simulation/testing............................................................................................8Figure 2-5. DEBAT inputs and main outputs.......................................................................................9Figure 2-6 DEBAT operational environment.....................................................................................13Figure 3-1 Main capabilities requirements set...................................................................................14Figure 3-2 DEBAT common functionalities requirements set...........................................................15Figure 3-3 DEBAT integrated environment requirements set...........................................................28Figure 3-4 Web Interface requirements set........................................................................................34Figure 3-5. Local Web Site Requirements set....................................................................................35Figure 3-6. DEBAT Web Service architecture..................................................................................40Figure 3-7. DEBAT Web Services requirements set.........................................................................41Figure 3-8. EAST core requirements set............................................................................................44Figure 3-9 Input and output of DEBAT Modeller.............................................................................55Figure 3-10. DEBAT Data Modeller requirements set......................................................................56Figure 3-11 Input and output of the DEBAT DPE.............................................................................70Figure 3-12. DPE requirements set....................................................................................................70Figure 3-13. DPE data handling user requirements...........................................................................73Figure 3-14 Input and output of the DEBAT DEQ............................................................................83Figure 3-15. DEQ requirements set....................................................................................................84Figure 3-16. DEQ data handling requirements..................................................................................85Figure 3-17 DEBAT Utilities requirements set..................................................................................96Figure 3-18 DEBAT post-processing tools requirements set...........................................................101Figure 3-19 DEBAT distribution requirements set..........................................................................107Figure 3-20 TM/TC & SCOS-2000 requirements set......................................................................109Figure 3-21 SCOS-2000 database import........................................................................................110Figure 4-1 Constraints requirements set...........................................................................................115


User Requirements Document Reference : SS/DEBAT/URD Issue : 1.2 Date : 10/03/2003 Page : viii

Acronyms and Abbreviations

ADD Architectural Design DocumentAMS Archive Management SystemAPI Application Program InterfaceAR Acceptance ReviewATP Authorisation To ProceedCA Control AuthorityCAID Control Authority IdentifierCAO Control Authority OfficeCAOS Control Authority Office SystemCDF Common Data FormatCDR Critical Design ReviewCEOS Committee on Earth Observation ScienceCFI Customer Furnished ItemCNES Centre National D’Etudes Spatiales (French Space Agency)COTS Commercial Off The ShelfCCSDS Consultative Committee for Space Data SystemsDEAL Display EAST Access ListDEBAT Development of EAST Based Access ToolsDEBAT-DM DEBAT Data ModellerDEBAT-DPE DEBAT Data Producer & EditorDEBAT-DEQ DEBAT Data Extractor & QueryingDEBAT-PPT DEBAT Post Processing ToolsDEBAT-UT DEBAT UtilitiesDDR Data Description RecordDDU Data Description UnitDDF Design Definition FileDED Data Entity DictionaryDEDSL Data Entity Description Specification LanguageDEW Data Extractor WizardDIP Dissemination Information PackageDJF Design Justification FileDUW Data Update WizardDW DEBAT WorkshopEAST Enhanced ADA Sub SeTECSS European Cooperation for Space StandardizationEO Earth ObservationESA European Space AgencyESRIN European Space Research INstituteERS European Remote Sensing satelliteESA European Space AgencyEVA ESA Virtual ArchiveFA Final AcceptanceFAQ Frequently Asked QuestionFAR Factory Acceptance ReviewFAT Factory Acceptance Tests


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : ix

FDIR Fault Detection, Isolation and RecoveryFP Final PresentationFPA Final Presentation and AcceptanceGUI Graphical User InterfaceHDF Hierarchical Data FormatHTML Hyper Text Mark-up LanguageHTTP Hyper Text Transfer ProtocolHW HardwareICD Interface Control DocumentIDVP Implementation, Diffusion and Validation PlanIR Interface RequirementsITT Invitation To TenderJSP Java Server PagesKOM Kick Off MeetingMACAO Member Agency Control Authority OfficeMMI Man-Machine InterfaceNAS Network Attached StorageOAIS Open Archival Information SystemOASIS Space Data Modelling Help Tool OSAT On Site installation and Acceptance TestsPAP Product Assurance PlanPDR Preliminary Design ReviewPMP Project Management PlanPUS Packet Utilisation StandardPVL Parameter Value LanguageRB Requirements BaselineRID Review Item DiscrepancyRTD Research and Technology DevelopmentSCMP Software Configuration Management PlanSIP Submission Information PackageSOAP Simple Object Access ProtocolSOW Statement of WorkSPMP Software Project Management PlanSRR System Requirements ReviewSVG Scalable Vector GraphicTM/TC Telemetry / TelecommandTS Technical SpecificationsUDDI Universal Description Discovery and IntegrationURD User Requirements DocumentWSDL Web Service Description LanguageWWW World Wide WebXML eXtensible Mark-up LanguageXSL eXtensible Stylesheet LanguageXSLT eXtensible Stylesheet Language Transformation


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : x

Applicable Documents

Title Issue Date ReferenceAD1 ESRIN SOW “Development of

EAST Based Access Tools”1.1 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

AD5 ECSS – Space Engineering Standards – Software ECSS-E-40B

ECSS-E-40B


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xi

Reference Documents

Title Issue Date ReferenceRD1 DEBAT - Project Management Plan 1.1 30/10/2002 SS/DEBAT/PMP

RD2 DEBAT - Product Assurance Plan 1.1 30/10/2002 SS/DEBAT/PAP

RD3 DEBAT - Interviews Technical Note 1.0 14/01/2003 SS/DEBAT/I_TN

RD4 DEBAT - EAST for TM/TC processing Technical Note

1.0 14/01/2003 SS/DEBAT/TMTC_TN

RD5 DEBAT - EAST current applications Technical Note

1.0 14/01/2003 SS/DEBAT/EAST_TN

RD6 DEBAT – Requirements Collection Technical Note

1.0 14/01/2003 SS/DEBAT/RC_TN

RD7 The Data Description Language EAST Specification (CCSD0010). Blue Book.

2.0 November 2000

CCSDS 644.0-B-2

RD8 The Data Description Language EAST - A Tutorial. Green Book.

1.0 May 1997 CCSDS 645.0-G-1

RD9 The Data Description Language EAST - List of Conventions. Green Book.

1.0 May 1997 CCSDS 646.0-G-1

RD10 Data Entity Dictionary Specification Language (DEDSL) - Abstract Syntax (CCSD0011). Blue Book.

1.0 June 2001 CCSDS 647.1-B-1

RD11 Data Entity Dictionary Specification Language (DEDSL) - PVL Syntax (CCSD0012). Blue Book.

1.0 June 2001 CCSDS 647.2-B-1

RD12 Data Entity Dictionary Specification Language (DEDSL) - XML/DTD Syntax (CCSD0013). Blue Book.

1.0 January 2002

CCSDS 647.3-B-1


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xii

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.

The following schema presents how the URD phase is integrated in the DEBAT project and in particular, it shows the activities preceding the URD phase. These activities allow to identify the user requirements by stressing the strength and weaknesses of the current EAST technology and associated tools.

Figure 1-1 Requirements collection process

The research for the requirements has three sources: Interviews stage [RD3] : the interview activities allow to gather users feedback and to

get the expected enhancements or limitations expressed by current users or potential new users.

EAST for TM/TC processing study [RD4] : the research for requirements is achieved by modelling the generic PUS Service 11 (ECSS standard) and the CryoSat Service 11 (On-board Operations Scheduling), and by analysing the work done and results obtained. A focus is also done on the SCOS-2000 Mission Control Centre in order to identify the requirements related to the potential use of DEBAT within SCOS-2000.

EAST current applications study [RD5] : the research for requirements is achieved by modelling some data products (CryoSat, Envisat, AMS2) and by analysing the work done and the results obtained.

The “Requirements Collection Technical Note” [RD6] gather all requirements identified in the previous stages. Finally, the user requirements are both extracted from the functionalities of the existing EAST tools suite and from the previous phases.

The URD details the technical objectives of the DEBAT software by defining the user requirements as a preliminary phase to the software development life cycle. The User Requirements Document (URD) intends to focus on the user needs by defining the ideal DEBAT software from the user


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xiii

point of view. The goal of all these requirements is to leverage the EAST technology to be able to model any kind of data and to be widely adopted by the industry.

The technical and organisational constraints / limitations are not stressed here and will be documented during the next steps of the system development. The URD will be followed by the System Requirements Document (SRD), the Architectural Design Document (ADD) and the Detailed Design Document (DDD).

The URD is a contractual document, which must be followed by the Contractor and the project team when designing the DEBAT software. While it defines the boundaries of the system under development, through clear specification of user needs and expectations, it should also be used as a reference during the acceptance testing to ensure that all essential user requirements have been satisfied by the implementation of the system.

1.2 Scope

The DEBAT software will be a data workshop relying on the EAST technology which consists in the following international recommendations:

EAST (Enhanced Ada SubseT) primarily imagined by CNES and designed in the framework of CCSDS Panel II (CCSDS 644.0-B-1 and ISO 15889:2000). As the name implies (Enhanced Ada SubseT), EAST is based upon the ADA language (in fact, EAST is 100% compliant with the ADA syntax). EAST is designed to create non-ambiguous descriptions of data formats including syntactic (logical and physical) information.

DEDSL (Data Entity Dictionary Specification language) designed in the framework of CCSDS Panel II. DEDSL allows to add semantic information to data by the means of semantic attributes. Two implementation are available: one in PVL (Parameter Value Language), the other one in XML (eXtensible Markup Language).

The EAST/DEDSL technology has been developed (primarily in a Research & Technology Development context) with the following major objectives in mind:

to provide complete, perennial, easily understandable and evolutionary descriptions of data formats, including syntactic and semantic information,

to provide engineers, scientists and end-users with generic tools for supporting the technology: to easily describe the data formats and make them evolve, to produce quickly test data independently from storage media, to access and extract the values of the data without having to write specific code, to format the data on their storage medium with a structure that matches their

description.

The main goal of the DEBAT software is to provide a set of enhanced tools that support the entire data life cycle. The challenge is to leverage the current EAST data workshop concepts (set of norms and collections of tools) towards an unified view of data through a data handling architecture centred on the users needs.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xiv

The figure below presents the data life cycle:

Figure 1-2 Data life cycle

The first step for using EAST technology is to describe the structure and meaning of the data. The DEBAT-Data Modeller will be a convenient tool providing facilities to thoroughly describe the users’ data through a user friendly graphical interface. The DEBAT-Data Modeller will produce as outputs a description file (often called Data Description Record – DDR) gathering all syntactic information about the data and a DED file (Data Entity Dictionary) containing all semantic information. These DDR/DED files will then be used by all other tools to process the data.

The projects working with the EAST technology will be able to use the low-level APIs (INTERPRETER and data GENERATOR) to develop their customised applications that read/write data initially described with DEBAT-Data Modeller.

The DEBAT-Data Producer & Editor will be a tool allowing the production/modification of data files. This tool is intended to produce test data files for simulation purposes for example.

Then, in order to process data products, several tools will be provided within the DEBAT environment. The DEBAT-Data Extractor & Querying will be a powerful graphical tool providing capabilities to read data products, search for elements and extract sub-products from data products described with the EAST technology. Other useful tools will also be provided for processing purposes. The most relevant are:

ASCII_DUMP produces an ASCII representation of binary files (visual checking)

DATA_CHECKER checks the format of data files produced by an application that does not use the EAST technology to generate the files.

The post-processing in DEBAT will consist in providing users with the ability to plug or simply run their own post-processing applications in the DEBAT framework. Finally, DEBAT will provide means to distribute data products to end-users.

As a conclusion, the main benefits gained from making use of EAST and DEBAT technologies could be summarised as follows:

Ensuring data preservation: being freed from non perennial file formats, and using a well defined formalism (instead of textual descriptions like Word or Pdf documents) with a computer compatible format (ADA subset, PVL, XML),


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xv

Adding value to data: with possibilities to define “data about data”, i.e. syntactic and semantic metadata allowing an easier understanding of the data by human-beings or computers and adding real value to the data,

Making data life cycle easier: providing a suite of tools for all phases of data handling, allowing to process data with almost no developments.

1.3 Conventions

Within this requirements document, the following definitions shall apply: ‘Shall’ Requirements containing ‘shall’ are considered essential, i.e. mandatory.

‘Should’ Requirements containing ‘should’ are strongly recommended requirements although non-mandatory; a justification must be given if the requirement is not met.

‘Will’ The term ‘will’ is used only in describing assumptions or background information used in formulating the requirements, not the requirements themselves.

‘May’ The term ‘may’ is used only in describing assumptions or background information used in formulating the requirements, not the requirements themselves. Has less certitude than ‘will’.

The following keywords refer to each requirement definition as each requirement has the followingattributes:

‘UR Id’ The unique numeric identifier of the user requirement, used for traceability back to the URD.

‘Text’ This is the formulation of the requirement. Each requirement attempts to be clear, concise and unambiguous, with each statement containing one and only one requirement. (Note that the text for each UR is not preceded by the ‘text’ label as this would be redundant).

‘Source’ This is the source of the requirement used for backwards traceability and may be a document cross-reference, the name of a body or organisation or a particular review meeting. EAST_TN means that the requirement comes from the “EAST current application Technical Note”, TMTC_TN means that it comes from the “EAST for TM/TC processing Technical Note”, I_TN means that it is issued from the interviews stage and DEBAT_TEAM means that it is issued from the DEBAT project team.

‘Need’ The level of requirement precedence. These are (in decreasing order of importance) 1, 2, 3, 4 and 5. They reflect the importance and urgency given to each requirement. The requirements with higher priority levels shall be satisfied first. Note, that a level 1 requirement worded using ‘should’ will still be a lower priority than a level 2 requirement worded using ‘shall'.

‘Note’ For some of the requirements there is a following note that expands and clarifies the description of the requirement and any particular implications.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xvi

1.4 Definitions

Data Model The data model is the name of the DEBAT Data Modeller internal format of the data description. This internal format contains all syntactic and semantic information of the data. It is created, modified and read by the DEBAT Data Modeller and is used to generate the EAST and DEDSL description files.

EAST description file The EAST description file contains the syntactic information of a data model in the EAST format. This file is conform to the EAST recommendation. It is created by the DEBAT Data Modeller and is used by all other tools to read, generate, extract, check data products.

DEDSL description file The DEDSL description file contains the semantic information of a data model in the DEDSL format. This file is conform to the DEDSL recommendation. It is created by the DEBAT Data Modeller and is used by all other tools when the semantic information of a data product are managed.

1.5 Structure of the document

This document is organised as follows:

Chapter 1: IntroductionThe current chapter gives the objectives, scope, conventions and structure of the document.

Chapter 2: General DescriptionThis chapter provides a general description of the DEBAT software and the environment in which the system operates. It also presents the general factors that affect the DEBAT software and its requirements. Chapter 3: Capability RequirementsThis chapter presents the capabilities of the DEBAT software needed by users to solve a problem or achieve an objective.

Chapter 4: Constraint RequirementsThis chapter details the constraints and restrictions placed by users on how the problem is to be solved or the objective achieved.

Chapter 5: List of RequirementsThis last chapter lists all user requirements detailed in the chapters 3 and 4.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xvii

2. General Description

2.1 Product perspective

DEBAT will leverage the current EAST technologies and associated tools by providing a complete environment for data handling all along the data life cycle. The following tools are currently associated with the EAST technology:

The OASIS tool for modelling data,

The DUW tool used to read/generate data products,

The DEW tool used to extract information from data products,

EAST command-line utilities (e.g. DATA_CHECKER, ASCII_DUMP,…),

The interpreter and generator tools are the core of the technology and are then used by all other tools.

The limitations of these tools are the following: EAST concepts are really strong, but using the technology can sometimes require some

knowledge of the underlying principles as the modelling scheme may have serious performance impacts,

An in-depth technical knowledge and understanding of EAST tools mechanisms (notably, for the low level APIs), is required in order to make the best use of the tools. For instance, parsing a huge data file can lead to very poor performances if the user do not know (nor understand) the existing optimisation mechanisms,

End-user dissatisfaction because of the lacks/weaknesses of the technology and its associated tools (e.g. not friendly MMI, poor performances),

Inconsistencies between the tools (e.g. some models generated in OASIS can not be read by the other tools),

Modelling problems since the EAST norm lacks of some features (e.g. EAST has no calculation capabilities, OASIS does not manage types libraries …),

Some bugs because most of the existing EAST tools have been created in the frame of Research & Development projects and used as such by projects (it's worth mentioning that the level of methodology applied during the development is satisfactory and that the EAST core is reliable enough to be used in operational projects. The main encountered bugs concern the OASIS GUI that can be improved and made more reliable),

Lacks of architectural point of view: EAST is currently just a set of norms and tools and there is no indication (methodology or facilities) of how to integrate EAST tools within a more global architecture, or of how to connect these tools with a distributed middleware or an existing infrastructure.

The challenge of DEBAT is then to leverage the EAST data workshop concepts (set of norms and collections of tools) towards an unified view of data through a data handling architecture centred on the users needs.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xviii

Some potential scenarios of use of DEBAT architecture are identified below. The power of DEBAT relies on its capabilities to be viewed, adapted and used in a wide range of different use cases.

DEBAT as a data workshop:

Users can directly use DEBAT as a series of enhanced tools covering the entire data life cycle (with almost no architectural concept in mind) as it is the current practice with existing EAST tools. DEBAT can be used in a system without any dedicated effort, as it is a combination of independent tools.

Figure 2-3 DEBAT as a data workshop

DEBAT connecting to external world:

The strong idea with this use scenario is to use the great openness of DEBAT to connect/integrate DEBAT architecture (in)to an existing system or with an existing middleware layer. For instance, if we imagine an archiving facility, it would be interesting to integrate DEBAT architecture tools in a more global archiving facility for ensuring data preservation.

Figure 2-4 DEBAT architecture connecting to real world


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xix

DEBAT as a generic data infrastructure:

This scenario really takes advantage of DEBAT architecture allowing users to build their own system upon the infrastructure provided by DEBAT. This is possible by the enhanced modularity of DEBAT architecture and its strong concepts of dynamic customisation and plug-and-play. This way, users have capabilities to plug-in their own specific processes, their own business logic (for post-processing for example), and their own MMI in an unified infrastructure that offers generic, user-customisable and cost-efficient functionalities.

Figure 2-5 DEBAT as a generic data infrastructure

DEBAT for simulation/testing:

A peculiarly interesting field of application of DEBAT is the simulation/testing arena (for example, within the TM/TC domain). DEBAT should provide generic blocks for easily and cost-efficiently building simulation/testing systems. The advantages gained are obvious: instead of (re)developing simulation/testing systems for each system to be tested, the use of existing DEBAT enhanced data generation functions (to be customised for each mission), should allow to greatly reduce the associated costs and developments duration.

Figure 2-6 DEBAT for simulation/testing


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xx

2.2 General capabilities

This part is divided in two sections. The first section will detail the DEBAT tools while the second will present the main DEBAT features.

2.2.1 DEBAT ToolsThe main capabilities of the DEBAT tools suite will accompany the users throughout the data life cycle.

DEBAT will then consist in the following tools and function : DEBAT Data modeller which will enable users to model any kind of data and generate

the associated EAST and DEDSL description files. It will also be used to create the associated documentation.

DEBAT Producer and Editor which will be used to read and generate data products based on EAST descriptions.

DEBAT Extractor and Querying which will be used to extract relevant information from a whole data product using evolved search capabilities.

DEBAT Post-processing tools which will be used to process the data products (e.g. image viewer).

DEBAT Utilities which gathers all command-line tools based on the existing EAST ones (i.e. DATA_CHECKER, ASCII_DUMP, DEAL, EAST_CRC).

Format translation tools which will be used to insure a compatibility between EAST and other data formats like HDF.

Packaging and compression functionalities to be able to distribute easily the data products.

Figure 2-7. DEBAT inputs and main outputs


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxi

2.2.2 DEBAT featuresThe main features of the DEBAT environment will be:

A modular design that will ease future maintenance (substitute or add functions later with no impact on other functionalities),

The compatibility with the existing data formats (e.g. HDF, CDF, XML,…),

The openness with the use of open-standards like XML,

The portability with the availability of the environment on Unix (Sun), Windows and Linux operating systems,

The accessibility both to novice users (no knowledge of the EAST technology) through evolved help functions as well as to advanced users (with more knowledge of the EAST technology) through the use of the DEBAT API,

High performances,

It is envisaged that DEBAT is designed in such way that users will be able to install only the tools and functions they need. They will also be able to configure the whole environment to better suit their needs,

End-users will also be able to use the DEBAT functionalities either from a friendly graphical user interface or as library functions to be linked to the users’ applications.

All of these features will insure that DEBAT will be easily and widely adopted by the industry.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxii

2.3 General constraints

The following constraints apply to the DEBAT environment : DEBAT is developed on existing EAST tools. Thus, to fulfil all users requirements,

some of these tools will be updated (e.g. Interpreter, Generator,…) while others have to be entirely re-developed (e.g. DUW, DEW).

The expandability and modularity of DEBAT to support the addition/modification of functionalities and the addition of new applications in the environment.

The openness of DEBAT concerning the ease-of-use, the use of open standards (e.g. XML) for development and the format translation capabilities (e.g. EAST to/from CDF, HDF,…).

The portability of the whole environment to Unix, Windows and Linux operating systems.

2.4 User characteristics

The end users’ familiarity with the existing EAST technology and associated tools as well as the requirements towards the hardware and software environments is expected to vary widely. The following three different DEBAT users are then distinguished :

The expert users who are expected to be very familiar with the EAST technology and associated tools,

The modeller users and data managers who may not be familiar with the EAST technology but who know how to use the DEBAT tools to create models and handle data,

The novice users who are expected to have none or few knowledge of the EAST technology and associated tools but who are considered to be experts in their domains (then have a good knowledge of the data they manipulate).

For the purpose of the most, there is no need for complex data processing functions within the DEBAT environment. In fact, most scientists and researchers still have their own favourite processing algorithms to apply to their data. Using the DEBAT API to read the data, they will be freed from the compatibility problems. They will not have to care about the platform on which data were generated as this will be handled by the DEBAT API.

2.5 Application domains

The following application domains are relevant for the DEBAT environment: Space

Management of satellite mission data products: Earth observation data, scientific measurements, etc,

Modelling, simulation and validation of the interfaces between subsystems, Modelling, generation and analysis of telemetry and telecommand packets.

Other domains (aeronautics, energy, transport, etc) that require to model data with a set of powerful data manipulation tools. The great advantages of DEBAT in comparison


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxiii

with other technologies are its capabilities to model binary data and the fact that the data models are separated from the data.

2.6 Operational environment

DEBAT is a complete data life cycle management environment which comprises all required tools from modelling to distribution. The functionalities of the DEBAT environment are accessible through the following external interfaces:

Man Machine Interface: the DEBAT environment will provide a user-friendly GUI that allows users to run any functionalities of the DEBAT tools.

API: it will provide users with a convenient way to use the DEBAT functionalities inside their own software.

Web interface: the Web interface will provide access to a subset of the DEBAT functionalities (the most useful ones) using a Web browser as interface. It is thus intended to enable users to directly use DEBAT functionalities whatever the target platform and without specific installation.

SOAP interface (Web services interface): thanks to the SOAP interface, users’ applications will be able to access remotely to some of the functionalities offered in DEBAT. Web services are small server-side components that can be requested by client software.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxiv

Figure 2-8 DEBAT operational environment

2.7 Assumptions and dependencies

DEBAT accepts data specifications as inputs. Since the performances of data reading/generating are based on the model, strong dependencies exist between the data specifications and the performances of the DEBAT tools and APIs. There is also strong dependencies between the performances and reliability of the DEBAT environment and the performance of the hardware it relies on. The assumption is made here that the DEBAT environment will run on a recent machine (so that the operating system does not overload the machine by itself).

Concerning DEBAT portability, assumption is made in this document that the DEBAT environment will be portable on Unix (Sun), Windows and Linux operating systems.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxv

3. Capability RequirementsCapability requirements describe functions and operations needed by users: functional requirements on the system (what the system should actually do) including interface requirements (so far as these are known at this early stage). Quantitative statements that specify performance and accuracy attributes should form part of the specification of a capability.

The following figure depicts the main user requirements set of DEBAT.

Figure 3-9 Main capabilities requirements set

Each set of user requirements will be described in the next subsections.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxvi

3.1 DEBAT

This part concerns requirements applicable to the whole DEBAT tools suite.

Figure 3-10 DEBAT common functionalities requirements set

3.1.1 Installation

UR 1_DEBATThe DEBAT user shall be able to easily install the DEBAT tools using a graphical installation tool (like InstallShield).

Source I_TNNeed 1Note The same installation procedure will be used for all platforms and this procedure will be common to all DEBAT tools.

UR 2_DEBATThe DEBAT user shall be able to choose between two installation modes: automatic and custom.

Source I_TNNeed 1Note In the automatic mode, all DEBAT tools will be installed whereas in the custom mode, the user will choose which tools to install. In both modes, the user will select the installation directory.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxvii

UR 3_DEBATThe DEBAT user shall be able to uninstall DEBAT.

Source DEBAT_TEAMNeed 1Note

3.1.2 Version management

UR 4_DEBATThe EAST norm shall have a version number. Each (or group of) modification of the norm shall increase the version number.


UR 5_DEBATThe DEBAT tools shall have a single version number. Each (or group of) modification of the DEBAT tools shall increase the version number.


UR 6_DEBATThe EAST and DEDSL description files should have a version number.

Source DEBAT_TEAMNeed 1Note The version number may be very useful for projects that have to deal with evolutions of their data descriptions.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxviii

UR 7_DEBATThe dates of creation and modification of the EAST and DEDSL description files should be stored.

Source DEBAT_TEAMNeed 3Note These information may be accessed to manage the evolution of a data description.

UR 8_DEBATThe EAST and DEDSL description files shall contain the version number of the EAST norm and DEBAT tools with which they were created.

Source DEBAT_TEAMNeed 1Note This will indicate the version with which EAST and DEDSL description files were created.

UR 9_DEBATThe data model shall contain the version numbers of the EAST norm and DEBAT tools with which it was created.

Source I_TNNeed 3Note This will indicate the version with which the data model was created.

UR 10_DEBATWhen loading EAST and DEDSL description files in DEBAT, a message should be displayed if the description was created with earlier versions of the EAST norm and/or the DEBAT tools.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxix

UR 11_DEBATWhen loading a data model in DEBAT, a message should be displayed if the data model was created with earlier versions of the norm and/or the DEBAT tools.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxx

3.1.3 Data Life CycleDEBAT will provide support for the whole data life cycle and then through its five successive stages:

1. A modelling phase whose goal is to specify a non ambiguous, exhaustive, understandable, evolutionary description of the data according to syntactic and semantic aspects of the data,

2. A generating/simulating phase which consists in generating data based on this model,3. A processing phase which will validate the model against the data produced in the previous

phase and will also offer processing functionalities to users (e.g. data extraction, querying),4. A post-processing phase which concerns all domain-oriented processing and where data

products content can be transformed to produce synthesised data directly interpretable,5. A distribution phase which goal is to distribute the processed data to end-users (using CD-

ROM, Internet).

UR 12_DEBATThe DEBAT user shall be able to use DEBAT for the entire data life cycle, from modelling to distribution.


UR 13_DEBATThe DEBAT user shall be able to handle huge volume of data (i.e. up to 6 gigabytes) during their entire data life cycle.

Source I_TNNeed 1Note DEBAT will hide the complexity and the size of data to users.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxxi

3.1.4 Compatibility

UR 14_DEBATAn ascending compatibility shall be kept for the EAST norm and the DEBAT tools.

Source I_TNNeed 1Note With the DEBAT tools, the DEBAT user will be able to use EAST and DEDSL description files created with previous versions of the tools.

UR 15_DEBATIf the ascending compatibility is broken (due to major changes in the EAST norm or DEBAT tools), the DEBAT user should be able to transform the old format of the data model, EAST or DEDSL files into the new one so as to keep the ascending compatibility.

Source I_TNNeed 1Note

UR 16_DEBATThe DEBAT user shall be able to know if the EAST and DEDSL description files he is using are compatible with the installed version of the EAST norm.

Source DEBAT_TEAMNeed 3Note If the EAST norm version of the EAST and DEDSL description files is different than the installed version, the DEBAT user may want to know if the two versions are compatible. Warning messages will be displayed if the EAST and DEDSL description files have different EAST norm versions than the one installed. The user should also be able to know if these description files can be used with the installed version of the DEBAT environment.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxxii

UR 17_DEBATThe DEBAT user shall be able to know if the data model he is using is compatible with the installed versions of the EAST norm and DEBAT tools.

Source DEBAT_TEAMNeed 3Note If the version numbers associated to the data model are different than the installed version numbers, the DEBAT user may want to know if the versions are compatible. Warning messages will be displayed to the user.

UR 18_DEBATIn case the EAST and DEDSL description files are not compatible with the installed versions of the EAST norm and DEBAT tools, a list of the incompatible elements (i.e. their names and paths in the EAST description) should be graphically rendered to users.

Source I_TNNeed 3Note As a complete diagnostic would be complex and costly to implement (need to follow and document with an adequate formalism the evolution of the norms and of the tools), it is envisaged to only display to the users the path and name of the elements in error (it is then up to the user to look for the cause of the error).

InclusionNo Cost High Added Value why and where not JustificationThis feature could be really difficult to implement as it implies to follow and document with an adequate formalism all the evolutions of the norms and of the tools. This feature could lead to a huge amount of work and could be really time consuming compared to the real added-value.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxxiii

UR 19_DEBATIn case the data model is not compatible with the installed versions of the EAST norm and DEBAT tools, a list of the incompatible elements (i.e. their names and paths in the data model) should be graphically rendered to users.

Source I_TNNeed 3Note As a complete diagnostic would be complex and costly to implement (need to follow and document with an adequate formalism the evolution of the norms and of the tools), it is envisaged to only display to the users the path and name of the elements in error (it is then up to the user to look for the cause of the error)..

InclusionNoCost High Added Value why and where not JustificationThis feature could be really difficult to implement as it implies to follow and document with an adequate formalism all the evolutions of the norms and of the tools. This feature could lead to a huge amount of work and could be really time consuming compared to the real added-value.

UR 20_DEBATThe compatibility with the XML technology shall be enforced.

Source DEBAT_TEAMNeed 1Note The popularity of XML and the potential of all the tools that are emerging in its support is such that some sort of synergy between XML and EAST would greatly increase both the perceived and real capabilities of an enhanced EAST.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxxiv

3.1.5 Internationalisation

UR 21_DEBATThe Graphical User Interfaces (menus, labels, buttons, messages, errors) of the DEBAT tools shall be in the English language.

Source DEBAT_TEAM Need 1Note By default, only the English language will be provided, but the addition of a new language will be made easy.

UR 22_DEBATThe user shall be able to choose the language used by the DEBAT tools.

Source DEBAT_TEAM Need 2Note The whole DEBAT environment will be designed so that a new language can be easily added without any further code development.

3.1.6 Online Help

UR 23_DEBATThe DEBAT tools shall provide users with an online help that documents the available functionalities.


UR 24_DEBATThe DEBAT users shall access the online help from the DEBAT tools GUI.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxxv

UR 25_DEBATThe online help shall be available in html format and shall provide a navigable information.


3.1.7 GUI functionalities

UR 26_DEBATThe DEBAT tools shall have a user-friendly graphical interface.

Source I_TN Need 1Note Last available MMI (Man-Machine Interface) standards will be used to create the graphical interfaces.

UR 27_DEBATWithin DEBAT, users shall be able to switch from one tool to another easily.

Source I_TN Need 1Note

UR 28_DEBATThe DEBAT user shall be able to use the tools without any knowledge of the underlying technology.

Source EAST_TN Need 1Note The graphical interface will be designed to hide the complexity of the EAST and DEDSL recommendations to users.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxxvi

UR 29_DEBATThe users shall have direct access to the main functionalities of the tools through shortcuts.

Source DEBAT_TEAM Need 3Note

UR 30_DEBATThe DEBAT user shall easily understand the source of the errors/warnings.

Source I_TN Need 1Note The errors will be graphically displayed with indication of the origin along with a message explaining the reason of the error.

UR 31_DEBATThe DEBAT user should be able to capture some parts of the GUI (such as the data structure description, syntactic and semantic information).


UR 32_DEBATThe DEBAT user should be able to print the captures.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxxvii

UR 33_DEBATThe DEBAT user should be able to save the captures as images.


3.1.8 Documentation generation

UR 34_DEBATThe DEBAT user shall be able to generate documentation about a data description (containing syntactic and semantic information) in RTF format.


UR 35_DEBATThe DEBAT user shall be able to generate documentation about a data description (containing syntactic and semantic information) in HTML format.


UR 36_DEBATThe DEBAT user shall be able to generate documentation about a data description (containing syntactic and semantic information) in PDF format.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxxviii

UR 37_DEBATThe DEBAT user should be able to have access to the version of the documentation corresponding to the version of the data description.

Source I_TN Need 2Note A description can evolve frequently and be manipulated by many users. One of these users will generate the documentation for a particular version of the description. This documentation will then be tied with the version of the data description.

UR 38_DEBATThe DEBAT user shall be able to modify the generated documentation with an external tools (chosen by the users and not provided by DEBAT).


3.1.9 Printing functionalities

UR 39_DEBATThe DEBAT user shall be able to print the whole or parts of data files, EAST description files, DEDSL description files.


UR 40_DEBATThe DEBAT user shall be able print documentation files.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xxxix

3.2 DEBAT Integrated Environment

The DEBAT integrated environment is intended to provide both a framework (that gathers all the tools associated to the EAST technology) and a plug-in system to easily add or simply run new tools in the framework. Indeed, even though the set of tools, that handles EAST descriptions and data, have their own operational needs, they form a homogeneous software suite which shall be available through a single access point.

In order to plug new tools in the framework, a plug-in interface has to be defined. This interface specifies how data can be exchanged between the DEBAT framework and the tools. The plug-in interface also specifies the way tools can be launched and stopped from the framework.

Finally, the DEBAT framework provides users with a GUI allowing them to launch the available tools and to configure the framework. Users can also add new tools thanks to a convenient graphical interface allowing them to set the run command, the icon image and the tool name.

The DEBAT framework also provides projects management capabilities where all related files (i.e. EAST description, data models, data products, documentation) will be grouped. The data can then be shared among all available DEBAT tools and eventually plug-in tools that are conform to the data interface specified by the plug-in system. This way, data can be handled easily during the entire life cycle without any further manipulation.

Figure 3-11 DEBAT integrated environment requirements set


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xl

3.2.1 DEBAT frameworkThe DEBAT framework will propose a simple and intuitive access to a set of DEBAT tools in order to supply users with a homogeneous Look & Feel and behaviour. Thanks to the DEBAT framework, data (models, raw data, computed data, etc) are shared among the available tools and are then handled during their entire life cycle.

UR 41_INTEGRATEDENVUsers shall be able to access the DEBAT framework functionalities through a user-friendly GUI.

Source I_TNNeed 1Note Last available MMI (Man-Machine Interface) standards will be used to create the graphical interfaces.

UR 42_INTEGRATEDENVUsers shall be able to run all the DEBAT tools from the DEBAT framework.

Source I_TNNeed 1Note In order to simplify the use of DEBAT tools, users will access the tools thanks to a single access point.

UR 43_INTEGRATEDENVUsers shall be able to run any other plugged tools from the DEBAT framework.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xli

UR 44_INTEGRATEDENVUsers shall be able to modify the configuration of each tool in the DEBAT framework. The following items shall be configurable: tool image icon, tool name, run command.


UR 45_INTEGRATEDENVUsers shall be able to minimize, maximize or close any window (the framework window or any tool window open in the framework). The user shall also be able to modify the size of any window.


3.2.2 Plug-in systemThe plug-in interfaces intend to provide users with a set of functionalities to plug-in new applications in the framework without recompiling its source code. Thus, users will be able both to customize the framework by adding new tools and to upgrade tools in the framework.

UR 46_INTEGRATEDENVUsers shall be able to plug new tools in the DEBAT framework.

Source I_TNNeed 1Note Users will be able to add new tools in the framework providing that the tools follow the interface specifications of the plug-in system.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xlii

UR 47_INTEGRATEDENVUsers shall be able to launch new tools from the DEBAT framework.

Source I_TNNeed 1Note Users may want to run other tools than the one provided in DEBAT. The framework graphical interface will then propose a list of linked tools (each link being created by the users). Each link will consist in the command used to run the associated tool.

UR 48_INTEGRATEDENVUsers shall be able to upgrade the tools in the DEBAT framework.

Source I_TNNeed 1Note The upgrade functionality is the same as the adding functionality except that the tool configuration does not change.

UR 49_INTEGRATEDENVUsers shall be able to remove tools from the DEBAT framework.

Source I_TNNeed 1Note A tool that is removed will be no more accessible from the DEBAT framework. However, the tool will not be uninstalled from the operating system.

UR 50_INTEGRATEDENVWhen plugging a new tool, users shall be able to define, through a convenient GUI, the following configuration information: tool image icon, tool name, run command.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xliii

3.2.3 Project management

UR 51_INTEGRATEDENVThe DEBAT environment shall support the project management concept.

Source I_TNNeed 1Note A project is common to all DEBAT tools of the framework and consists in a bundle containing: data models, EAST and DEDSL description files, data products, processed data, project documentation.

UR 52_INTEGRATEDENVUsers shall be able to create new projects in the DEBAT environment. The creation process is realised through a GUI of the framework.


UR 53_INTEGRATEDENVWith no further manipulation, users shall be able to use the data of a project in any DEBAT tool or plugged tool that complies with the data interface specifications of the DEBAT framework.

Source I_TNNeed 1Note Data loaded in the framework will be used in any available tool with no further manipulation.

UR 54_INTEGRATEDENVThe project should manage the versions of the EAST and DEDSL description files.

Source DEBAT_TEAMNeed 3Note Users will be able to display the version numbers of the EAST and DEDSL description files. If they modify the data model from which the description files are generated, they will be able to set a new version number.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xliv

UR 55_INTEGRATEDENVUsers should be able to modify the version number graphically

Source DEBAT_TEAMNeed 3Note Note


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xlv

3.3 Web Interface

The Web interface gathers both the local web site and the web services.

Figure 3-12 Web Interface requirements set

Globally, the Web interface will offer the following functionalities :

Web Site Web ServicesRead an EAST description Read a data product Generate a data product Search for elements Extract values from a data product Check that an EAST description is valid against the EAST norm Check that a data product is conform to a particular EAST description Transform a data product using its associated EAST description into XML Visualise data product with a 2D graphical tool Online Help


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xlvi

3.3.1 Local Web SiteA local web site (tied with a particular installation of DEBAT) will be provided in DEBAT for users to be able to use some of the functionalities using a web browser as interface. The functionalities offered by this web site will be limited due to the limitations of web browsers (e.g. difficulty to create a friendly and responsive MMI) and to the limitations of the network (i.e. it will be difficult to use large files with the Web site).

Figure 3-13. Local Web Site Requirements set.

This will enable remote users to directly use DEBAT functionalities whatever the target platform and without specific installation.

UR 56_WEBRemote users shall be able to read an EAST description using the DEBAT Local Web site through a web browser.

Source DEBAT_TEAM Need 2Note The Web site will offer a friendly graphical interface for users to read and display EAST descriptions graphically. The user will have first to upload the EAST description to the server through an HTTP upload function provided by the browser.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xlvii

UR 57_WEBRemote users shall be able to display a data product using the DEBAT Local Web site through a web browser.

Source DEBAT_TEAM Need 2Note The Web site will offer a friendly graphical interface for users to read and display data products graphically. The data product has to be uploaded to the data server first using an HTTP upload function provided by the browser.

UR 58_WEBRemote users shall be able to automatically generate a data product using the DEBAT Local Web site.

Source DEBAT_TEAMNeed 2Note The Web site will offer a friendly graphical interface for users to generate data products corresponding to an EAST description. The user will have first to upload the EAST description to the server through an HTTP upload function provided by the browser.

UR 59_ WEBRemote users shall be able to save the generated data files locally to disk.

Source DEBAT_TEAMNeed 2Note The generated data product will be automatically downloaded through the HTTP connection of the browser.

UR 60_WEBRemote users shall be able to search for elements using their names.

Source DEBAT_TEAMNeed 2Note The result will be graphically displayed in a list.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xlviii

UR 61_WEBRemote users shall be able to search for elements using their types.

Source DEBAT_TEAMNeed 2Note The result will be graphically displayed in a list.

UR 62_WEBRemote users shall be able to extract elements from a data products.

Source DEBAT_TEAMNeed 2Note The Web site will offer a friendly graphical interface for users to be able to select elements to extract.

UR 63_WEBRemote users shall be able to extract elements resulting from a previous search.


UR 64_WEBRemote users shall be able to save the extracted elements locally to disk.


UR 65_WEBRemote users shall be able to check that an EAST description is valid against the EAST norm.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xlix

UR 66_WEBRemote users shall be able to check that a data product is conform to a particular EAST description.


UR 67_WEBIn case of incompatibility, a list of non-conform elements shall be displayed.


UR 68_WEBRemote users should be able to transform a data product into XML using its associated EAST description.


UR 69_WEBRemote users should be able to save the resulting XML file to disk.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : l

UR 70_WEBRemote users should be able to visualise data products with a 2D graphical tool through the web browser.


UR 71_WEBAn HTML online help shall be provided to users.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : li

3.3.2 Web ServicesWeb services will enable remote users to access remotely to some of the functionalities offered in DEBAT through a Web service interface (i.e. through SOAP over HTTP). Web services are small server-side components. In this case, remote users will have to use a specific client software to access these functionalities remotely. Furthermore, due to the limitations of the network, it will be difficult to deal with large files.

Figure 3-14. DEBAT Web Service architecture

In this architecture, new web services can be easily added. However their use in the frame of DEBAT is limited due to the web services technology : A specific client is required to locate and connect to the web services. This client will have to

propose a friendly graphical interface for the data products and EAST description to be displayed conveniently.

Few functionalities can be transformed into web services and these functionalities are limited due to the network.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lii

The following functionalities will be available through web services :

Figure 3-15. DEBAT Web Services requirements set.

UR 72_WEBA web service shall propose the functionality to read EAST description files.


UR 73_WEBA web service shall propose the functionality to read data products (provided an EAST description exists).


UR 74_WEBA web service shall propose the functionality to generate data products (provided an EAST description exists).



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : liii

UR 75_WEBThe user shall be able to save the generated data files locally to disk.


UR 76_WEBA web service shall offer the functionality to check an EAST description against the EAST norm.


UR 77_WEBA web service shall offer the functionality to check an existing data product against the associated EAST description.


UR 78_WEBIn case of incompatibilities, the users shall be able to get a list resuming all encountered errors.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : liv

UR 79_WEBA web service should offer the functionality to transform a data product to XML using its associated EAST description.


UR 80_WEBThe user should be able to save the XML file (converted from the EAST and data files) to disk.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lv

3.4 EAST core

The EAST core gathers all low-level functionalities used by the EAST tools to manipulate EAST description files and associated data products. The EAST core is then an API providing users with the following convenient features:

to read and interpret EAST description files,

to check EAST description files against the EAST norm,

to read data products provided an EAST description exists,

to generate data products provided an EAST description exists,

to verify the conformity of a data products against the associated EAST description.

The following figure details the main user requirements set concerning the EAST API :

Figure 3-16. EAST core requirements set

3.4.1 General requirements

UR 81_EASTCOREAll the existing EAST core functionalities shall be available in the future version proposed by DEBAT.

Source DEBAT_TEAMNeed 1Note The existing functionalities will be kept and be used the same way as they are with the current technology.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lvi

UR 82_EASTCOREThe EAST core shall implement all the features of the EAST norm.


UR 83_EASTCOREThe performances of the EAST core shall be drastically improved.

Source I_TNNeed 1Note The performances of the existing Interpreter tool have already been improved but more improvements are possible. On the contrary, the Generator has never been looked after concerning its performances. We have already carried out some benchmarks and found some ways to improve performances. However, this requirement is difficult to express (as the performances depend on the model). For the interpreter, starting from a given model/associated data (with known performances) we can expect an improvement of at least 20% (execution time). For the Generator, we can expect that its performance will be at least equals to the performances of the Interpreter.

UR 84_EASTCOREUsers shall rely on a robust EAST core.

Source EAST_TN, I_TNNeed 1Note The EAST core will be responsive enough for users to work conveniently and this whatever the complexity of the EAST description and of the data products. Furthermore, the EAST core shall return error messages to users for any occurring problem.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lvii

UR 85_EASTCOREThe EAST core shall store in a file the logbook containing warnings and errors raised during the reading or writing of data products.

Source DEBAT_TEAMNeed 2Note The messages of the logbook will be enough explicit so that users (both developers and end-users) can understand the reason of the errors or warnings.

UR 86_EASTCOREUsers shall be able to open the logbook from the DEBAT environment (using an integrated text editor).


UR 87_EASTCOREUsers shall be able to use the EAST API with the ADA, Fortran, C, C++ and Java programming languages.

Source I_TNNeed 1Note In the current state of the technology, an API is available only for ADA, C and Fortran programming languages.

UR 88_EASTCOREAll warning and errors raised in the EAST core shall be accessible through the API.

Source I_TNNeed 3Note Programmers may be able to use these information in their applications and process errors and warning automatically.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lviii

UR 89_EASTCOREUsers should be able to use the EAST API through CORBA.

Source I_TNNeed 5Note The goal is to be able to use the EAST API remotely and as conveniently as it may be locally.

3.4.2 EAST Description Handling

UR 90_EASTCOREThe EAST core shall propose the functionalities to read and interpret a data description in the EAST format.

Source DEBAT_TEAMNeed 1Note The API should offer means to interpret EAST descriptions.

UR 91_EASTCOREThe EAST core shall identify elements in an EAST description on the basis of their full paths.

Source DEBAT_TEAMNeed 1Note Problems appeared as the EAST core was not able to differentiate many elements having the same name in a particular description (though their paths were different).This is an important problem since discriminants are reffered to only with their names and not with their whole paths. As a result wrong values may be used as discriminants.

UR 92_EASTCOREThe EAST core shall be able to check if an EAST description is valid.

Source DEBAT_TEAMNeed 1Note The API should offer means to verify EAST descriptions against the EAST norm.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lix

UR 93_EASTCOREThe EAST core shall be able to handle basic calculation functions (i.e. +, -, *, /, odd, even).

Source EAST_TNNeed 1Note

UR 94_EASTCOREThe EAST core shall be able to handle advanced calculation functions (i.e. cosinus, sinus, tan, log, !, ^²,^ⁿ ).


UR 95_EASTCOREThe EAST core shall be able to handle operators priority and parenthesis.


UR 96_EASTCOREThe EAST core should be able to handle some algorithmic features (i.e. control structures).



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lx

UR 97_EASTCOREThe EAST core should be able to handle data discriminated by an integer, an enumeration, a character, a float or a string.

Source EAST_TNNeed 4Note In the current technology, it is only possible to discriminate data by an integer, an enumeration or a character.

UR 98_EASTCOREThe EAST core shall be able to handle data discriminated by a computed value.

Source EAST_TNNeed 2Note The computed value will be calculated upon other data values.

UR 99_EASTCOREThe EAST core should be able to handle look-up tables (associate data values with keys).

Source EAST_TNNeed 5Note This table will be used either for data reading and data generation. The keys will be read/generated in the data products and transformed into their real values for further manipulation.

UR 100_EASTCOREThe EAST core shall be able to handle string constants.

Source EAST_TNNeed 3Note In the current state of the technology, it is only possible to create and manage constants of the following basic types : integer, real and character.

3.4.3 Data HandlingThe data handling requirements are divided in three parts :

data reading,


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxi

data generation,

data checking.

3.4.3.1 Data reading

UR 101_EASTCOREUsers shall be able to read data products corresponding to a data description.

Source DEBAT_TEAMNeed 1Note The API should offer means to read and interpret EAST descriptions and also read the associated data products.

UR 102_EASTCOREUsers shall be able to read huge volume of data.

Source I_TNNeed 1Note Users shall at least be able to read data products up to 6 gigabytes. This value (which is not a limit!) of 6 gigabytes has been chosen because in all projects using the EAST technology, they have never faced larger data files. But this is not a hard limit and this is not depend on the host.

UR 103_EASTCOREUsers should be able to read data values from the standard input.

Source I_TNNeed 2Note This requirement raises feasibility and synchronisation issues as the internal format of the EAST core (architecture) assumes that the data can be read block by block and from file (need to review the entire architecture of the tool, could generate performances problems, etc.). What is proposed is a basic solution that caches the received data and saves it to disk before being processed by EAST. It is not a "real-time" processing of the data (the data can not be processed immediately when received), but rather a "near-real time" processing of the data


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxii

InclusionNo Cost High JustificationThe EAST technology has not been designed for real time purposes. The performances of the EAST core implementation are far from what is really required for real-time processing. Though this feature would leverage the use and distribution of the EAST technology, it will be too costly and time-consuming to modify the existing EAST code to include it.

UR 104_EASTCOREUsers should be able to read data values from a socket.


Note A basic solution is proposed (caching the data for "near real time" processing). See UR 103_EASTCORE


UR 105_EASTCOREThe EAST core should be able to handle multi-file data.

Source I_TNNeed 4Note It may then be possible to have an arbitrary breakdown of any data product.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxiii

3.4.3.2 Data generation

UR 106_EASTCOREUsers shall be able to produce data products corresponding to a data description.

Source DEBAT_TEAMNeed 1Note The API will offer means to read and interpret EAST descriptions and then generate the associated data products. This can be done automatically (EAST can produce all values) or manually (users can choose some elements values). Moreover, the API could use default values specified in the EAST description when generating data files.

UR 308_ EASTCOREUsers shall be able to automatically generate data products corresponding to a data description (the EAST core will generate random values for all of the elements)

Source DEBAT_TEAMNeed 1 Note

UR 107_ EASTCOREUsers shall be able to generate manually data products corresponding to a data description (users will be able to specify the values to use for the generation process).

Source DEBAT_TEAMNeed 1 Note


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxiv

UR 107_EASTCOREThe DEBAT generationEAST core tool shall take default values into account when specified for generating a data product conforming to a data description.

Source DEBAT_TEAMNeed 1Note If the user has not specified a rule to apply for a particular element, then the generation tool will look for its default value. If no default value is provided, the generation tool will generate a random value conforming to the syntactic information in the EAST description.

UR 108_EASTCOREThe DEBAT generationEAST core tool shall take integer and real formats into account (this applies to ASCII encoding of integers and reals) when generating a data product.

Source DEBAT_TEAMNeed 1Note If the user has specified an ASCII encoded format for a particular element when designing the data model, the generation tool shall take it into account when generating the associated value. For example, a format of %2.3f will generate a real number having two digits before the dot and three digits after the dot (e.g. 10.123).

UR 109_EASTCOREUsers shall be able to write generated data values on the standard output.


UR 110_EASTCOREUsers should be able to write generated data values in a socket.

Source I_TNNeed 3Note The user will have to enter the IP address and the port to locate the remote machine to access.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxv

3.4.3.3 Data checking

UR 111_EASTCOREUsers should be able to check data programmatically.

Source DEBAT_TEAMNeed 2Note The EAST API will offer means to check particular elements against their types and values (specified in the EAST description) or using user-specified values.

UR 112_EASTCOREUsers should be able to check a data product field by field.


UR 113_EASTCOREThe data checking API should propose different level of checking for a value (warning, error, fatal error).

Source DEBAT_TEAMNeed 4Note The user will be able to refine the checking. For example, the user may choose that the API will generate a warning when an element is inferior to a particular value and a fatal error when this element is superior to another value.

UR 114_EASTCOREThe user should be able to check data values using computed constraints.

Source DEBAT_TEAMNeed 3Note The user will compare (i.e. inferior, superior, equality) one element’s value with another value calculated upon one or more other values identified by their EAST paths.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxvi

UR 115_EASTCOREThrough the API, the user should be able to check data values using external constraints passed as methods’ arguments.


UR 116_EASTCOREThrough the API, the user shall be able to have direct access to the detected errors without the help of external error files.

Source DEBAT_TEAMNeed 2Note The user will then use the result of the checking function in the applications.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxvii

3.5 DEBAT Modeller

Based upon the existing OASIS tool, the DEBAT Data Modeller will be the data description creation tool. It will feature EAST and DEDSL norms and provide a powerful and ergonomic graphical interface. The EAST norm guarantees a complete syntactic description of the data while the DEDSL provides semantic description.

The schema here-below summarises the input/output of the DEBAT Modeller tool:

Figure 3-17 Input and output of DEBAT Modeller

With the DEBAT Modeller tool, users will be able to graphically: model their data:

definition of the logical model – i.e. the data structure, the data type, the range of possible values, etc.

definition of the physical model – i.e. encoding format of the data. give a proper documentation containing the semantic information of the data.

Several facilities will be provided to users during the modelling process. A types library gather types common to all users whatever their projects and their

models. Users can use the types in the library to define an element of their model. They can also create new types and store them in the library if they want to share their new types.

Users can create their model graphically using both a hierarchic view – presenting the model structure and data types – and several panels to define the syntactic and semantic parameters of an element in the model. The navigation in the graphical model will be easy using the mouse, shortcuts and powerful manipulation functions (e.g. copy/paste, cut/paste, remove) and search functions (to easily locate an element in the model).


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxviii

A list of opened data models will also be displayed so that the users can rapidly go from one model to another.

Once the data model is realised, users will be able to check their models – i.e. verify the syntactic validity of the model. Any errors raised by the syntactic check will be displayed to users so that they can correct their model. The following information are displayed: the element which is in error and the cause of the error.

Then, if the data model is valid, users will be able to generate: The EAST description file containing all syntactic information,

The DEDSL description file containing all semantic information. This file can be in two formats: PVL or XML,

The data declarations in ADA, C/C++ and Java in order to be used in other applications that read data products. Developers will not have to redefine the types.

The following figure presents the main user requirements set for the DEBAT Modeller tool:

Figure 3-18. DEBAT Data Modeller requirements set.


UR 117_MODELLERAll the functionalities existing in the current OASIS tool shall be kept in the DEBAT Data Modeller.

Source DEBAT_TEAMNeed 1Note The “Import EAST” function will be hidden so as to be accessible to expert users only.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxix

UR 118_MODELLERAll the bugs found in the current version of the OASIS tool shall be fixed (see [RD6]).


UR 119_MODELLERWith the DEBAT Data Modeller, users shall be able to read the data model created with previous versions of the Data Modeller (and notably with OASIS).

Source I_TNNeed 1Note An ascending compatibility will be kept in order to be able to use existing models.

UR 120_MODELLERWith the DEBAT Modeller, users shall be able to use any new features of the EAST norm which are implemented during the DEBAT project.


UR 121_MODELLERUsers should be able to interface custom applications with the Modeller functionalities.

Source I_TN Need 3Note The following functionalities will be accessible to users from an API: EAST file generation, DEDSL file generation, documentation generation.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxx

UR 122_MODELLERUsers should be able to use the Modeller functionalities through the command line.

Source DEBAT_TEAM Need 1Note Users will not have to launch the DEBAT Modeller tool to execute some actions (e.g. generate EAST, DEDSL and documentation files from the model). A batch mode will be provided. However, users will not have access to the modelling functionalities through the command line.

3.5.2 Model HandlingThe model handling requirements are divided in three parts :

Requirements concerning syntactic information,

Requirements concerning semantic information,

Requirements concerning both syntactic and semantic information.

3.5.2.1 Syntax

UR 123_MODELLERUsers shall be able to enter all syntactic information graphically.

Source DEBAT_TEAMNeed 1Note Users will design data thanks to graphical functionalities. The structure of the data will then appear in a tree view along with associated information. All features of the EAST norm will be accessible to users, even though the complexity of this recommendation will be hidden to users.

UR 124_MODELLERUsers shall be able to specify a format to apply when encoding a number (i.e. integer and real) in an ASCII form.

Source DEBAT_TEAMNeed 2Note This format will be used as input for the generation of the data products. For example, users can enter %2.3f as format for a real number to specify that it is encoded with two digits before the dot and three digits after (e.g. 10.123).


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxi

UR 125_MODELLERThe Data Modeller shall automatically verify that the format entered by users for a particular element is compatible with the size of this element.


UR 126_MODELLERUsers shall be able to specify a default value for the elements.


UR 127_MODELLERUsers shall be able to easily re-use parts of a model in another one.

Source EAST_TN Need 1Note Users will be able to copy/cut and paste parts of a model.

UR 128_MODELLERUsers shall be able to check the syntactic model and get warnings/errors about all missing or incomplete syntactic information.

Source I_TN Need 2Note The model checker of the Data Modeller will inform users about lacks in the model structure and in the syntactic information (e.g. fields ranges, sizes, …)


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxii

UR 129_MODELLERUsers should be able to handle and follow the modifications of a data model.

Source I_TN Need 3Note When users modify a model, the tool will check if the new model is compatible with the old one (i.e. the same data can be modelled with both models).

UR 130_MODELLERUsers shall be able to model size-variable elements discriminated by one or more other fields sizes or values.

Source I_TN Need 1Note The size of elements can be variable in the current technology and be discriminated only by one other element. In DEBAT, users will create size-variable elements upon two or more other elements (using basic calculation functions) which sizes will then be calculated at runtime.

UR 131_MODELLERUsers should be able to define look-up tables in the models graphically.

Source I_TN Need 5Note Users will define a table containing keys and values. In the data, the values are replaced by the keys so as to reduce the space required to store the data.

3.5.2.2 Semantic

UR 132_MODELLERUsers shall be able to enter all semantic information graphically.

Source DEBAT_TEAM Need 1Note The existing graphical interface to enter semantic information will be modified since not convenient for users.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxiii

UR 133_MODELLERUsers shall be able to define semantic attributes of the following types: files or images.

Source DEBAT_TEAM Need 3Note Existing files or images (e.g. UML diagrams, Word documents explaining the mission,…) can be added in the DEDSL description and be included in the generated documentation.

3.5.2.3 Common

UR 134_MODELLERUsers shall be able to save the syntactic and semantic information to disk (without generating the corresponding EAST and DEDSL files), even if the model is incomplete.

Source DEBAT_TEAM Need 1Note The information will be stored in the DEBAT Modeller internal format.

UR 135_MODELLERThe DEBAT Modeller internal format shall be transformed to XML.

Source DEBAT_TEAM Need 1Note The DEBAT Data Modeller will still be able to use existing internal format files but all new models developed with the DEBAT Data Modeller will be stored in an XML internal format. The XML internal format will be made compliant with the DRB tool (http://www.gael.fr/drb)

UR 136_MODELLERThe Modeller user shall be able to load the syntactic and semantic information from the data model (stored on disk).



http://www.gael.fr/drb

User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxiv

3.5.3 Type handling

UR 137_MODELLERThe DEBAT Modeller tool shall support the type library concept.

Source EAST_TN, TMTC_TN, I_TNNeed 1Note The concept of types library is to gather useful types in a common library. These types will then be available for any Modeller user and can be used to type an element of the description.

UR 138_MODELLERUsers shall be able to create new types and store them in the library.

Source DEBAT_TEAM Need 1Note The types that are created will not be necessarily stored in the library. Users will also be able to use these new types in their own model.

UR 139_MODELLERUsers shall be able to use types stored in the library.

Source DEBAT_TEAM Need 1Note Types of the library can be used to type an element of the description.

UR 140_MODELLERUsers shall be able to modify a type of the library.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxv

UR 141_MODELLERUsers shall be able to import a type into the library.

Source DEBAT_TEAM Need 1Note Users will then add existing types into the library. These types may then be used to type any elements.

3.5.4 Graphical User Interface

UR 142_MODELLER The Modeller tool shall provide users with the possibility to mask parts of the model.

Source I_TN Need 1Note Only parts of interest will then be graphically displayed to users.

UR 143_MODELLER The Modeller tool shall provide users with the possibility to visualise the masked parts of the model.


UR 144_MODELLER The Modeller tool shall provide users with the possibility to select a particular element in the model view.

Source I_TN Need 1Note The syntactic and semantic information for this element will automatically be displayed.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxvi

UR 145_MODELLERThe DEBAT Modeller tool shall provide users with remove capability to suppress elements from the model.

Source I_TN Need 1Note This functionality is not working properly in the current version of the OASIS tool.

UR 146_MODELLERThe DEBAT Modeller tool shall provide users with copy and paste capabilities for the model manipulation.

Source I_TN Need 1Note Users will be able to copy an element in the model and to paste it in another place in the same model or in another one still in the DEBAT data modeller.

UR 147_MODELLERThe DEBAT Modeller tool shall provide users with cut and paste capability for the model manipulation.

Source I_TN Need 1Note Users will be able to remove an element in the model and to paste it in another place in the same model or in another one still in the DEBAT data modeller.

UR 148_MODELLERUsers shall be able to copy a text selection (such as a syntactic or semantic parameter value) and to paste it in another text field within the Modeller tool.

Source I_TN Need 1Note Users will be able to copy text from one field in the Modeller and paste it into another field (still in the Modeller).


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxvii

UR 149_MODELLERUsers should be able to copy a text selection (such as a syntactic or semantic parameter value) in the Modeller and to paste it in another location (out of the Modeller tool).

Source I_TNNeed 4Note Users will be able to copy text from one field in the Modeller and paste it into another location (e.g. in a Word document).

UR 150_MODELLERUsers should be able to copy a text selection from another tool (out of the scope of the DEBAT environment) and to paste it into a text field in the Modeller.

Source I_TN Need 4Note Users will be able to copy text from one document (e.g. Word Document) and paste it to a text field in the Modeller.

UR 151_MODELLERThe DEBAT Modeller tool should provide users with a drag and drop capability for the model manipulation.

Source I_TN Need 3Note Users will be able to drag and drop types from the model to the types library. This functionality may be also used to move elements in the model view.

UR 152_MODELLERThe DEBAT Modeller tool should provide users with an undo/redo functionality.

Source I_TN Need 2Note Users will be able to cancel the actions they have just done.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxviii

UR 153_MODELLERThe DEBAT Modeller tool shall provide search functionalities to locate elements using any syntactic information (i.e. name, type, size, bounds).

Source I_TN Need 3Note As an example, users will then be able to search for all integers having the following range : 0..10 (or using one of these two bounds as input for the search).

UR 154_MODELLERThe DEBAT Modeller user shall be able to use the wildcards ('*' and '?') when searching for an element using its name or type.

Source I_TN Need 3Note As an example, users will then be able to search for all elements beginning with the “int” prefix using “int*” as search criteria.

UR 155_MODELLERThe user should be able to locate elements using any combination (using “and” and “or” operators) of the syntactic information (i.e. name, type, sizes, bounds).

Source I_TN Need 4Note As an example, users will then be able to search for all elements which sizes are 10 or 15. They can also combine more than two information to search for example for all integers having a size of 10 which inferior bound is 0.

UR 156_MODELLERThe DEBAT Modeller tool should provide search functionalities to locate elements using semantic attributes.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxix

UR 157_MODELLERThe DEBAT Modeller user should be able to use regular expressions when searching for an element using its name or type.


UR 158_MODELLERThe search results shall be rendered to users as a list of corresponding elements.


UR 159_MODELLERThe DEBAT Modeller tool should provide a clone functionality for users to copy the model view and open another view with this copy.


InclusionNo

UR 160_MODELLERThe DEBAT Modeller tool should provide a zoom functionality for users to focus on a precise part of the model view.


3.5.5 GenerationThe DEBAT Modeller tool is able to generate

the EAST and DEDSL files from the syntactic and semantic descriptions,


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxx

type data declarations in various languages so that it can be used in external applications,

documentation about the data description.

3.5.5.1 EAST/DEDSL

UR 161_MODELLERUsers shall be able to generate the EAST description corresponding to the current model and save this file to disk.


UR 162_MODELLERUsers shall be able to generate the DEDSL file corresponding to the semantic information entered by users and save this file to disk.

Source DEBAT_TEAM Need 1Note The DEDSL file will be in the XML format or in the PVL format.

3.5.5.2 Programming languages support

UR 163_MODELLERUsers shall be able to generate type data declarations in ADA, C/C++ and Java.

Source DEBAT_TEAM, I_TNNeed 1Note Thanks to this feature, users will be able to integrate easily the type data declarations in their applications without having to produce more code.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxxi

3.5.5.3 Formats file

UR 164_MODELLERUsers shall be able to generate a file containing the EAST paths of the elements (i.e. integer and real) to format along with the associated format.

Source DEBAT_TEAM, I_TNNeed 1Note In the current state of the technology, users have to create the format file by hand. In DEBAT, users will enter their formats while creating the data model so that the format file could be generated by the Modeller tool. This format file will then be used as input in the data generation process.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxxii

3.6 DEBAT Producer & Editor

The DPE tool will offer an easy access to data. With this tool, users will be able to read, edit, produce and modify data products that follow an EAST description. Users will be able to access parameters values by an easily graphical way. The useful tool GUI allows to change, read or generate data without any code development.

Figure 3-19 Input and output of the DEBAT DPE

The main functionalities of this tool will be : to consult data products (provided an EAST description exists) in a graphical

representation and navigate through this representation using the mouse, shortcuts and search capabilities,

to generate data with the possibilities for users to fill some elements’ values by handif necessary (i.e. there will be two generation modes: fully automatic generation or user-controlled process),

to modify data manually (a check will be performed to verify that values entered are conform to the EAST description),

to check the visualised data product against the associated EAST description.

The following figure presents the main user requirements set of the DPE tool:

Figure 3-20. DPE requirements set.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxxiii

3.6.1 EAST description Handling

UR 165_DPEUsers shall be able to display an EAST description content graphically.

Source DEBAT_TEAMNeed 1Note Based on an EAST description specified by a user, the DPE will display the EAST description graphically.

UR 166_DPEUsers shall be able to display an EAST description content as a tree structure view.


UR 167_DPEUsers should be able to display an EAST description content as a data byte flow view.


UR 168_DPEUsers shall be able to display non complete EAST descriptions graphically.

Source I_TNNeed 3Note A message will be displayed to users to warn them about the incomplete description. Then a list of all undefined elements may be rendered to users or these elements may be graphically highlighted.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxxiv

UR 169_DPEUsers shall be able to display DEDSL files corresponding to a particular description.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxxv

3.6.2 Data HandlingThe data handling requirements are divided into five main parts :

Figure 3-21. DPE data handling user requirements.

3.6.2.1 Data Reading

UR 170_DPEUsers shall be able to display data files graphically.

Source DEBAT_TEAMNeed 1Note Based on an EAST description and the associated data file specified by a user, the DPE will display all elements and their associated values graphically.

UR 171_DPEUsers should be able to handle data cut in several packets.

Source I_TNNeed 3Note Large data files are sometimes separated physically in many smaller data packets (e.g. for transport purposes). Each packet contains the data of interest along with information used to identify this packet and then be able to reconstruct the whole data file. Users may want to read and extract data of interest from these packets with one particular EAST description and then read the whole data file with another EAST description.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxxvi

UR 172_DPEUsers should be able to read data from the standard input.

Source I_TNNeed 2Note This requirement raises feasibility and synchronisation issues as the EAST architecture assumes that the data can be read block by block and from file (need to review the entire architecture of the tool, could generate performances problems, etc.). What is proposed is a basic solution that caches the received data and saves it to disk before being processed by EAST. It is not a "real-time" processing of the data (the data can not be processed immediately when received), but rather a "near-real time" processing of the data


UR 173_DPEUsers should be able to read data from a socket.

Source I_TNNeed 3Note A basic solution is proposed (caching the data for "near real time" processing). See UR 172_DPE.

Inclusion No Cost HighJustificationThe EAST technology has not been designed for real time purposes. The performances of the EAST core implementation are far from what is really required for real-time processing. Though this feature would leverage the use and distribution of the EAST technology, it will be too costly and time-consuming to modify the existing EAST code to include it.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxxvii

UR 174_DPEUsers shall be able to easily navigate into a whole data product.

Source I_TNNeed 1Note Data files are separated in many blocks. Users will be allowed to set the number of blocks to be displayed at the same time. Users will use forward and backward functionalities to navigate through the whole product. Users may also request a particular block directly by specifying its rank.

3.6.2.2 Data GenerationThere are two modes in the generation process :

Firstly, users may let the tool generate all values on its own. The tool will then use the syntactic information defined in the EAST description file to generate all the elements’ values.

Users may also choose to enter some elements’ values before generating the whole data product. The tool will use the user values for these elements and the syntactic information defined in the EAST description for all other elements when generating data products.

In both cases, users may choose to generate valid data products where all values are corresponding to the syntactic information defined in the EAST description file or to generate wrong data products where some or all values may be incorrect.

UR 175_DPEUsers shall be able to generate automatically a data product corresponding to a particular EAST description.

Source DEBAT_TEAMNeed 1Note All values will be randomly set by the tool. The generation process will also handle default values when specified.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxxviii

UR 176_DPEUsers shall be able to precise some elements’ values when generating a data file corresponding to a particular EAST description.

Source DEBAT_TEAMNeed 1Note Users will graphically select which elements they want to set and enter their values. The only restriction here is that the size of the elements correspond to the size defined in the EAST file. All other values will be randomly generated by the tool upon syntactic information and default values defined in the EAST file.

UR 177_DPEUsers shall be able to enter some elements’ values graphically.

Source DEBAT_TEAMNeed 1Note Users will navigate in the graphical view and choose which values to enter. These values will be checked against the syntactic information contained in the EAST description.

UR 178_DPEUsers shall be able to enter some elements’ values in a file.

Source DEBAT_TEAMNeed 1Note This file will contain elements’ paths and their associated values. The DPE will read this file, check the values against the syntactic information and automatically update the graphical view.

UR 179_DPEUsers should be able to enter calculation formulas to define how values are to be generated.

Source DEBAT_TEAMNeed 4Note This requirement includes calculation functions like +, *, sin, cos,… but also operator priority and parenthesis.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : lxxxix

UR 180_DPEUsers should be able to enter algorithms to set how data values are to be generated.


UR 181_DPEUsers shall be able to generate automatically “wrong” data product corresponding to a particular EAST description.

Source DEBAT_TEAMNeed 1Note Users will first select which elements should have wrong values. During the generation, the tool will follow the rules defined in the description (concerning elements sizes and bounds) except for the elements selected by users.

UR 182_DPEUsers shall be able to generate automatically “wrong” data product and enter wrong values.

Source DEBAT_TEAMNeed 1Note Users will first select which elements should have wrong values and will enter the values for these particular elements. During the generation, the tool will follow the rules defined in the description (concerning elements sizes and bounds) except for the elements selected by users.

UR 183_DPEUsers shall be able to generate values on the standard output.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xc

UR 184_DPEUsers should be able to write generated data values in a socket.

Source I_TNNeed 3Note Users will have to enter the IP address and the port to locate the remote machine to access.

3.6.2.3 Data Checking

UR 185_DPEThe DPE tool shall check the consistency of data products before displaying them.

Source I_TNNeed 2Note Before displaying a data product, the DPE will automatically check it against the associated EAST description file.

UR 186_DPEThe DPE tool shall display to users a list of inconsistencies if errors are detected during the checking process.

Source I_TNNeed 2Note The reason of the errors will be accessible. The wrong values for the elements will be displayed along with the expected ones so that users will be able to clearly understand the source of the errors.

UR 187_DPEThe DPE tool shall display the data product to users even if inconsistencies are detected during the checking process.

Source I_TNNeed 2Note The elements creating errors will be displayed along with the “bad value” string to be graphically identifiable.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xci

3.6.2.4 Data Manipulation

UR 188_DPEUsers shall be able to modify elements values using the DPE graphical interface.

Source DEBAT_TEAMNeed 1Note The elements and their values will be displayed graphically and users will simply navigate in the description view and choose which value to modify. Users will then be asked for a new value for the selected element.

UR 189_DPEThe DPE tool shall automatically verify user values against the associated syntactic information in the EAST file.


3.6.2.5 Data Storage

UR 190_DPEUsers shall be able to save the data files to disk.

Source DEBAT_TEAMNeed 1Note Users will be asked for the saving directory and the name of the file.


UR 191_DPEThe DPE tool MMI shall not be blocked while executing users actions.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xcii

UR 192_DPEThe DPE tool shall provide users with the possibility to mask parts of the EAST description.

Source I_TN Need 1Note Only parts of interest will then be graphically displayed to users in the EAST description view window.

UR 193_DPEThe DPE tool shall provide users with the possibility to visualise the masked parts of the EAST description.


UR 194_DPEThe DPE tool shall provide users with copy and paste capability for manipulating data values.

Source I_TN Need 1Note Users will then be able to copy one value and paste it to other elements.

UR 195_DPEThe DPE tool should provide users with an undo/redo functionality.

Source I_TN Need 4Note Users actions in the DPE will automatically be registered so that it will be simple for them to cancel the actions they have just done. This will be convenient in case of users errors since the action could be cancelled in one click on the undo functionality.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xciii

UR 196_DPEUsers shall be able to search elements using EAST paths or any syntactic information (i.e. names, types, bounds, sizes) as search criteria.

Source DEBAT_TEAMNeed 1Note One graphical interface will be available for users to enter these criteria. The resulting elements will be highlighted in the EAST description view or may be displayed as a list of elements (each element being identified by its name and its EAST path) according to the users choice.

UR 197_DPEUsers should be able to search elements using their values as search criteria.

Source DEBAT_TEAMNeed 2Note One graphical interface will be available for users to enter these criteria. The resulting elements will be highlighted in the EAST description view or may be displayed as a list of elements (each element being identified by its name and its EAST path) according to the users choice.

UR 198_DPEUsers shall be able to use the wildcards ('*' and '?') as part of the search criteria.

Source DEBAT_TEAMNeed 1Note Users will then be able to check for elements without knowing their complete names or types. For example, searching for the “int*” element name will display all elements which names begin with the “int” substring.

UR 199_DPEUsers should be able to use regular expressions as search criteria.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xciv

UR 200_DPEUsers shall be able to combine several criteria to refine the search.

Source DEBAT_TEAMNeed 2Note One graphical interface will be available for users to enter these criteria and select how to combine them (using the AND and OR logical operators).

UR 201_DPEThe search results shall be displayed as a list of elements.

Source DEBAT_TEAMNeed 2Note This list will contain the name of the elements responding to the search criteria along with their associated values and their EAST paths.

UR 202_DPEUsers shall be able to change the data values directly in the search result list.

Source DEBAT_TEAMNeed 2Note While looking at the search results, users may want to change the data values at will. The data product view will automatically be updated with the new values entered by users. This will enable users to change values of precise elements without having to navigate through the whole data product.

UR 203_DPE Users shall easily understand the source of the errors/warnings.

Source I_TN Need 1Note The errors will be displayed with indication of the origin along with a message explaining the reason of the error.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xcv

3.7 DEBAT Extractor & Querying

Users could not be interested by all values contained in a data product and may want to extract parts and generate smaller files which could be easily disseminated over the network. This is particularly relevant for very large data files that are difficult to handle and transport.

The DEQ tool is primarily designed to offer mean to easily extract values from data products responding to search criteria (e.g. time, value,…) and create new packages upon these results. Extracted information are then displayed and may be modified before being saved to disk. The goal is to create new data packages that will be used as input for other post-processing tools.

Figure 3-22 Input and output of the DEBAT DEQ

The main functionalities of the tools are then summarises here-below: to consult data products (provided an EAST description exists) in a graphical

representation and navigate through this representation using the mouse, shortcuts and basic search capabilities,

to search for elements using built-in search capabilities in one or more data products at the same time,

to search for elements using an XML query language over an XML view of the data,

to extract elements to create new data packages either from users’ choices (users will select graphically the elements to extract) or resulting from a previous search.

The following figure presents the user requirements set of the DEQ tool:


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xcvi

Figure 3-23. DEQ requirements set

3.7.1 EAST description handling

UR 204_DEQUsers shall be able to display an EAST description graphically.

Source DEBAT_TEAMNeed 1Note Users will open an EAST description and display the elements in a tree structure.

UR 205_DEQUsers shall be able to display an EAST description content as a tree structure view.


UR 206_DEQUsers shall be able to display a non complete EAST description graphically.

Source I_TNNeed 3Note Users will open an EAST description and display the elements in a tree structure.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xcvii

3.7.2 Data handlingThe DEQ data handling requirements are divided into five parts :

Figure 3-24. DEQ data handling requirements.

3.7.2.1 Data reading

UR 207_DEQUsers shall be able to display graphically data products corresponding to an EAST description.

Source DEBAT_TEAMNeed 1Note Users will open an EAST description and associated data products and display the elements in a tree structure along with their values. Users will then navigate in the tree view.

UR 208_DEQUsers should be able to handle data cut in several packets.

Source I_TNNeed 3Note Some data files are very large and are sometimes cut in several packets (one packet contains data and associated information). Users may read these packets (with one particular EAST description), extract data from all these packets and then read the data with another EAST description.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xcviii

UR 209_DEQUsers should be able to read data from the standard input.

Source I_TNNeed 2Note This requirement raises feasibility and synchronisation issues as the EAST architecture assumes that the data can be read block by block and from file (need to review the entire architecture of the tool, could generate performances problems, etc.). What is proposed is a basic solution that caches the received data and saves it to disk before being processed by EAST. It is not a "real-time" processing of the data (the data can not be processed immediately when received), but rather a "near-real time" processing of the data


UR 210_DEQUsers should be able to read data from a socket.

Source I_TNNeed 3Note A basic solution is proposed (caching the data for "near real time" processing). See UR 209_DEQ.

Inclusion No Cost HighJustificationThe EAST technology has not been designed for real time purposes. The performances of the EAST core implementation are far from what is really required for real-time processing. The implementation is this feature is costly and technically complex.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : xcix

UR 211_DEQUsers should be able to easily navigate into a whole data product.

Source I_TNNeed 1Note Data files are separated in many blocks. Only one block will be displayed at one time. Users will use forward and backward functionalities to navigate through the whole product. Users may also request a particular block directly by specifying its rank.

3.7.2.2 Data querying

3.7.2.2.1 Basic query

UR 212_DEQUsers shall be able to search elements using the DEDSL attributes.


UR 213_DEQUsers shall be able to search elements using the elements EAST paths.


UR 214_DEQUsers shall be able to search elements using the elements EAST types.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : c

UR 215_DEQUsers shall be able to search elements using the elements values.


3.7.2.2.2 Advanced Query

UR 216_DEQUsers shall be able to locate parts of the data of interest to extract the corresponding values using any of the syntactic parameters as search criteria.

Source DEBAT_TEAMNeed 1Note The results will be displayed as a list or be graphically highlighted in the graphical description view. Both may also be combined : users will select an element in the list and this element will be highlighted in the EAST description.

UR 217_DEQUsers shall be able to use the wildcards ('*' and '?') in search criteria.

Source DEBAT_TEAMNeed 1Note The * token will replace any string in the search criteria. For example, the “App*” will search the data description for all elements having “App” as name prefix.

UR 218_DEQUsers should be able to use regular expressions as search criteria.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : ci

UR 219_DEQUsers shall be able to combine the search criteria.


UR 220_DEQUsers shall be able to locate data values using time as search criteria.

Source DEBAT_TEAMNeed 1Note Users will have to choose graphically on which elements the search will apply. Users will then have to choose if they want to search for elements where the element to search is inferior, superior or equal to a given date (also entered by users). As a result, a list of all corresponding data blocks will be displayed.

UR 221_DEQUsers shall be able to locate data values using comparison functions as search criteria.

Source DEBAT_TEAMNeed 1Note Users will have to choose on which elements the search will apply, which functions they want to be applied and then launch the search. For example, users will search for all blocks where an element value is inferior to another value. As a result, a list of corresponding data blocks will be displayed.

UR 222_DEQUsers shall be able to check for the existence of elements using their paths.

Source DEBAT_TEAMNeed 1Note Users will have to choose on which elements the search will apply by specifying their paths. As a result, a list of corresponding elements will be displayed.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cii

UR 223_DEQUsers shall be able to locate information in one or more data products at the same time.


UR 224_DEQThe querying functionalities should be available from the API.


UR 225_DEQUsers should be able to use an XML-like query language to process complex queries on the data products.

Source I_TNNeed 4Note Users may create the requests that best suit their needs using powerful XML-like query language.

3.7.2.2.3 Query results

UR 226_DEQThe query results shall be displayed as a list of elements along with the associated values.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : ciii

UR 227_DEQThe query results display shall be configured by users.

Source DEBAT_TEAMNeed 1Note Users will be able to choose the form of the result. For instance, the following form can be proposed to users: tables (each row contains the query results of a particular sub data product; the elements matching the query are displayed in columns), trees (a node per sub data products, the leaves represent the elements matching the query), or XML views of the data product.

UR 228_DEQUsers shall choose the form in which the query results are displayed.


3.7.2.3 Data extraction

UR 229_DEQUsers shall be able to select elements to extract graphically.

Source DEBAT_TEAMNeed 1Note Users will select the elements to extract in the graphical description view.

UR 230_DEQUsers shall be able to extract elements resulting of a search.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : civ

UR 231_DEQUsers shall be able to extract data values while focusing on a precise branch of any EAST description.

Source DEBAT_TEAMNeed 1Note Users will traverse huge data files piece by piece without loading the whole product.

UR 232_DEQThe extraction functionalities should be available from the API.


3.7.2.4 Data processing

UR 233_DEQUsers shall be able to use another application to process the data.

Source DEBAT_TEAMNeed 1Note Users will then extract data and then launch another tool (e.g. viewer tool) with these data as input.

3.7.2.5 Data storage

UR 234_DEQUsers shall be able to save extracted elements to disk.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cv

UR 235_DEQUsers shall be able to write extracted data values on standard output.


UR 236_DEQUsers should be able to write extracted data values in a socket.

Source I_TNNeed 3Note Users will have to enter the IP address and the port to locate the remote machine to access.


UR 237_DEQThe DEQ tool MMI shall not be blocked while executing users actions.


UR 238_DEQ The DEQ tool shall provide users with the possibility to mask parts of the description.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cvi

UR 239_DEQThe DEQ tool shall provide users with the possibility to visualise the masked parts of the description.


UR 240_DEQ The DEQ tool should provide users with an undo/redo functionality.

Source I_TN Need 4Note Users actions in the DEQ will automatically be registered so that it will be simple for them to cancel the actions they have just done. This will be convenient in case of users errors since the action could be cancelled in one click on the undo functionality.

3.7.4 Batch processing

UR 241_DEQUsers should be able to defer the querying of information in data products at a later time.

Source I_TN Need 4Note Users will prepare the querying from one or several data products and choose a launch time (e.g. at night). At the given time, the data products will be queried and the results saved to disk.

UR 242_DEQUsers should be able to defer the extraction of information from data products at a later time.

Source I_TN Need 4Note Users will prepare the extraction of information from one or several data products and choose a launch time (e.g. at night). At the given time, the information will be generated extracted and saved to disk.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cvii

UR 243_DEQUsers should be able to defer the querying and extraction of information in XML views of data products at a later time.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cviii

3.8 DEBAT Utilities

The DEBAT Utilities are all command-line tools used to handle EAST descriptions and data products. The command-line tools are the following:

The ASCII_DUMP tool which produces an ASCII file representing a data file associated with an EAST description.

The DEAL tool produces a file containing all the paths defined in an EAST description.

The EASTcrc tool verifies the checksum of an EAST description.

The DATA_CHECKER tool allow users to check the conformity of a data file with an EAST description.

Figure 3-25 DEBAT Utilities requirements set


UR 244_UTUsers shall be able to use the DEBAT utilities from the command line.Source DEBAT_TEAMNeed 1Note

UR 245_UTUsers shall be able to use the DEBAT utilities from a graphical user interface.Source DEBAT_TEAMNeed 1Note


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cix

3.8.2 ASCII_DUMP

UR 246_UTUsers shall be able to produce an ASCII file representing a data file associated with an EAST description.Source DEBAT_TEAMNeed 1Note The ASCII_DUMP will create a text file containing all elements EAST paths and the associated values encoded in ASCII.

UR 247_UTUsers shall be able to produce an XML file representing a data file associated with an EAST description.Source DEBAT_TEAMNeed 1Note The ASCII_DUMP will create a XML file containing all elements EAST paths and the associated values encoded in ASCII.

3.8.3 DEAL

UR 248_UTUsers shall be able to generate a file containing all the paths defined in an EAST description.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cx

3.8.4 EASTcrc

UR 249_UTUsers shall be able to verify the checksum of an EAST description.

Source DEBAT_TEAMNeed 1Note Users will check that the description has not been modified by hand.

3.8.5 DATA_CHECKER

UR 250_UTUsers shall be able to check data products against EAST descriptions.

Source DEBAT_TEAMNeed 1Note Users will check data products and get the associated results. In case of errors, messages will be detailed enough for users to clearly understand the source of these errors.

UR 251_UTErrors messages shall be located into one single file.

Source DEBAT_TEAMNeed 1Note Detailed error messages will be located into one single file.

UR 252_UTUsers should be able to specify their own checking rules.

Source I_TN Need 3Note Users will specify their own checking rules to check the EAST elements against particular values (different from the values or ranges specified in the EAST description).


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxi

UR 253_UTUsers should be able to specify different checking levels for a value (warning, error, fatal error).

Source I_TN Need 3Note Users will specify their own checking rules along with the checking level.

UR 254_UTUsers should be able to specify the checking level when launching the DATA_CHECKER tool.

Source I_TN Need 3Note The user may be interested only in some kind of errors. For instance, users may want to check only the fatal errors.

UR 255_UTThe user shall be able to specify computed constraints.

Source I_TNNeed 3Note The user will compare elements according to a value computed upon two or more other elements in the data product.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxii

3.8.6 Comparison tool

UR 256_UTThe users should be able to visualise the differences between two descriptions.

Source DEBAT_TEAM Need 2Note These differences can be the existence/absence of an element, the difference in the type of an element, the value of a syntactic parameter or semantic parameter.

UR 257_UTThe differences between two descriptions should be stored as a list in a file.

Source DEBAT_TEAM Need 2Note This list will be divided in two parts: the first part will contain the equivalent elements (i.e. having the same EAST paths) which do not have the same syntactic information while the second will contain elements that do not exist in one of the descriptions. The list also presents the syntactic information that differs for a precise element.

UR 258_UTThe differences between two descriptions should be displayed graphically.

Source DEBAT_TEAM Need 3Note The GUI may display the difference between two descriptions. The two descriptions may be displayed in parallel (like in a text editor) and the differences between the two coloured.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxiii

3.9 DEBAT Post-Processing Tools

The DEBAT post-processing tools are both tools provided with the DEBAT framework and tools plugged in the framework. The user requirements here-below only describe the first category of tools as the other one is not under the DEBAT project responsibility.

The DEBAT post-processing tools that are provided with the framework gather all convenient tools to visualise data, convert data (into XML, HDF or CDF) and to interface with the CAO system.

Figure 3-26 DEBAT post-processing tools requirements set

3.9.1 2D graphical tool

UR 259_PPTThe DEBAT framework shall provide users with a 2D graphical tool.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxiv

UR 260_PPTThanks to the 2D graphical tool, users shall be able to plot data stored in a data product.

Source I_TNNeed 2Note The 2D display tool will plot data in different graphical forms: plot, scatter, bar, pie. Users will also set all plotting parameters: axis label and colour, axis position, title, etc. It will also be possible for the users to plug their own favourite 2D tool (through the plug-in interface.

UR 261_PPTThe 2D graphical tool shall be able to export graphics in the following formats: jpeg and png.

Source I_TNNeed 2Note This tool will also be capable to export graphics in various format (jpeg and png) allowing them to be stored or even inserted in a document. PNG (Portable Network Graphics) is a lightweight image format designed to replace the GIF format since this latter is not royalty-free anymore.

UR 262_PPTUsers shall be able to print the graphics produced by the 2D graphical tool.


3.9.2 Quick looks

UR 263_PPTUsers shall be able to generate quick looks from the raw data.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxv

3.9.3 CAOS

UR 264_PPTUsers should be able to register EAST and DEDSL descriptions in the CAO (Control Authority Office) system.


UR 265_PPTUsers should be able to revise EAST and DEDSL descriptions in the CAO (Control Authority Office) system.


UR 266_PPTUsers should be able to extract EAST and DEDSL descriptions from the CAO (Control Authority Office) system.


UR 267_PPTUsers should be able to search for EAST and DEDSL descriptions in the CAO (Control Authority Office) system.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxvi

3.9.4 Database interface

UR 268_PPTUsers should be able to store data values in a database.

Source I_TNNeed 5Note For instance, the data values generated with the DPE or extracted with the DEQ may be stored in a database.

UR 269_PPTUsers should be able to create data products using values stored in a database.

Source I_TNNeed 5Note The DPE tool shall use the values stored in the database in order to generate a product. A basic solution is proposed: this will allow to specify that a generated value comes from an SQL statement such as "Select X from Y where …".

InclusionNo Cost High JustificationThere is not an important user need for this functionality and this one will induce too many developments compared to the gains obtained. It is also difficult to create a generic interface to be applied to all database schemas

3.9.5 Format transformation

UR 270_PPTUsers should be able to create a CDF file from any data product described with EAST.

Source I_TNNeed 3Note Users will select the EAST/DEDSL elements to be converted to CDF elements and then define the mapping between them (this mapping could be defined in a file that indicates for each EAST element, the associated element in the CDF file). Then, users will simple have to run the transformation functionality of DEBAT.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxvii

UR 271_PPTUsers should be able to create EAST/DEDSL descriptions and associated data file from any data product described in CDF.

Source I_TNNeed 3Note Users will select the CDF elements to be converted to EAST/DEDSL elements and then define the mapping between them (this mapping could be defined in a file that indicates for each CDF element, the associated element in the EAST/DEDSL files). The users will have to enter all EAST syntactic parameters since CDF does not provide them. Then, users will simple have to run the transformation functionality of DEBAT.

UR 272_PPTUsers should be able to create an HDF file from any data product described with EAST.

Source I_TNNeed 3Note Users will select the elements to be converted and define the mapping between EAST/DEDSL elements and HDF elements (this mapping could be defined in a file that indicates for each EAST element, the associated element in the HDF file). Then, users will select the elements to be converted will have to run the transformation functionality of DEBAT.

UR 273_PPTUsers should be able to create EAST/DEDSL descriptions and associated data file from any data product described in HDF.

Source I_TNNeed 3Note Users will first will select the elements to be converted and define the mapping between HDF elements and EAST/DEDSL elements (this mapping could be defined in a file that indicates for each HDF element, the associated element in the EAST/DEDSL files). The users will have to enter all EAST syntactic parameters since HDF does not provide them. Then, users will select the elements to be converted will simply have to run the transformation functionality of DEBAT.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxviii

UR 274_PPTUsers shall be able to convert the raw data files into XML.

Source I_TNNeed 3Note This conversion process can be fully automated. The user will simply have to precise the data file and associated EAST description file locations.

UR 275_PPTUsers shall be able to convert the DEDSL in PVL format into XML.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxix

3.10 DEBAT Distribution

The distribution phase comes at the end of the data life cycle. The main goal of this part is to disseminate data packages (e.g. data alone, data along with its documentation) to very end-users.

Figure 3-27 DEBAT distribution requirements set

UR 276_DISTThe DEBAT user should be able to package data files together with the data descriptions (EAST and DEDSL files).


UR 277_DISTThe DEBAT user should be able to compress files (i.e. data, EAST and DEDSL) and packages.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxx

UR 278_DISTUsers should be able to connect to DEBAT functionalities remotely.

Source I_TNNeed 3Note DEBAT will provide both Web services and CORBA interfaces.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxi

3.11 TM/TC & SCOS-2000

The EAST technology and the DEBAT tools are intended to come as a companion to the SCOS-2000 Mission Control Centre. EAST and DEBAT are of interest for the TM and TC packets modelling and the DEBAT tools have powerful features that can be used with success within the TM/TC processing chain of SCOS-2000.

The requirements concerning the TM/TC and SCOS-2000 activities are divided in two main fields: The EAST technology, thanks to its interesting features (modelling of binary data,

separation between the model and the data, etc) will be able to model TM and TC packets that are conform to the ESA Packet Utilisation Standard.

The DEBAT tools can be used for two different purposes within SCOS-2000: Improvement of the SCOS-2000 database import process by providing generic

means to automatically generate some import files from the TM/TC packets models.

Simulation for testing/debugging of the TM/TC processing chains.In order to achieve these goals, the DEBAT tools will provide two prototypes that will be validated at factory premises with the means provided by CS (version 2.3e of SCOS-2000 installed on the SUSE 7.3 Linux platform).

Figure 3-28 TM/TC & SCOS-2000 requirements set


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxii

3.11.1 TM/TC modelling

UR 279_TMTCWith the EAST technology, users shall be able to model TM and TC packets which conform to the Packet Utilisation Standard. This standard is described in the document named “Telemetry and Telecommand Packet Utilisation, ECSS-E-70-41”.

Source TMTC_TNNeed 1Note Users will be able to model all the TM and TC packets defined for every sub-services of each services described in the PUS.

3.11.2 SCOS-2000 database import

Figure 3-29 SCOS-2000 database import

UR 280_TMTCDEBAT shall provide a generic prototype that automatically generates some of the database import files for SCOS-2000 (defined by the SCOS-2000 database import ICD).

Source TMTC_TNNeed 2Note Users will use the generic prototype to generate some of the import files needed by SCOS 2000 to create the MIB (i.e. Mission Information Base). The files that can be generated are only those relating to the description of the TM and TC packets.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxiii

UR 281_TMTCThe prototype shall be able to use the information contained in the EAST and DEDSL description files.

Source TMTC_TNNeed 2Note The information contains in the EAST and DEDSL files will be used to generate some of the SCOS-2000 database import files:

o The structural information (such as the position of a parameter within a packet) will be deduced from the EAST descriptions,

o the non-structural information (additional information) will be defined as semantic information in the DEDSL descriptions.

UR 282_TMTCThe prototype shall be able to generate the following files that are related to the monitoring (these files are defined by the SCOS-2000 database import ICD): pid, pic, tpcf, plf, vpd.

Source TMTC_TNNeed 2Note

UR 283_TMTCThe prototype shall be able to generate the following files that are related to the commanding (these files are defined by the SCOS-2000 database import ICD): tcp, pcpc, pcdf, ccf, cpc, cdf.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxiv

3.11.3 Simulation of the SCOS-2000 TM/TC processing chain

UR 284_TMTCDEBAT shall provide a TM simulator prototype. This prototype may be directly built upon the DEBAT DPE, or built upon an ESA TM simulator (in this case, the simulator has to be modified to be able to read EAST descriptions as input), or built upon a CS simulator (PRISM).

Source TMTC_TNNeed 2Note For validation/test purposes, users will simulate the sending of TM thanks to the simulator prototype. The prototype may be based on the generic DEBAT Data Producer & Editor tool.

UR 285_TMTCDEBAT shall provide a TC simulator prototype. This prototype may be directly built upon the DEBAT DPE, or built upon an ESA TM simulator (in this case, the simulator has to be modified to be able to read EAST descriptions as input), or built upon a CS simulator (PRISM).

Source TMTC_TNNeed 2Note For validation/test purposes, users will simulate the sending of TM thanks to the simulator prototype. The prototype may be based on the generic DEBAT Data Producer & Editor tool.

UR 286_TMTCThe TM and TC simulator prototypes should integrate all data encapsulation levels.

Source TMTC_TNNeed 2Note The data encapsulation levels are the following: CCSDS packets, CCSDS frames, NCTRS frames.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxv

UR 287_TMTCUsers should be able to interface the TM simulator prototype with SCOS 2000.


UR 288_TMTCOnce the TM packets are modelled, users should be able to send TM packets to SCOS-2000 via the simulator prototype.

Source TMTC_TNNeed 2Note The TM simulator prototype (if interfaced with SCOS-2000) will be able to send TM packets that conform to the EAST description.

UR 289_TMTCUsers shall be able to interface the TC simulator prototype with SCOS 2000.


UR 290_TMTCOnce the TC packets are modelled, users should be able to receive TC packets from SCOS-2000.

Source TMTC_TNNeed 2Note The TC simulator prototype (if interfaced with SCOS-2000) will be able to receive TC packets.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxvi

UR 291_TMTCUsers should be able to check the validity of the TC packets received from SCOS-2000.

Source TMTC_TNNeed 2Note The TC simulator prototype will be able to check if the TC packets are conform to the EAST description.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxvii

4. Constraint requirementsConstraint requirements place restrictions on how software can be built and operated. For example, definitions of external communications, hardware and software interfaces may already exist, either because the software is a part of a larger system, or because the user requires that certain protocols, standards, computers, operating systems, library or kernel software be used. Constraints that users may wish to place on the software include the quality attributes of adaptability, availability, portability and security. The user shall describe the consequences of losses of availability, or breaches of security, so that developers can fully appreciate the criticality of each function. The user may choose to make additional standards applicable; such requirements are additional constraints on the development. Non-functional requirements, including:

performance requirements (speed of execution and memory requirements),

environment requirements (hardware, OS, peripherals, network, web browser),

external requirements (minimum version numbers of external systems, subsystems, functionality needed from these),

reliability requirements (uptime, mean time to failure, accessibility, loading, average performance, worst case performance, etc),

usability requirements (minimum time to learn system, expected time to learn system, level of user support, expected efficiency gains from system),

safety requirements (critical functionality and its reliability),

legal requirements (conformance to industry standards and recommendations).

Figure 4-30 Constraints requirements set


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxviii

4.1 Performances requirements

UR 292_CONSTRAINTThe graphical interface of all DEBAT tools shall respond quickly to users’ actions (i.e. less than half a second).

Source DEBAT_TEAMNeed 1Note The goal of this requirement is not for the tools to complete a particular task but to show users that their actions has been recognised and is being executed.

UR 293_CONSTRAINTThe DEBAT tools should estimate the remaining time to complete users actions.

Source DEBAT_TEAMNeed 4Note The time to complete will be displayed to users only if it is superior to five seconds.

UR 294_CONSTRAINTThe printing should begin in less than thirty seconds after the command.


UR 295_CONSTRAINTDuring an interactive session, DEBAT shall be able to hold a minimum of ten models and data products simultaneously.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxix

4.2 Environment requirements

UR 296_CONSTRAINTThe DEBAT user shall be able to use the tool on Windows platforms without any changes.


UR 297_CONSTRAINTThe DEBAT user shall be able to use the tool on Linux platforms without any changes.


UR 298_CONSTRAINTThe DEBAT user shall be able to use the tool on Unix platforms without any changes.


4.3 External requirements

UR 299_CONSTRAINTThe DEBAT environment shall be designed to allow the integration of other applications without any software or hardware changes.



User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxx

4.4 Reliability requirements

UR 300_CONSTRAINTThe DEBAT environment shall be modular and shall not depend upon specific technology. It shall be developed with particular care to facilitate the incorporation of new functionalities.


4.5 Usability requirements

UR 301_CONSTRAINTThe DEBAT environment shall be easy to use.

Source DEBAT_TEAMNeed 1Note It will take one or two days for users to get acquainted with the whole DEBAT environment.

UR 302_CONSTRAINTBeginner users should be able to learn the EAST technology with few efforts.

Source DEBAT_TEAMNeed 3Note DEBAT will be designed so that the EAST complexity will be hidden to beginner users. DEBAT may propose an expert mode where error messages will be complete and use the EAST vocabulary. A beginner tutorial may also be created to present the environment to new users and guide them through the use of all the DEBAT functionalities.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxxi

4.6 Safety requirements

UR 303_CONSTRAINTDEBAT shall report to users all failures in the functionalities.


UR 304_CONSTRAINTDEBAT shall prevent from data corruption at all times.


UR 305_CONSTRAINTDEBAT shall preserve the data integrity in the event of system shutdown, power failure and other accidental system failures.


4.6.1 Legal requirements

UR 306_CONSTRAINTDEBAT shall be developed using free technologies and as far as possible open source.Source DEBAT_TEAMNeed 1Note


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxxii

UR 307_CONSTRAINTDEBAT shall be available freely for users under the form of a binary distribution.Source DEBAT_TEAMNeed 1Note With this package, users will install the DEBAT tools suite but will not have access to the source code.


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxxiii

5. List of User RequirementsUR 1_ DEBAT

The DEBAT user shall be able to easily install the DEBAT tools using a graphical installation tool (like InstallShield).......................................................................................15

UR 2_ DEBATThe DEBAT user shall be able to choose between two installation modes: automatic and custom...................................................................................................................................15

UR 3_ DEBATThe DEBAT user shall be able to uninstall DEBAT............................................................16

UR 4_ DEBATThe EAST norm shall have a version number. Each (or group of) modification of the norm shall increase the version number.........................................................................................16

UR 5_ DEBATThe DEBAT tools shall have a single version number. Each (or group of) modification of the DEBAT tools shall increase the version number............................................................16

UR 6_ DEBATThe EAST and DEDSL description files should have a version number.............................16

UR 7_ DEBATThe dates of creation and modification of the EAST and DEDSL description files should be stored.....................................................................................................................................17

UR 8_ DEBATThe EAST and DEDSL description files shall contain the version number of the EAST norm and DEBAT tools with which they were created........................................................17

UR 9_ DEBATThe data model shall contain the version numbers of the EAST norm and DEBAT tools with which it was created......................................................................................................17

UR 10_ DEBATWhen loading EAST and DEDSL description files in DEBAT, a message should be displayed if the description was created with earlier versions of the EAST norm and/or the DEBAT tools.........................................................................................................................17

UR 11_ DEBATWhen loading a data model in DEBAT, a message should be displayed if the data model was created with earlier versions of the norm and/or the DEBAT tools..............................18

UR 12_ DEBATThe DEBAT user shall be able to use DEBAT for the entire data life cycle, from modelling to distribution........................................................................................................................19

UR 13_ DEBATThe DEBAT user shall be able to handle huge volume of data (i.e. up to 6 gigabytes) during their entire data life cycle......................................................................................................19

UR 14_ DEBATAn ascending compatibility shall be kept for the EAST norm and the DEBAT tools.........20

UR 15_ DEBATIf the ascending compatibility is broken (due to major changes in the EAST norm or DEBAT tools), the DEBAT user should be able to transform the old format of the data model, EAST or DEDSL files into the new one so as to keep the ascending compatibility................................................................................................................................................20

UR 16_ DEBAT


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxxiv

The DEBAT user shall be able to know if the EAST and DEDSL description files he is using are compatible with the installed version of the EAST norm.....................................20

UR 17_ DEBATThe DEBAT user shall be able to know if the data model he is using is compatible with the installed versions of the EAST norm and DEBAT tools......................................................21

UR 18_ DEBATIn case the EAST and DEDSL description files are not compatible with the installed versions of the EAST norm and DEBAT tools, a list of the incompatible elements (i.e. their names and paths in the EAST description) should be graphically rendered to users...........21

UR 19_ DEBATIn case the data model is not compatible with the installed versions of the EAST norm and DEBAT tools, a list of the incompatible elements (i.e. their names and paths in the data model) should be graphically rendered to users....................................................................21

UR 20_ DEBATThe compatibility with the XML technology shall be enforced...........................................22

UR 21_ DEBATThe Graphical User Interfaces (menus, labels, buttons, messages, errors) of the DEBAT tools shall be in the English language...................................................................................22

UR 22_ DEBATThe user shall be able to choose the language used by the DEBAT tools............................22

UR 23_ DEBATThe DEBAT tools shall provide users with an online help that documents the available functionalities........................................................................................................................23

UR 24_ DEBATThe DEBAT users shall access the online help from the DEBAT tools GUI......................23

UR 25_ DEBATThe online help shall be available in html format and shall provide a navigable information................................................................................................................................................23

UR 26_ DEBATThe DEBAT tools shall have a user-friendly graphical interface.........................................23

UR 27_ DEBATWithin DEBAT, users shall be able to switch from one tool to another easily....................24

UR 28_ DEBATThe DEBAT user shall be able to use the tools without any knowledge of the underlying technology.............................................................................................................................24

UR 29_ DEBATThe users shall have direct access to the main functionalities of the tools through shortcuts................................................................................................................................................24

UR 30_ DEBATThe DEBAT user shall easily understand the source of the errors/warnings.......................24

UR 31_ DEBATThe DEBAT user should be able to capture some parts of the GUI (such as the data structure description, syntactic and semantic information)..................................................25

UR 32_ DEBATThe DEBAT user should be able to print the captures.........................................................25

UR 33_ DEBATThe DEBAT user should be able to save the captures as images.........................................25

UR 34_ DEBAT


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxxv

The DEBAT user shall be able to generate documentation about a data description (containing syntactic and semantic information) in RTF format..........................................25

UR 35_ DEBATThe DEBAT user shall be able to generate documentation about a data description (containing syntactic and semantic information) in HTML format......................................26

UR 36_ DEBATThe DEBAT user shall be able to generate documentation about a data description (containing syntactic and semantic information) in PDF format..........................................26

UR 37_ DEBATThe DEBAT user should be able to have access to the version of the documentation corresponding to the version of the data description............................................................26

UR 38_ DEBATThe DEBAT user shall be able to modify the generated documentation with an external tools (chosen by the users and not provided by DEBAT).....................................................26

UR 39_ DEBATThe DEBAT user shall be able to print the whole or parts of data files, EAST description files, DEDSL description files..............................................................................................27

UR 40_ DEBATThe DEBAT user shall be able print documentation files....................................................27

UR 41_ INTEGRATEDENVUsers shall be able to access the DEBAT framework functionalities through a user-friendly GUI........................................................................................................................................29

UR 42_ INTEGRATEDENVUsers shall be able to run all the DEBAT tools from the DEBAT framework.....................29

UR 43_ INTEGRATEDENVUsers shall be able to run any other plugged tools from the DEBAT framework................29

UR 44_ INTEGRATEDENVUsers shall be able to modify the configuration of each tool in the DEBAT framework. The following items shall be configurable: tool image icon, tool name, run command..............30

UR 45_ INTEGRATEDENVUsers shall be able to minimize, maximize or close any window (the framework window or any tool window open in the framework). The user shall also be able to modify the size of any window...........................................................................................................................30

UR 46_ INTEGRATEDENVUsers shall be able to plug new tools in the DEBAT framework.........................................30

UR 47_ INTEGRATEDENVUsers shall be able to launch new tools from the DEBAT framework.................................31

UR 48_ INTEGRATEDENVUsers shall be able to upgrade the tools in the DEBAT framework.....................................31

UR 49_ INTEGRATEDENVUsers shall be able to remove tools from the DEBAT framework.......................................31

UR 50_ INTEGRATEDENVWhen plugging a new tool, users shall be able to define, through a convenient GUI, the following configuration information: tool image icon, tool name, run command................31

UR 51_ INTEGRATEDENVThe DEBAT environment shall support the project management concept..........................32

UR 52_ INTEGRATEDENV


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxxvi

Users shall be able to create new projects in the DEBAT environment. The creation process is realised through a GUI of the framework.........................................................................32

UR 53_ INTEGRATEDENVWith no further manipulation, users shall be able to use the data of a project in any DEBAT tool or plugged tool that complies with the data interface specifications of the DEBAT framework.............................................................................................................................32

UR 54_ INTEGRATEDENVThe project should manage the versions of the EAST and DEDSL description files..........32

UR 55_ INTEGRATEDENVUsers should be able to modify the version number graphically..........................................33

UR 56_ WEBRemote users shall be able to read an EAST description using the DEBAT Local Web site through a web browser..........................................................................................................35

UR 57_ WEBRemote users shall be able to display a data product using the DEBAT Local Web site through a web browser..........................................................................................................36

UR 58_ WEBRemote users shall be able to automatically generate a data product using the DEBAT Local Web site......................................................................................................................36

UR 59_ WEBRemote users shall be able to save the generated data files locally to disk..........................36

UR 60_ WEBRemote users shall be able to search for elements using their names...................................36

UR 61_ WEBRemote users shall be able to search for elements using their types....................................37

UR 62_ WEBRemote users shall be able to extract elements from a data products...................................37

UR 63_ WEBRemote users shall be able to extract elements resulting from a previous search................37

UR 64_ WEBRemote users shall be able to save the extracted elements locally to disk...........................37

UR 65_ WEBRemote users shall be able to check that an EAST description is valid against the EAST norm......................................................................................................................................37

UR 66_ WEBRemote users shall be able to check that a data product is conform to a particular EAST description.............................................................................................................................38

UR 67_ WEBIn case of incompatibility, a list of non-conform elements shall be displayed.....................38

UR 68_ WEBRemote users should be able to transform a data product into XML using its associated EAST description..................................................................................................................38

UR 69_ WEBRemote users should be able to save the resulting XML file to disk....................................38

UR 70_ WEBRemote users should be able to visualise data products with a 2D graphical tool through the web browser..........................................................................................................................39

UR 71_ WEB


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxxvii

An HTML online help shall be provided to users.................................................................39UR 72_ WEB

A web service shall propose the functionality to read EAST description files.....................41UR 73_ WEB

A web service shall propose the functionality to read data products (provided an EAST description exists).................................................................................................................41

UR 74_ WEBA web service shall propose the functionality to generate data products (provided an EAST description exists).................................................................................................................41

UR 75_ WEBThe user shall be able to save the generated data files locally to disk..................................42

UR 76_ WEBA web service shall offer the functionality to check an EAST description against the EAST norm......................................................................................................................................42

UR 77_ WEBA web service shall offer the functionality to check an existing data product against the associated EAST description................................................................................................42

UR 78_ WEBIn case of incompatibilities, the users shall be able to get a list resuming all encountered errors.....................................................................................................................................42

UR 79_ WEBA web service should offer the functionality to transform a data product to XML using its associated EAST description................................................................................................43

UR 80_ WEBThe user should be able to save the XML file (converted from the EAST and data files) to disk........................................................................................................................................43

UR 81_ EASTCOREAll the existing EAST core functionalities shall be available in the future version proposed by DEBAT............................................................................................................................44

UR 82_ EASTCOREThe EAST core shall implement all the features of the EAST norm....................................45

UR 83_ EASTCOREThe performances of the EAST core shall be drastically improved.....................................45

UR 84_ EASTCOREUsers shall rely on a robust EAST core................................................................................45

UR 85_ EASTCOREThe EAST core shall store in a file the logbook containing warnings and errors raised during the reading or writing of data products......................................................................46

UR 86_ EASTCOREUsers shall be able to open the logbook from the DEBAT environment (using an integrated text editor).............................................................................................................................46

UR 87_ EASTCOREUsers shall be able to use the EAST API with the ADA, Fortran, C, C++ and Java programming languages........................................................................................................46

UR 88_ EASTCOREAll warning and errors raised in the EAST core shall be accessible through the API..........46

UR 89_ EASTCOREUsers should be able to use the EAST API through CORBA..............................................47


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxxviii

UR 90_ EASTCOREThe EAST core shall propose the functionalities to read and interpret a data description in the EAST format...................................................................................................................47

UR 91_ EASTCOREThe EAST core shall identify elements in an EAST description on the basis of their full paths......................................................................................................................................47

UR 92_ EASTCOREThe EAST core shall be able to check if an EAST description is valid...............................47

UR 93_ EASTCOREThe EAST core shall be able to handle basic calculation functions (i.e. +, -, *, /, odd, even)................................................................................................................................................48

UR 94_ EASTCOREThe EAST core shall be able to handle advanced calculation functions (i.e. cosinus, sinus, tan, log, !, ^²,^ⁿ )....................................................................................................................48

UR 95_ EASTCOREThe EAST core shall be able to handle operators priority and parenthesis..........................48

UR 96_ EASTCOREThe EAST core should be able to handle some algorithmic features (i.e. control structures)................................................................................................................................................48

UR 97_ EASTCOREThe EAST core should be able to handle data discriminated by an integer, an enumeration, a character, a float or a string................................................................................................49

UR 98_ EASTCOREThe EAST core shall be able to handle data discriminated by a computed value................49

UR 99_ EASTCOREThe EAST core should be able to handle look-up tables (associate data values with keys).49

UR 100_ EASTCOREThe EAST core shall be able to handle string constants.......................................................49

UR 101_ EASTCOREUsers shall be able to read data products corresponding to a data description.....................50

UR 102_ EASTCOREUsers shall be able to read huge volume of data...................................................................50

UR 103_ EASTCOREUsers should be able to read data values from the standard input........................................50

UR 104_ EASTCOREUsers should be able to read data values from a socket........................................................51

UR 105_ EASTCOREThe EAST core should be able to handle multi-file data......................................................51

UR 106_ EASTCOREUsers shall be able to produce data products corresponding to a data description...............51

UR 308_ EASTCOREUsers shall be able to automatically generate data products corresponding to a data description (the EAST core will generate random values for all of the elements)...............51

UR 309_ EASTCOREUsers shall be able to generate manually data products corresponding to a data description (users will be able to specify the values to use for the generation process).........................52

UR 107_ EASTCORE


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxxxix

The EAST core shall take default values into account when specified for generating a data product conforming to a data description.............................................................................52

UR 108_ EASTCOREThe EAST core tool shall take integer and real formats into account (this applies to ASCII encoding of integers and reals) when generating a data product..........................................52

UR 109_ EASTCOREUsers shall be able to write generated data values on the standard output...........................52

UR 110_ EASTCOREUsers should be able to write generated data values in a socket...........................................53

UR 111_ EASTCOREUsers should be able to check data programmatically..........................................................53

UR 112_ EASTCOREUsers should be able to check a data product field by field..................................................53

UR 113_ EASTCOREThe data checking API should propose different level of checking for a value (warning, error, fatal error)....................................................................................................................53

UR 114_ EASTCOREThe user should be able to check data values using computed constraints...........................54

UR 115_ EASTCOREThrough the API, the user should be able to check data values using external constraints passed as methods’ arguments..............................................................................................54

UR 116_ EASTCOREThrough the API, the user shall be able to have direct access to the detected errors without the help of external error files...............................................................................................54

UR 117_ MODELLERAll the functionalities existing in the current OASIS tool shall be kept in the DEBAT Data Modeller................................................................................................................................56

UR 118_ MODELLERAll the bugs found in the current version of the OASIS tool shall be fixed (see [RD6]).....57

UR 119_ MODELLERWith the DEBAT Data Modeller, users shall be able to read the data model created with previous versions of the Data Modeller (and notably with OASIS).....................................57

UR 120_ MODELLERWith the DEBAT Modeller, users shall be able to use any new features of the EAST norm which are implemented during the DEBAT project.............................................................57

UR 121_ MODELLERUsers should be able to interface custom applications with the Modeller functionalities....57

UR 122_ MODELLERUsers should be able to use the Modeller functionalities through the command line..........58

UR 123_ MODELLERUsers shall be able to enter all syntactic information graphically........................................58

UR 124_ MODELLERUsers shall be able to specify a format to apply when encoding a number (i.e. integer and real) in an ASCII form..........................................................................................................58

UR 125_ MODELLERThe Data Modeller shall automatically verify that the format entered by users for a particular element is compatible with the size of this element.............................................59

UR 126_ MODELLER


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxl

Users shall be able to specify a default value for the elements.............................................59UR 127_ MODELLER

Users shall be able to easily re-use parts of a model in another one.....................................59UR 128_ MODELLER

Users shall be able to check the syntactic model and get warnings/errors about all missing or incomplete syntactic information.....................................................................................59

UR 129_ MODELLERUsers should be able to handle and follow the modifications of a data model.....................60

UR 130_ MODELLERUsers shall be able to model size-variable elements discriminated by one or more other fields sizes or values.............................................................................................................60

UR 131_ MODELLERUsers should be able to define look-up tables in the models graphically.............................60

UR 132_ MODELLERUsers shall be able to enter all semantic information graphically........................................60

UR 133_ MODELLERUsers shall be able to define semantic attributes of the following types: files or images.. . .61

UR 134_ MODELLERUsers shall be able to save the syntactic and semantic information to disk (without generating the corresponding EAST and DEDSL files), even if the model is incomplete...61

UR 135_ MODELLERThe DEBAT Modeller internal format shall be transformed to XML..................................61

UR 136_ MODELLERThe Modeller user shall be able to load the syntactic and semantic information from the data model (stored on disk)...................................................................................................61

UR 137_ MODELLERThe DEBAT Modeller tool shall support the type library concept.......................................62

UR 138_ MODELLERUsers shall be able to create new types and store them in the library...................................62

UR 139_ MODELLERUsers shall be able to use types stored in the library............................................................62

UR 140_ MODELLERUsers shall be able to modify a type of the library...............................................................62

UR 141_ MODELLERUsers shall be able to import a type into the library.............................................................63

UR 142_ MODELLERThe Modeller tool shall provide users with the possibility to mask parts of the model.......63

UR 143_ MODELLERThe Modeller tool shall provide users with the possibility to visualise the masked parts of the model...............................................................................................................................63

UR 144_ MODELLERThe Modeller tool shall provide users with the possibility to select a particular element in the model view......................................................................................................................63

UR 145_ MODELLERThe DEBAT Modeller tool shall provide users with remove capability to suppress elements from the model......................................................................................................................64

UR 146_ MODELLER


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxli

The DEBAT Modeller tool shall provide users with copy and paste capabilities for the model manipulation...............................................................................................................64

UR 147_ MODELLERThe DEBAT Modeller tool shall provide users with cut and paste capability for the model manipulation..........................................................................................................................64

UR 148_ MODELLERUsers shall be able to copy a text selection (such as a syntactic or semantic parameter value) and to paste it in another text field within the Modeller tool.....................................64

UR 149_ MODELLERUsers should be able to copy a text selection (such as a syntactic or semantic parameter value) in the Modeller and to paste it in another location (out of the Modeller tool)...........65

UR 150_ MODELLERUsers should be able to copy a text selection from another tool (out of the scope of the DEBAT environment) and to paste it into a text field in the Modeller................................65

UR 151_ MODELLERThe DEBAT Modeller tool should provide users with a drag and drop capability for the model manipulation...............................................................................................................65

UR 152_ MODELLERThe DEBAT Modeller tool should provide users with an undo/redo functionality..............65

UR 153_ MODELLERThe DEBAT Modeller tool shall provide search functionalities to locate elements using any syntactic information (i.e. name, type, size, bounds)............................................................66

UR 154_ MODELLERThe DEBAT Modeller user shall be able to use the wildcards ('*' and '?') when searching for an element using its name or type...................................................................................66

UR 155_ MODELLERThe user should be able to locate elements using any combination (using “and” and “or” operators) of the syntactic information (i.e. name, type, sizes, bounds)...............................66

UR 156_ MODELLERThe DEBAT Modeller tool should provide search functionalities to locate elements using semantic attributes.................................................................................................................66

UR 157_ MODELLERThe DEBAT Modeller user should be able to use regular expressions when searching for an element using its name or type..............................................................................................67

UR 158_ MODELLERThe search results shall be rendered to users as a list of corresponding elements................67

UR 159_ MODELLERThe DEBAT Modeller tool should provide a clone functionality for users to copy the model view and open another view with this copy..........................................................................67

UR 160_ MODELLERThe DEBAT Modeller tool should provide a zoom functionality for users to focus on a precise part of the model view..............................................................................................67

UR 161_ MODELLERUsers shall be able to generate the EAST description corresponding to the current model and save this file to disk........................................................................................................68

UR 162_ MODELLERUsers shall be able to generate the DEDSL file corresponding to the semantic information entered by users and save this file to disk.............................................................................68


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxlii

UR 163_ MODELLERUsers shall be able to generate type data declarations in ADA, C/C++ and Java................68

UR 164_ MODELLERUsers shall be able to generate a file containing the EAST paths of the elements (i.e. integer and real) to format along with the associated format............................................................69

UR 165_ DPEUsers shall be able to display an EAST description content graphically..............................71

UR 166_ DPEUsers shall be able to display an EAST description content as a tree structure view...........71

UR 167_ DPEUsers should be able to display an EAST description content as a data byte flow view......71

UR 168_ DPEUsers shall be able to display non complete EAST descriptions graphically.......................71

UR 169_ DPEUsers shall be able to display DEDSL files corresponding to a particular description........72

UR 170_ DPEUsers shall be able to display data files graphically.............................................................73

UR 171_ DPEUsers should be able to handle data cut in several packets...................................................73

UR 172_ DPEUsers should be able to read data from the standard input...................................................74

UR 173_ DPEUsers should be able to read data from a socket...................................................................74

UR 174_ DPEUsers shall be able to easily navigate into a whole data product..........................................74

UR 175_ DPEUsers shall be able to generate automatically a data product corresponding to a particular EAST description..................................................................................................................75

UR 176_ DPEUsers shall be able to precise some elements’ values when generating a data file corresponding to a particular EAST description...................................................................75

UR 177_ DPEUsers shall be able to enter some elements’ values graphically...........................................75

UR 178_ DPEUsers shall be able to enter some elements’ values in a file.................................................76

UR 179_ DPEUsers should be able to enter calculation formulas to define how values are to be generated................................................................................................................................................76

UR 180_ DPEUsers should be able to enter algorithms to set how data values are to be generated...........76

UR 181_ DPEUsers shall be able to generate automatically “wrong” data product corresponding to a particular EAST description..................................................................................................76

UR 182_ DPEUsers shall be able to generate automatically “wrong” data product and enter wrong values................................................................................................................................................77

UR 183_ DPEUsers shall be able to generate values on the standard output..............................................77


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxliii

UR 184_ DPEUsers should be able to write generated data values in a socket...........................................77

UR 185_ DPEThe DPE tool shall check the consistency of data products before displaying them............77

UR 186_ DPEThe DPE tool shall display to users a list of inconsistencies if errors are detected during the checking process...................................................................................................................78

UR 187_ DPEThe DPE tool shall display the data product to users even if inconsistencies are detected during the checking process..................................................................................................78

UR 188_ DPEUsers shall be able to modify elements values using the DPE graphical interface..............78

UR 189_ DPEThe DPE tool shall automatically verify user values against the associated syntactic information in the EAST file................................................................................................78

UR 190_ DPEUsers shall be able to save the data files to disk...................................................................79

UR 191_ DPEThe DPE tool MMI shall not be blocked while executing users actions..............................79

UR 192_ DPEThe DPE tool shall provide users with the possibility to mask parts of the EAST description.............................................................................................................................79

UR 193_ DPEThe DPE tool shall provide users with the possibility to visualise the masked parts of the EAST description..................................................................................................................79

UR 194_ DPEThe DPE tool shall provide users with copy and paste capability for manipulating data values....................................................................................................................................80

UR 195_ DPEThe DPE tool should provide users with an undo/redo functionality...................................80

UR 196_ DPEUsers shall be able to search elements using EAST paths or any syntactic information (i.e. names, types, bounds, sizes) as search criteria.....................................................................80

UR 197_ DPEUsers should be able to search elements using their values as search criteria......................81

UR 198_ DPEUsers shall be able to use the wildcards ('*' and '?') as part of the search criteria................81

UR 199_ DPEUsers should be able to use regular expressions as search criteria.......................................81

UR 200_ DPEUsers shall be able to combine several criteria to refine the search.....................................81

UR 201_ DPEThe search results shall be displayed as a list of elements....................................................82

UR 202_ DPEUsers shall be able to change the data values directly in the search result list.....................82

UR 203_ DPEUsers shall easily understand the source of the errors/warnings..........................................82

UR 204_ DEQ


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxliv

Users shall be able to display an EAST description graphically..........................................84UR 205_ DEQ

Users shall be able to display an EAST description content as a tree structure view...........84UR 206_ DEQ

Users shall be able to display a non complete EAST description graphically......................84UR 207_ DEQ

Users shall be able to display graphically data products corresponding to an EAST description.............................................................................................................................85

UR 208_ DEQUsers should be able to handle data cut in several packets...................................................85

UR 209_ DEQUsers should be able to read data from the standard input...................................................86

UR 210_ DEQUsers should be able to read data from a socket...................................................................86

UR 211_ DEQUsers should be able to easily navigate into a whole data product.......................................86

UR 212_ DEQUsers shall be able to search elements using the DEDSL attributes.....................................87

UR 213_ DEQUsers shall be able to search elements using the elements EAST paths...............................87

UR 214_ DEQUsers shall be able to search elements using the elements EAST types...............................87

UR 215_ DEQUsers shall be able to search elements using the elements values........................................87

UR 216_ DEQUsers shall be able to locate parts of the data of interest to extract the corresponding values using any of the syntactic parameters as search criteria.......................................................88

UR 217_ DEQUsers shall be able to use the wildcards ('*' and '?') in search criteria..................................88

UR 218_ DEQUsers should be able to use regular expressions as search criteria.......................................88

UR 219_ DEQUsers shall be able to combine the search criteria................................................................88

UR 220_ DEQUsers shall be able to locate data values using time as search criteria.................................89

UR 221_ DEQUsers shall be able to locate data values using comparison functions as search criteria......89

UR 222_ DEQUsers shall be able to check for the existence of elements using their paths........................89

UR 223_ DEQUsers shall be able to locate information in one or more data products at the same time....89

UR 224_ DEQThe querying functionalities should be available from the API..........................................90

UR 225_ DEQUsers should be able to use an XML-like query language to process complex queries on the data products.........................................................................................................................90

UR 226_ DEQ


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxlv

The query results shall be displayed as a list of elements along with the associated values................................................................................................................................................90

UR 227_ DEQThe query results display shall be configured by users........................................................90

UR 228_ DEQUsers shall choose the form in which the query results are displayed..................................91

UR 229_ DEQUsers shall be able to select elements to extract graphically................................................91

UR 230_ DEQUsers shall be able to extract elements resulting of a search................................................91

UR 231_ DEQUsers shall be able to extract data values while focusing on a precise branch of any EAST description.............................................................................................................................91

UR 232_ DEQThe extraction functionalities should be available from the API..........................................92

UR 233_ DEQUsers shall be able to use another application to process the data........................................92

UR 234_ DEQUsers shall be able to save extracted elements to disk..........................................................92

UR 235_ DEQUsers shall be able to write extracted data values on standard output..................................92

UR 236_ DEQUsers should be able to write extracted data values in a socket...........................................93

UR 237_ DEQThe DEQ tool MMI shall not be blocked while executing users actions.............................93

UR 238_ DEQThe DEQ tool shall provide users with the possibility to mask parts of the description......93

UR 239_ DEQThe DEQ tool shall provide users with the possibility to visualise the masked parts of the description.............................................................................................................................93

UR 240_ DEQThe DEQ tool should provide users with an undo/redo functionality..................................94

UR 241_ DEQUsers should be able to defer the querying of information in data products at a later time. 94

UR 242_ DEQUsers should be able to defer the extraction of information from data products at a later time........................................................................................................................................94

UR 243_ DEQUsers should be able to defer the querying and extraction of information in XML views of data products at a later time..................................................................................................95

UR 244_ UTUsers shall be able to use the DEBAT utilities from the command line..............................96

UR 245_ UTUsers shall be able to use the DEBAT utilities from a graphical user interface...................96

UR 246_ UTUsers shall be able to produce an ASCII file representing a data file associated with an EAST description..................................................................................................................97

UR 247_ UT


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxlvi

Users shall be able to produce an XML file representing a data file associated with an EAST description..................................................................................................................97

UR 248_ UTUsers shall be able to generate a file containing all the paths defined in an EAST description.............................................................................................................................97

UR 249_ UTUsers shall be able to verify the checksum of an EAST description....................................98

UR 250_ UTUsers shall be able to check data products against EAST descriptions................................98

UR 251_ UTErrors messages shall be located into one single file............................................................98

UR 252_ UTUsers should be able to specify their own checking rules....................................................99

UR 253_ UTUsers should be able to specify different checking levels for a value (warning, error, fatal error)......................................................................................................................................99

UR 254_ UTUsers should be able to specify the checking level when launching the DATA_CHECKER tool........................................................................................................................................99

UR 255_ UTThe user shall be able to specify computed constraints........................................................99

UR 256_ UTThe users should be able to visualise the differences between two descriptions................100

UR 257_ UTThe differences between two descriptions should be stored as a list in a file.....................100

UR 258_ UTThe differences between two descriptions should be displayed graphically......................100

UR 259_ PPTThe DEBAT framework shall provide users with a 2D graphical tool...............................101

UR 260_ PPTThanks to the 2D graphical tool, users shall be able to plot data stored in a data product. 102

UR 261_ PPTThe 2D graphical tool shall be able to export graphics in the following formats: jpeg and png.......................................................................................................................................102

UR 262_ PPTUsers shall be able to print the graphics produced by the 2D graphical tool......................102

UR 263_ PPTUsers shall be able to generate quick looks from the raw data...........................................102

UR 264_ PPTUsers should be able to register EAST and DEDSL descriptions in the CAO (Control Authority Office) system....................................................................................................103

UR 265_ PPTUsers should be able to revise EAST and DEDSL descriptions in the CAO (Control Authority Office) system....................................................................................................103

UR 266_ PPTUsers should be able to extract EAST and DEDSL descriptions from the CAO (Control Authority Office) system....................................................................................................103

UR 267_ PPT


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxlvii

Users should be able to search for EAST and DEDSL descriptions in the CAO (Control Authority Office) system....................................................................................................103

UR 268_ PPTUsers should be able to store data values in a database......................................................104

UR 269_ PPTUsers should be able to create data products using values stored in a database.................104

UR 270_ PPTUsers should be able to create a CDF file from any data product described with EAST.. .104

UR 271_ PPTUsers should be able to create EAST/DEDSL descriptions and associated data file from any data product described in CDF............................................................................................105

UR 272_ PPTUsers should be able to create an HDF file from any data product described with EAST.105

UR 273_ PPTUsers should be able to create EAST/DEDSL descriptions and associated data file from any data product described in HDF...........................................................................................105

UR 274_ PPTUsers shall be able to convert the raw data files into XML................................................106

UR 275_ PPTUsers shall be able to convert the DEDSL in PVL format into XML................................106

UR 276_ DISTThe DEBAT user should be able to package data files together with the data descriptions (EAST and DEDSL files)...................................................................................................107

UR 277_ DISTThe DEBAT user should be able to compress files (i.e. data, EAST and DEDSL) and packages..............................................................................................................................107

UR 278_ DISTUsers should be able to connect to DEBAT functionalities remotely................................108

UR 279_ TMTCWith the EAST technology, users shall be able to model TM and TC packets which conform to the Packet Utilisation Standard. This standard is described in the document named “Telemetry and Telecommand Packet Utilisation, ECSS-E-70-41”.......................110

UR 280_ TMTCDEBAT shall provide a generic prototype that automatically generates some of the database import files for SCOS-2000 (defined by the SCOS-2000 database import ICD)...............110

UR 281_ TMTCThe prototype shall be able to use the information contained in the EAST and DEDSL description files...................................................................................................................111

UR 282_ TMTCThe prototype shall be able to generate the following files that are related to the monitoring (these files are defined by the SCOS-2000 database import ICD): pid, pic, tpcf, plf, vpd.111

UR 283_ TMTCThe prototype shall be able to generate the following files that are related to the commanding (these files are defined by the SCOS-2000 database import ICD): tcp, pcpc, pcdf, ccf, cpc, cdf................................................................................................................111

UR 284_ TMTCDEBAT shall provide a TM simulator prototype. This prototype may be directly built upon the DEBAT DPE, or built upon an ESA TM simulator (in this case, the simulator has to be


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxlviii

modified to be able to read EAST descriptions as input), or built upon a CS simulator (PRISM)..............................................................................................................................112

UR 285_ TMTCDEBAT shall provide a TC simulator prototype. This prototype may be directly built upon the DEBAT DPE, or built upon an ESA TM simulator (in this case, the simulator has to be modified to be able to read EAST descriptions as input), or built upon a CS simulator (PRISM)..............................................................................................................................112

UR 286_ TMTCThe TM and TC simulator prototypes should integrate all data encapsulation levels........112

UR 287_ TMTCUsers should be able to interface the TM simulator prototype with SCOS 2000...............113

UR 288_ TMTCOnce the TM packets are modelled, users should be able to send TM packets to SCOS-2000 via the simulator prototype.................................................................................................113

UR 289_ TMTCUsers shall be able to interface the TC simulator prototype with SCOS 2000...................113

UR 290_ TMTCOnce the TC packets are modelled, users should be able to receive TC packets from SCOS-2000.....................................................................................................................................113

UR 291_ TMTCUsers should be able to check the validity of the TC packets received from SCOS-2000.114

UR 292_ CONSTRAINTThe graphical interface of all DEBAT tools shall respond quickly to users’ actions (i.e. less than half a second)..............................................................................................................116

UR 293_ CONSTRAINTThe DEBAT tools should estimate the remaining time to complete users actions.............116

UR 294_ CONSTRAINTThe printing should begin in less than thirty seconds after the command..........................116

UR 295_ CONSTRAINTDuring an interactive session, DEBAT shall be able to hold a minimum of ten models and data products simultaneously..............................................................................................116

UR 296_ CONSTRAINTThe DEBAT user shall be able to use the tool on Windows platforms without any changes..............................................................................................................................................117

UR 297_ CONSTRAINTThe DEBAT user shall be able to use the tool on Linux platforms without any changes.. 117

UR 298_ CONSTRAINTThe DEBAT user shall be able to use the tool on Unix platforms without any changes....117

UR 299_ CONSTRAINTThe DEBAT environment shall be designed to allow the integration of other applications without any software or hardware changes.........................................................................117

UR 300_ CONSTRAINTThe DEBAT environment shall be modular and shall not depend upon specific technology. It shall be developed with particular care to facilitate the incorporation of new functionalities......................................................................................................................118

UR 301_ CONSTRAINTThe DEBAT environment shall be easy to use...................................................................118

UR 302_ CONSTRAINT


User Requirements Document Reference : SS/DEBAT/URD Issue. : 1.2 Date : 10/03/2003 Page : cxlix

Beginner users should be able to learn the EAST technology with few efforts.................118UR 303_ CONSTRAINT

DEBAT shall report to users all failures in the functionalities...........................................119UR 304_ CONSTRAINT

DEBAT shall prevent from data corruption at all times.....................................................119UR 305_ CONSTRAINT

DEBAT shall preserve the data integrity in the event of system shutdown, power failure and other accidental system failures...................................................................................119

UR 306_ CONSTRAINTDEBAT shall be developed using free technologies and as far as possible open source.. .119

UR 307_ CONSTRAINTDEBAT shall be available freely for users under the form of a binary distribution...........120
