Interopérabilité des systèmes d’IAO: Les services de prototypage rapide

1. Interopérabilité des systèmes d’IAO:Les services de prototypage rapide Emmanuel Malet 24 Novembre 2003 • LERI de Reims • IFTS Charleville Mézières équipe CMCAO Projet Européen CASIPRO3 Lundi 24 Novembre 2003

2. Plan • Introduction • L’échange de données • La médiation • Interopérabilité des systèmes d’IAO • Les services de prototypage • Implémentation • Conclusion et perspectives Lundi 24 Novembre 2003

3. Introduction • Entreprise étendue et ingénierie collaborative • Collaboration des différents acteurs • Interopérabilité des systèmes d’ingénierie (IAO) • Solutions technologiques normalisées • Echange / partage de données (STEP) ? • L’interfaçage des systèmes (médiateurs) ? Lundi 24 Novembre 2003

4. L’échange de données • Historiquement via fichiers / formats d’échange • Natifs et propriétaires: • Systèmes homogènes (uniformisation, monopole) • Fiables mais très limités • Neutres et ouverts (IGES, SET, VDA, etc.): • Systèmes hétérogènes • N’ont pas suivi l’évolution des représentations • Fiabilité très souvent insatisfaisante •  Projet STEP de normalisation des échanges Lundi 24 Novembre 2003

5. La norme STEPSTandard for Exchange of Product data model • Projet lancé en 1985 • Secteurs automobile, aéronautique • Définir un modèle du produit normalisé • Couvrant tout son cycle de vie • A travers les ≠ métiers • Permettre l’échange et le partage • Normalisé en 1994 par l’ISO (réf. ISO-10303) • Aujourd’hui superficiellement implanté … Lundi 24 Novembre 2003

6. Eléments de la norme STEP • Protocoles d’application • Solution d’échange / domaine • Ex: AP 201 (2D) AP 204 (BRep) • Méthodes de description • Méthodes de modélisation de données • Ressources communes • Bibliothèques de shémas de données réutilisables • Méthodes d’implémentation • Mise en oeuvre de STEP • Méthodologie de test de conformité • Scénarios de test des P.A Lundi 24 Novembre 2003

7. Contrôle SCHEMA geometrie; ENTITY point; x: REAL; y: REAL; z: REAL; END_ENTITY; Entité Entrée Sortie Fonction Attributs Contraintes Mécanisme Appel Méthodologie de développement d’un Protocole d’Application • Modélisation fonctionnelle à l’aide de sadt™, idefØ • Modéliser les fonctions du système (processus de l’entreprise) • Identifier les besoins informatifs • Modélisation conceptuelle à l’aide de idef1x, express_g • Exprimer la structure conceptuelle de l’information • Indépendance / architecture logicielle / matérielle • Expression formelle des données en langage express Lundi 24 Novembre 2003

8. Ressources communes • Capitalisation des schémas / bibliothèques • Génériques: indépendantes du domaine • D’application: dépendantes du domaine • R.A = spécialisation des R.G (Héritage) • Constructions interprétées • Interprétation des ressources communes à ≠ P.A • Modules d’application • Récent projet de modularisation de STEP • Améliorer le développement des P.A Lundi 24 Novembre 2003

9. SDAI BD partagée BD locale BD locale Méthodes d’implémentation • Mise en œuvre de STEP sur un système particulier • L’interface SDAI (Step Data Access Interface) • Le format d’échange STEP Lundi 24 Novembre 2003

10. L’interface SDAI • SDAI est une spécification • Fonctions d’accès/modification des données • Indépendamment / du langage et de la B.D • Accès à n’importe quel attribut/entité par son nom •  Très faiblement typée, sémantique ? •  Ne respecte pas d’encapsulation •  Ne reflète pas le comportement des objets Lundi 24 Novembre 2003

11. Le format d’échange STEP • Syntaxe des fichiers d’échange STEP • Contient des instances d’entités / P.A + contraintes • Interprétable par tout système supportant STEP Iso-10303-21 header Données d’en-tête endsec data #01 = Point_3D(0,0,0); #01 = Point_3D(1,0,0); endsec end-iso-10303-21 Lundi 24 Novembre 2003

12. Synthèse sur STEP • Norme issue de l’industrie • Normalise et capitalise des modèles • Méthodologie relationnelle + héritage • Focalise sur l’aspect représentation • Ne prend pas en compte le comportement • STEP est faiblement implanté Lundi 24 Novembre 2003

13. La médiation • Issue du domaine des réseaux informatiques • Fondée sur les concepts objet • Réutilisation / évolution des systèmes • Intégrer ressources hétérogènes / distribuées • Répartir et connecter les applications • Normes: Microsoft (D)COM et OMG CORBA Lundi 24 Novembre 2003

14. Les concepts objet • Objet • Entité identifiable, possédant un état et un comportement • Architecture objet • Collection d’objets communicant par messages via interfaces • La spécialisation / généralisation • La réutilisation des définitions via le principe d’héritage • L’encapsulation • Abstraction des représentations (données) • Le polymorphisme • Dissocie interface et implémentation d’un objet (service du code) • Encapsulation + polymorphisme • Abstraction complète (données et code) Lundi 24 Novembre 2003

15. process 1 process 2 process 2 process 3 réseau système 1 système 2 Les médiateurs • Assurent une communication transparente • Entre composants hétérogènes et distribués • Au-delà des processus, systèmes et réseaux • Permettent de s’abstraire des communications • Développement se concentre sur l’architecture • En 1991, l’OMG spécifie CORBA • En 1995, Microsoft spécifie (D)COM Lundi 24 Novembre 2003

16. (D)COM et CORBA • (D)COM • Architecture propriétaire de Microsoft • Base des services OLE (doc. composites, copier / coller) • Gestion du cycle de vie et des versions des composants • CORBA • Spécification ouverte d’un bus logiciel (ORB) • Pas de gestion spécifique du cycle de vie / versions • Spécifie l’interopérabilité inter-ORB avec (D)COM et OSF DCE • Synthèse (D)COM / CORBA • Principales normes de médiateur • Rôles similaires, la collaboration d’objets hétérogènes • CORBA spécification ouverte, (D)COM architecture propriétaire Lundi 24 Novembre 2003

17. Synthèse STEP / Médiation • STEP • Normalise les représentations • Ne prend pas en compte le comportement • Norme spécifique à l’ingénierie • Médiation • Abstraction des représentations • Normalise les services (comportement) • Approche généraliste • Synthèse • Niveaux d’abstraction ≠ • Approches complémentaires Lundi 24 Novembre 2003

18. Interopérabilité des systèmes d’IAO • Collaboration de systèmes d’IAO hétérogènes • Groupe de travail de l’OMG (MDTF) • Boeing, Ford, NASA • IBM/DS, Unigraphics, Open Cascade • Normaliser les services d’IAO / interfaces CORBA • « OMG CAD Services » pour la CAO • « PDM Enablers » pour la GDT • « DSS » pour la simulation distribuée • Méthodologie UML retenue • Divergences avec la communauté ISO/STEP • Nécessite une harmonisation EXPRESS / UML Lundi 24 Novembre 2003

19. SGDT Procédé CAO Proto Les services de prototypage rapide • Revoir l’interopérabilité CAO / prototypage • Pas seulement comme un échange de données • Mais comme un échange de services • Spécifier les services des systèmes de prototypage • Afin de les intégrer à l’environnement collaboratif • Intégrer les documents de prototypage au SGDT Lundi 24 Novembre 2003

20. Scénarios d’échange CAO/Prototypage • Distribution des ≠ modules  ≠ scénarios d’échange • Duplication des modèles de données entre les systèmes • Proposition: interfacer les ≠ composants via médiateur Lundi 24 Novembre 2003

21. Interopérabilité des composantsCAO-Prototypage • Dans la continuité des travaux de l’OMG • Interfaçage des composants CAO-Prototypage • Rationaliser l’architecture logicielle Lundi 24 Novembre 2003

22. Composants logiciels de prototypage • Le modèle STL standard • Réutilisation des fichiers STL existants • Le modèle STL topologique • Reconstruction de la topologie • Vérification de la fermeture des objets • Le modèle de tranches • Pilotage procédés de découpe (strato etc.) • Le modèle de remplissage • Pilotage procédés laser (stéréo, frittage etc.) • Le trancheur et le remplisseur • Génération des sections et trajectoires outil Lundi 24 Novembre 2003

23. Implémentation • Algorithmes de tranchage / remplissage • Affinités avec les opérations booléennes • Tranchage = ∩ (sol 3D, plan ) = Tranchage 3D • Remplissage= ∩ (sol 2D, droite) = Tranchage 2D • Ces opérateurs doivent être régularisés • Fiabilité et performance • Régularité des sections et trajectoires • Traitement efficace Lundi 24 Novembre 2003

24. Sommet singulier Arête singulière Classique Régularisé Tranchage classique et régularisé • Le tranchage classique ne garantit pas la régularité • Le tranchage doit donc être régularisé • Gestion des singularités aux sommets et arêtes Lundi 24 Novembre 2003

25. Espace 1D Espace 2D Solide 1D Solide 2D Singularités Notion de singularité • Solide: sous ensemble fini et non nul de l’espace • Singularité: sous ensemble de points de l’espace dont le voisinage a une dimension topologique ≠ Lundi 24 Novembre 2003

26. Ouvert Fermé Irréguliers Régulier Régularisation • Consiste à éliminer les singularités • Régularisation ouverte, intérieur de la clôture ik(S) • Régularisation fermée, clôture de l’intérieur ki(S) Lundi 24 Novembre 2003

27. Intersection des voisinagesN(p,plan) ∩ N(p,S) • Voisinage N(p,plan) : disque • Voisinage N(p Є E,S) : secteur de sphère • Voisinage N(p Є V,S) : portion de sphère =Ø Arête singularière ≠Ø Intersection franche p p plan ∩ =Ø Sommet singulier ≠Ø Intersection franche N(p,plan) N(p,S) Lundi 24 Novembre 2003

28. Originalité de notre approche • Spécificité du voisinage N(p,plan) (forme planaire) • Détecter les singularités N(p,plan) ∩ N(p,S) = Ø • Description qualitative de N(p Є E,S) et N(p Є V,S) • Par classification des faces incidentes • Arithmétisation de la méthode • Généralité pour les cas ouvert et fermé Lundi 24 Novembre 2003

29. Algorithme proposé • Classification V, E, F / au plan de tranchage P • C(V,P) = { On, Top, Bottom } • C(E,P) = { On, Top, Bottom, Cut } • C(F,P) = { On, Top, Bottom, Cut } • Création des sommets de la tranche • Issus de sommets dans le plan (V on P) (rejet des singularités) • Issus d’arètes coupant le plan (E cut P) • Création des arètes de la tranche • Issues d’arêtes dans le plan (E on P) (rejet des singularités) Issues de faces (F cut P) • Construction de la tranche • Méthode ascendante • Evite les redondances et le post-traitement de fusion Lundi 24 Novembre 2003

30. Maquette logicielle « e-prototyping » • Applet Java • Utilisation distante Intra / Inter net • Portabilité du code et possibilité d’utiliser CORBA • Acquisition de la géométrie • Actuellement par échange de données via STL • Devrait utiliser les services CAO (disponibilité ?) • Préparation des données • Tranchage, trajectoires outil • Pilotage du procédé • Imprimante de bureau • Services connexes • Placement et simulation de la rugosité du prototype • Estimation du temps et du coût de construction Lundi 24 Novembre 2003

31. Illustration Lundi 24 Novembre 2003

32. Conclusion • Cette thèse montre: • L’importance des normes dans la collaboration logicielle • Les ≠ fondamentales entre STEP / médiation • La lenteur du processus de normalisation • Les évolutions méthodologiques et technologiques • Cette thèse propose: • La normalisation des services de prototypage • Une implémentation originale de ces services • Questions en suspens: • STEP sera-il encapsulé derrière des services STEP ? • Les services CAO seront-ils implémentés par des modèles STEP ? • De nouvelles évolutions bouleverseront-ils ces normes ? • La collaboration intéresse elle les éditeurs de logiciels ? Lundi 24 Novembre 2003

33. Perspectives • Encapsulation des modèles STEP • Spécification de leurs interfaces • Vision fonctionnelle de la CFAO • Conception / Fabrication procédurale • Langages procéduraux de CFAO • Capitalisation des connaissances • Bibliothèques de procédures de Conception / Fabrication • Réutilisables et grandement portables • Automatisation • Patrons de Conception / Fabrication • Gammes automatiques • Relations logiques entre processus Conception / Fabrication ? • Traduction systématique de l’un en l’autre possible ? • La solution n’est elle pas la convergence des deux processus ? Lundi 24 Novembre 2003

34. FIN Lundi 24 Novembre 2003