Echange%20de%20donn

1
Echange de données techniquesAlain.Fagot_at_dorea.f
r
2
Organisation de la présentation

• Problème posé
• Solution proposée
• Loffre
• Les compétences
• Exemples dapplications

3
Problème posé

• Problème
• Grande diversité des codes de calcul et
  différences technologiques importantes,
• Modèle de données similaires mais malheureusement
  incompatibles,
• Dispersion géographique de ces codes,
• Besoin
• Réalisation dinterfaces intelligentes, cependant
  le nombre de ces interfaces saccroît de façon
  exponentielle, fonction des différents logiciels
  de calcul.

4
Solution proposée

• Solution
• Utiliser des formats neutres, basés sur les
  standards norme ISO internationale (STEP), XML,
  HDF.
• Valeur ajoutée
• La diminution du nombre dinterfaces à
  développer,
• Réduction des coûts de développement et surtout
  de maintenance, car utilisation de batteries
  doutils logiciels déjà validés industriellement
  

5
LOffre (1)

• Analyse des problèmes déchanges et propositions
  de solutions
• Développement de systèmes EDT complets
• protocoles, formats neutres,
• accompagnement au niveau des organismes de
  normalisation (AFNOR, ISO, W3C, OMG),
• API (C, C, Java, Fortran - UNIX et PC),
• interfaces,
• Bases de Données déchange,
• outils (éditeurs 3D) et méthodes de validation.

6
LOffre (2)

• Formations personnalisées aux techniques EDT
  (XML, STEP, HDF)
• Etude de ladéquation des produits existants au
  projet
• STEPTools, EPM Technology, PTC, Open Cascade,TGS,
  ...

7
Compétences transverses
Compétences théoriques
Compétences opérationnelles

• Mise en Œuvre XML/STEP/HDF
• AGL EDT
• Interfaces
• Intégration Base de Données

• Analyse du Problème d échange
• Architecture de Système EDT/GDT
• Modélisation XML, UML, STEP, HDF

Echange de Données techniques

• Développements C,Fortran,C,Java, Python
• IHM, Viewer 2D/3D
• Système Unix/NT

• Méthodologie de développements multi-plateformes
• Technos Objet
• Qualité, Gestion Conf., ...

Génie logiciel
8
Exemples dapplications

• Quelques exemples dapplications
• STEP-TAS thermique spatiale,
• CLIM-2000 lénergie,
• ARCAD les réseaux routiers,
• Interface GDT lélectronique embarquée,
• SNOOP lautomobile

9
STEP-TAS (1ère generation dAPI)

• Le besoin
• Pour ESA-CNES et partenaires, développement d'un
  système déchange de données entre simulateurs
  thermique spatiale.
• Le problème
• Grande diversité des codes thermiques et
  différences technologiques importantes (F77,VAX à
  C,NT).
• Dispersion géographique des logiciels et
  problèmes d'internationalisation.
• L'objectif
• Besoin de coopération entre les partenaires
  industriels.
• Développement d'interfaces entre les logiciels
  plus fiables et moins onéreuses.

10
STEP-TAS (1ère generation dAPI)

• La solution
• Définition d'un format neutre basé sur une norme
  ISO internationale (STEP).
• Développement de bibliothèques associées (C,
  Fortran) pour rendre plus fiable les échanges
  (automatisation).
• Développement de  Viewer  pour visualiser les
  données techniques échangées.
• Définition d'une méthodologie de validation.
• Double compétence échanges de données techniques
  informatique technique.

11
STEP-TAS (1ère generation dAPI)
ESARAD
ESARAD
ESARAD
TRASYS
TRASYS
TRASYS
Prototype available, Bi-directional Planned 2000
Prototype available, Bi-directional Planned 2000
Prototype available, Bi-directional Planned 2000
TSS
TSS
TSS
THERMICA
THERMICA
THERMICA
STEP-TAS
Thermal Desktop (Radcad)
Thermal Desktop (Radcad)
Thermal Desktop (Radcad)
US Pilot 2000
US Pilot 2000
US Pilot 2000
CORATHERM
TAS (Harvard Thermal)
TAS (Harvard Thermal)
TAS (Harvard Thermal)
US Pilot 2000
US Pilot 2000
US Pilot 2000
Baghera View
SINDA/ATM
SINDA/ATM
SINDA/ATM
Nevada
Nevada
Nevada
US Pilot 2000
US Pilot 2000
US Pilot 2000
Available
US Pilot 2000
US Pilot 2000
US Pilot 2000
12
STEP-TAS (1ère generation dAPI)

• Les bénéfices
• Amélioration de la qualité des échanges entre
  codes thermiques et des processus de validation.
• Reconnaissance et adhésion de la NASA aux projets
  européens.
• Réduction importante des coûts de développement
  et d exploitation des interfaces entre les
  différents logiciels.
• Création d'une norme mondiale concernant les
  données thermique spatiale.

13
CLIM 2000

• Le besoin
• Pour EDF, direction de la recherche. Outil de
  simulation de dépense dénergie.
• Le problème
• Multitude doutils de technologies différentes
  (Fortran, C , C, Shell) et d interfaces
  hétérogènes.
• Partage de données communes élémentaires.
• Objectif - Besoins du client
• Homogénéisation des échanges entre les codes de
  calcul de placement des sources de chaleur
  (optimisation dapport calorifique dans une
  pièce).

14
CLIM 2000

• Objectif - Besoins du client
• Définition d un format neutre et développement
  de librairies pour manipuler les données.
• La solution
• Double expertise dans léchange de données
  techniques et des technologies informatiques de
  pointe.
• Réalisation dAPI C, C, Fortran, Shell et d un
  moteur de chargement des données.
• Les bénéfices
• Permettre l amélioration de la qualité des
  échanges entre les codes de calcul thermique.

15
ARCAD

• Le besoin
• Pour le SETRA, direction informatique,
  développement des normes de CAO routières,
  logiciel ARCAD.
• Le problème
• Définir un réseau routier données
  géographiques, documentation technique, ouvrage
  d'art...
• L Objectif
• Associer au logiciel la CAO routière nouvelle
  génération (CASCADE), et des données échangées
  avec les autres outils du domaines.

16
ARCAD

• La solution
• Définir le format neutre STEP, modélisation
  EXPRESS, pour fournir un moyen d'archivage a long
  terme.
• Les bénéfices
• Utilisé par les partenaires industriels, il
  permettra d'avoir des interfaces indépendantes
  des logiciels de CAO routière.

17
Interface GDT

• Le besoin
• Pour Thomsom Marconi Space, direction
  informatique, gestion de configuration,
  assemblage et processus de conception des
  systèmes électriques embarqués.
• Le problème
• Connecter sa nouvelle GDT (Metaphase) à
  l'ensemble des produits CAO, GPAO, achat et
  logistique en GED.
• Multiplicité des interfaces.
• Développement des interfaces en même temps que le
  SGDT.

18
Interface GDT

• Objectif - Besoins du client
• Rendre plus pérenne les interfaces CAO, GPAO en
  augmentant leurs évolutivités.
• Renforcer la communication avec les partenaires
  anglais (TMS limited/Sherpa).
• La solution
• Mettre en place une méthodologie adaptée grâce à
  une double compétence SGDT - EDT.
• Développement d'un protocole STEP spécifique à
  TMS, des interfaces logicielles avec les outils
  périphériques via STEP.

19
Interface GDT

• Les bénéfices
• Meilleure évolutivité et meilleure flexibilité
  des interfaces CAO, GPAO.
• Indépendance des interfaces par rapport au SGDT.
• Disponibilité d'un format neutre normalisé,
  simplifiant les échanges avec les partenaires de
  TMS.
• Synthèse des données techniques dans un seul
  format.

20
SNOOP

• Le besoin
• Pour IMRA, centre de recherche, optimisation de
  logiciel embarqué pour son client TOYOTA.
• Le problème
• Code C généré pour les puces programmables
  embarquées (ABS, etc.) non optimisé.
• Temps réel, contraintes de temps de réponse.
• L'objectif
• Optimisation du code C généré par les outils
  informatiques de simulation.
• Rendre le code plus performant en conservant la
  compatibilité avec le langage Naive-C.

21
SNOOP

• La solution
• Spécification d un modèle objet (méta langage)
  du langage Naive-C.
• Développement d un outil de lecture et
  réécriture C en fonction des contraintes du
  langage (minimisation des tests, boucles, etc.).
• Utilisation des bibliothèques Rogue Wave, Design
  Pattern C.
• Les bénéfices
• Approche qualité sur le projet très
  satisfaisante.
• Transfert de compétences nettement facilité.