ETTC'2003 - SEE
ETTC'2003 - SEE ETTC'2003 - SEE
etrieve parameters and storing results. Main advantage of this way is that user has only to focus on algorithms and hence leave to JUZZLE the management of parameters/results interface and graphics user interface. • Definition and tuning of a simulator connecting elementary modules to each other: - Development of each module in JAVA or C, - Definition of the structure (choice and connection of the modules), - Definition of module parameters, global parameters and results to save, - Simulator tuning and debugging a using specific Graphical User Interface. The interface permits to probe, process and display graphically data exchanged between modules, - Optional creation of a separated executable corresponding to the simulator. • Encapsulation of simulators developed using C or FORTRAN by means of a file interface for parameter specification. In the context of this article, a simulator was developed using C based modules, each module performing an elementary function and exchanging numerical data with other modules. Graphic User Interface of JUZZLE for a C based module simulation is as follows Figure 2 : Graphic User Interface of JUZZLE for a C based module simulation EXPLOITATION TOOLS Beside simulation tools allowing to compute results from parameters, JUZZLE provides also exploitation tools to build case studies and statistic studies. A study on a JUZZLE simulator uses two kinds of parameter variations: • Case Study defines precisely parameters variations with simulations runs explicitly defined. • Statistic Study is feeding simulator parameters with random laws (uniform, Gaussian…). Furthermore, users have the possibility to execute studies using one or several computers. Thus, hardware resource can be optimised, JUZZLE being responsible for distribution and gathering of computation units. Graphic User Interface of JUZZLE for a study case is as follows 3
Figure 3 : Graphic User Interface of JUZZLE for a study case PHYSICAL LAYER SIMULATION WITH JUZZLE MODULE APPROACH In order to ensure independence between modules, a strategy has been established for data communications: Each module intends to operate a specific function of the transmission chain. The modules are then called successively and iteratively. To implement a module, the user has to declare in a specific window: - Includes, defines, external libraries needed for algorithm codes - Global variables that are kept during all the simulation - Data intended to be exchanged via input and output ports - Parameters and results associated to the module Graphic User Interface of JUZZLE for module declaration is as follows Figure 4 : User interface for module declaration Afterward, the algorithms are written using three different functions: - Preparation : This function is called at simulation start in order to initialise each module. For instance, for a filter, some coefficients are computed before any processing and kept between successive calls. - Process : This function is called as many times as necessary. The skeleton for this function is always the same : first, analysis of data amount available at input (if any) and free space at output, second, decision if computation can be performed and third, production of new data to output ports. - Termination : This last function is called when simulation is finished to allow each module to build synthesis results or to clean resource (memory de-allocation for instance). BUFFER MANAGEMENT For being able to perform computation, module needs data from input buffer(s) and 4
- Page 1 and 2: SÉANCE D'OUVERTURE / OPENING SESSI
- Page 3 and 4: A l’aube de ce siècle, Airbus s
- Page 5 and 6: Etape 4 : L’avion réel une fois
- Page 7 and 8: C’est, sur l’exemple des essais
- Page 9 and 10: parfois même sous la forme de plat
- Page 11 and 12: oth the system and the manufacturin
- Page 13 and 14: Such an interdependence between tes
- Page 15 and 16: eference books, but it is as fundam
- Page 17 and 18: BACK MANAGEMENT DES ESSAIS SYSTEME
- Page 19 and 20: BACK ESSAIS D’ENSEMBLE LANCEURS C
- Page 21 and 22: Elle ne doit cependant pas être me
- Page 23 and 24: - le plan de mesures est conséquen
- Page 25 and 26: 4.2 MAQUETTE DYNAMIQUE ARIANE 5 Dan
- Page 27 and 28: Les points délicats liés à l’o
- Page 29 and 30: Processus Commande Architecture Int
- Page 31 and 32: BACK 1 Introduction AIRBUS AIRCRAFT
- Page 33 and 34: So, different test tools shall be d
- Page 35 and 36: 3.4 Architecture of A380 Simulators
- Page 37 and 38: 3.6 A380: Models In order to suppor
- Page 39: GENERAL PRESENTATION OF JUZZLE GENE
- Page 43 and 44: IMPLEMENTATION AND SIMULATION OF A
- Page 45 and 46: REFERENCES [1] Space engineering, R
- Page 47 and 48: Client Compliance Matrix (par rappo
- Page 49 and 50: SESSION 2 : TECHNIQUES ET MOYENS D'
- Page 51 and 52: POSTE INE A380 Les besoins fonction
- Page 53 and 54: Les principes de l’architecture :
- Page 55 and 56: Les éléments de l’architecture
- Page 57 and 58: BACK Trajectographie temps réel DG
- Page 59 and 60: Deux précisions temps réel sont p
- Page 61 and 62: 4.00 3.00 2.00 1.00 0.00 -1.00 -2.0
- Page 63 and 64: CONCLUSION La phase d'essais en vol
- Page 65 and 66: RÉSUMÉ: Osiris est une gamme de m
- Page 67 and 68: 1. INTRODUCTION Dassault Aviation e
- Page 69 and 70: Exemple de modules banc d'intégrat
- Page 71 and 72: éduction de durée des essais par
- Page 73 and 74: 5. EXEMPLE L'OSIRIS MULTIFONCTION U
- Page 75 and 76: 6. LA MODULARITÉ DE LA GAMME OSIRI
- Page 77 and 78: • JBUILDER • ORACLE Cette modul
- Page 79 and 80: • VX Wxorks reste l'OS de la part
- Page 81 and 82: 6.5 Exemple d'interconnexion avec d
- Page 83 and 84: PRINCIPE 7.3 Exemple de réalisatio
- Page 85 and 86: 8. LA NOUVELLE GAMME SUR PC: VÉNUS
- Page 87 and 88: • Un IHM de sélection des param
- Page 89 and 90: 9. CONCLUSION OSIRIS a maintenant g
etrieve parameters and storing results.<br />
Main advantage of this way is that user has<br />
only to focus on algorithms and hence<br />
leave to JUZZLE the management of<br />
parameters/results interface and graphics<br />
user interface.<br />
• Definition and tuning of a simulator<br />
connecting elementary modules to each<br />
other:<br />
- Development of each module in JAVA<br />
or C,<br />
- Definition of the structure (choice and<br />
connection of the modules),<br />
- Definition of module parameters, global<br />
parameters and results to save,<br />
- Simulator tuning and debugging a using<br />
specific Graphical User Interface. The<br />
interface permits to probe, process and<br />
display graphically data exchanged<br />
between modules,<br />
- Optional creation of a separated<br />
executable corresponding to the simulator.<br />
• Encapsulation of simulators developed<br />
using C or FORTRAN by means of a file<br />
interface for parameter specification.<br />
In the context of this article, a simulator was<br />
developed using C based modules, each<br />
module performing an elementary function<br />
and exchanging numerical data with other<br />
modules.<br />
Graphic User Interface of JUZZLE for a C<br />
based module simulation is as follows<br />
Figure 2 : Graphic User Interface of JUZZLE for a<br />
C based module simulation<br />
EXPLOITATION TOOLS<br />
Beside simulation tools allowing to compute<br />
results from parameters, JUZZLE provides<br />
also exploitation tools to build case studies<br />
and statistic studies.<br />
A study on a JUZZLE simulator uses two<br />
kinds of parameter variations:<br />
• Case Study defines precisely parameters<br />
variations with simulations runs explicitly<br />
defined.<br />
• Statistic Study is feeding simulator<br />
parameters with random laws (uniform,<br />
Gaussian…).<br />
Furthermore, users have the possibility to<br />
execute studies using one or several<br />
computers. Thus, hardware resource can be<br />
optimised, JUZZLE being responsible for<br />
distribution and gathering of computation<br />
units.<br />
Graphic User Interface of JUZZLE for a<br />
study case is as follows<br />
3