Evolutions de la chaîne numérique et de la programmation des MOCN

Télécharger le fichier pdf d’un mémoire de fin d’études

Evolutions liées aux échanges de données au sein de la chaîne numérique

Evolutions des suites CAO/FAO

Pour pallier le problème d’échange de données entre les différents logiciels de CAO et FAO, les fournisseurs de logiciels proposent des systèmes intégrés CAO/FAO permettant un fonctionnement centralisé autour de fichiers aux formats propriétaires. Pour compléter ce fonctionnement, il existe aussi un modèle collaboratif de conception utilisant un format neutre d’échange (IGES, STEP, …) qui permet de résoudre les problèmes d’incompatibilité entre systèmes concurrentiels [Xu05] [Laguionie10]. Ceci peut être un atout concernant les projets de grande envergure. Le fonctionnement global et la complémentarité des deux systèmes sont illustrés sur la Figure 5.
Ces systèmes intégrés estompent les frontières (et donc l’hétérogénéité) des premiers maillons de la chaîne numérique. A titre d’exemple, Siemens peut maintenant intégrer l’ensemble des maillons de la chaîne de fabrication depuis le rachat de l’éditeur FAO NX CAM en 2007. Malgré les efforts d’homogénéisation des données, à la suite des étapes CAO/FAO, un post-processeur marque une nouvelle coupure afin de transcrire les trajectoires en code G.

Code G : un format non adapté à la description de trajectoires complexes

Le code G est un langage développé initialement par l’Electronic Industries Alliance (EIA) au milieu des années 1960 et a été normalisé depuis 1980 (ISO 6983). Ce langage est basé sur une description de bas niveau des actions à effectuer par la machine. Concernant les trajectoires, une succession de points de passage est définie dans le repère de coordonnées de la machine. Initialement, seules des interpolations linéaires et circulaires sont possibles. En plus des problèmes de rupture déjà évoqués au sein de la chaîne numérique (dû à la nécessité d’un post-processeur), la description des trajectoires élémentaire entraine des problèmes d’approximations lors de la programmation de trajectoires courbes. En effet, dans le cas de surfaces complexes, une discrétisation est déjà opérée entre le modèle CAO et les trajectoires FAO, entrainant alors une facettisation. Ensuite, pour une meilleure précision, la discrétisation doit être fine, et le nombre de segments à exécuter au sein de la CN devient conséquent, pouvant entrainer alors des problèmes de vibrations (Figure 6).
Afin d’éviter ces défauts, certaines CN ont évolué et autorisent la programmation de trajectoires complexes à l’aide de formats de description plus poussés, tels que l’interpolation polynomiale, les splines, ou encore les NURBS (Non-Uniform Rational Basis Splines [Piegl95]). Ces formats sont basés sur des modèles mathématiques permettant d’avoir une courbe de consigne d’accélération continue [Langeron2004] et donc au final d’avoir une surface complexe conforme, avec un meilleur aspect et un temps d’exécution plus court. Les avantages sont nombreux mais ces formats d’exécution ne sont pas encore disponibles sur toutes les CN et une maitrise de compétences est nécessaire [Duc02][Affouard04][Langeron04].
Notons aussi que grâce à l’utilisation de calculateurs plus performants, la plupart des CN récentes proposent des fonctions de compressions regroupant les blocs de programmes d’interpolations linéaires en un bloc d’une trajectoire redéfinie en splines [Siemens04]. Ceci améliore grandement le comportement cinématique de la machine [Pateloup05] car la trajectoire peut être exécutée plus rapidement avec moins d’à-coups et de ralentissements d’axes. Le choix est même proposé de privilégier le temps d’exécution, l’état de surface, ou la fluidité de déplacement des axes.

Le standard STEP-NC pour étendre les possibilités d’échange 

L’étude de la chaîne numérique classique a permis de mettre en avant les principales lacunes du code G [Laguionie10]. Afin de pallier celles-ci et d’étendre les possibilités d’échange des données, le standard STEP-NC reprend les bases du standard STEP pour les adapter à la production sur MOCN [Suh03]. Une des principales avancées de ce langage est de permettre une programmation basée entités : le programme décrit « quoi faire » plutôt que « comment faire » [Kramer06]. Cela permet alors une meilleure prise en compte des possibilités d’un couple process/machine, et peut donner un rôle plus important à la CN. Ceci permet d’avoir un flux bidirectionnel des données au sein de la chaîne numérique et une meilleure capitalisation de l’expérience [Suh02]. L’impact de ce langage sur les échanges de données au sein de la chaîne numérique est synthétisé sur la Figure 7.
Les pertes d’information sont minimisées car le STEP-NC offre un modèle complet de données liées à la production. Nous voyons sur cette figure que le post-processeur est supprimé et entraine maintenant des possibilités de feedback entre la machine et les suites de conception.
Concernant les problématiques d’échange d’informations, le format STEP-NC offre de grandes possibilités d’évolutions. Nous verrons par la suite que ce format modifie aussi l’approche de programmation actuelle dont nous allons maintenant présenter les principales évolutions.

Evolutions de la méthode de programmation : vers une programmation avancée du process de fabrication

L’évolution des maillons de la chaîne numérique et des échanges d’informations est dépendante de l’évolution de la programmation du parcours d’usinage. Les méthodes de programmation avancée tendent à prendre en compte le comportement réel du processus de fabrication, que cela soit avant (méthodes prédictives), pendant (méthodes correctives) ou, dans un cas moins favorable, après (méthodes curatives) la réalisation de la pièce. Nous allons présenter les principales avancées de ces méthodes de programmation et les éventuelles limitations bloquant leurs intégrations au sein des industries manufacturières.

Méthodes de programmation prédictives

Nous avons vu que la programmation de la chaîne numérique classique se base exclusivement sur des contraintes géométriques et cinématiques mais ne prend pas en compte les données du process, la structure de la machine, ainsi que les défauts liés à l’ensemble outil/pièce/montage. Nous savons par exemple que le parcours le plus court n’est pas nécessairement le plus productif, du fait de la structure de la machine et des ralentissements des axes aux discontinuités géométriques [Pateloup2005]. Afin d’obtenir les meilleurs résultats de production, il est nécessaire de compléter les compétences et l’expérience du programmeur à travers l’utilisation de différents outils de prédiction.
Les méthodes prédictives sont basées sur l’utilisation d’un ensemble d’outils de simulation du comportement réel de la MOCN dans le but d’optimiser la trajectoire et les conditions de coupe définies en FAO [Terrier05] [Tapie07]. Une vue de ce modèle de programmation est présentée sur la Figure 8.

Intérêt des méthodes de programmation correctives

Les méthodes de programmation correctives se basent sur le concept de contrôle adaptatif déjà utilisé dans de nombreux domaines dès les années 1960. En effet, celui-ci est d’abord appliqué sur des systèmes à boucle fermée simple (de type échangeur de chaleur, refroidisseur) puis sur des applications plus complexes (autopilotage d’avions et de missiles dès 1977).
Dans le domaine de la fabrication, afin d’expliquer l’intérêt du contrôle adaptatif, et donc des méthodes de programmation correctives, une analogie est faite entre le problème d’optimisation des paramètres du process (trajectoires, paramètres opératoires, …) et l’action d’un opérateur au pied de la machine [Simoes14] :
L’opérateur mobilise ses sens pour observer une opération de fabrication.
A partir de son ressenti, il interprète le bon déroulement de l’opération.
Si besoin, il modifie les paramètres de la machine pour augmenter ses performances.
Les paramètres qui gèrent le procédé de fabrication sont donc fixés au préalable de manière prudente, ou à la suite d’une programmation prédictive, puis optimisés en fonction de l’expérience de l’opérateur, ce qui donne des gains de productivité (déjà de 5 à 10% au début des années 1980 [Koren83]).
L’intérêt du contrôle adaptif est donc de compléter et d’automatiser les actions de l’opérateur expérimenté, et l’analogie donne donc simplement :
Utilisation d’un capteur pour le ressenti (Identification)
Un modèle pour le bon déroulement de l’op

Approche de programmation basée sur STEP-NC

Il est donc encore technologiquement difficile de réaliser un usinage adaptatif à l’aide du standard code G. Il existe donc de nombreuses perspectives de contrôle intelligent en utilisant le langage STEP-NC qui sont illustrées à l’aide d’une plateforme d’implémentation développée au sein de l’IRCCYN et intitulée SPAIM (STEP-NC Platform for Advanced and Intelligent Manufacturing) (Figure 13).
Cette plateforme fait interagir différentes unités (présentées plus en détails dans le chapitre 4 de ce manuscrit) qui communiquent entre elles par l’intermédiaire du langage STEP-NC. Ces interactions permettent de réaliser l’ensemble des évolutions citées précédemment, mais nécessitent une intégration complète du langage STEP-NC au sein de la CN. Ce qui reste encore difficile sur une CN propriétaire.
A travers les différentes premières sections de ce chapitre, nous avons vu que beaucoup d’évolutions sont possibles au sein de la chaîne numérique, mais certaines restent difficilement exploitables dû aux limitations de la CN propriétaire. Nous allons donc faire une synthèse de ces limitations avant de décrire nos différents axes de recherches.

Synthèse des limitations des CNs propriétaires

Nous pouvons synthétiser les limitations de la CN propriétaire suivants différents axes liés aux évolutions de la chaîne numérique.
Tout d’abord, un axe de limitation est lié au format de description des trajectoires propre aux CN qui n’a pas suivi l’évolution des formats de description de pièces complexes. Pour satisfaire des besoins de production de plus en plus exigeants, les fournisseurs de CN ont dû s’adapter et ajouter des fonctionnalités supplémentaires (compression, interpolations splines, …) au standard du code G. Ces fonctionnalités sont encore peu intégrées dans l’industrie et méritent d’être étendues à toutes les CN. De plus, une homogénéisation des données au sein de la chaîne numérique peut être opérée à l’aide du langage STEP-NC, mais celui-ci est difficilement intégrable dans les CN propriétaires actuelles.
Un second axe de limitation est lié aux difficultés de mise en place de méthodes de programmation avancée. La communauté scientifique développe des modèles prédictifs qui souffrent encore de la méconnaissance des algorithmes internes à la CN et du comportement réel de la machine durant la réalisation d’une pièce. De même pour les méthodes correctives dont le potentiel est limité par le manque de possibilité de modification du pilotage temps réel de la MOCN.
En parallèle de ces limitations, il y a aussi des limitations d’ordre économique et pratique, des commandes numériques propriétaires [Xu06]. Tout d’abord, un grand nombre de produits sont incompatibles avec les CN propriétaires (fournisseurs spécifiques et spécifiés). Il existe aussi des difficultés à s’adapter aux fréquences de mises à jour liées aux besoins. Enfin, les services, maintenances et coûts de réparations sont élevés.
Dans le cadre de nos travaux, nous allons répondre à ces limitations à travers différents axes de recherche.

XPAIM au sein du projet européen FoFdation Concept de Smart Machine Controller

XPAIM est une réalisation concrète correspondant aux objectifs du projet européen FP7 FoFdation (Foundation for the Sustainable Factory Of the Future [FoFdation][Rauch14]) réunissant 16 partenaires académiques de 8 pays différents (Figure 15).
Ce projet a pour but de développer un « Contrôleur de Machine Intelligent (SMC, Smart Machine Controller) qui, en lien avec les besoins industriels, inclut les caractéristiques suivantes :
Le système apprend par expérience et ses performances sont améliorées par l’utilisation de bases de connaissances et de simulations
Les conditions de fabrication sont automatiquement sélectionnées pour produire des pièces avec la qualité désirée et le maximum d’efficacité
Les différents modèles définis, ainsi que les capteurs pouvant intégrer la machine, fonctionnent en synergie afin d’améliorer le process et la précision des modèl
Un langage de haut niveau est utilisé pour communiquer les besoins, contrôler le process, décrire les composants physiques et stocker un historique
Une vision d’ensemble du concept de SMC est synthétisée sur la Figure 16 [Rauch14].
Ce concept est mis en œuvre dans le cadre de nos travaux. Les bases et les différents objectifs étant définis, nous allons justifier le choix de la CNO intégrée à la XPAIM. Pour cela, il est nécessaire de définir ce qu’est une CNO et de synthétiser les différents efforts académiques et industriels de développement de systèmes ouverts. Cette synthèse nous permettra d’identifier la CNO adéquate à nos développements sur la XPAIM.
Commande numérique ouverte : définition et projets mondiaux
Du fait des limitations des CN propriétaires, une relative ouverture des CN est devenue un argument commercial pour certains constructeurs (Siemens, Okuma, Fidia et autres CN avec environnement Windows). Par exemple, l’IHM ou encore l’automate programmable peuvent être modifiés, ou encore les coefficients d’un modèle d’asservissement peuvent être optimisés (et ceci, bien souvent dans le cadre de l’installation ou d’une maintenance opérée par le constructeur de la CN). Ce type de CN peut être défini comme « semiouverte » et ne permet pas d’accéder aux parties temps réel du contrôle de déplacement.
Face aux différentes attributions du mot « ouvert » qui peuvent être faites par différents acteurs, il est nécessaire de présenter notre définition de la commande numérique ouverte.

Définition d’une commande numérique ouverte

La définition de la commande numérique ouverte est basée tout d’abord sur celle des systèmes informatiques ouverts. Le comité technique de l’IEEE (Institute of Electrical and Electronics Engineers) à travers la Norme [IEEE95] définit ce qu’est un système ouvert. De cette norme, nous en ressortons notre définition d’un système ouvert. Tout d’abord, un système ouvert permet à des applications correctement mises en œuvre d’être intégrées et de fonctionner sur différentes plateformes de différents fournisseurs. Celles-ci doivent également interagir avec d’autres applications du système ainsi que fournir une interface utilisateur cohérente.
Une des caractéristiques principales des systèmes ouverts est une grande modularité à la fois logicielle et matérielle. Cette modularité peut être illustrée par un projet du domaine de la technologie grand publique, initialement nommé Phoneblocks et devenu le Projet Ara de Google (Figure 17).
Dans ce projet, chaque fonctionnalité d’un smartphone (téléphonie, internet, photographie…) est décomposée dans différents composants modulaires (réseau, écran, appareil photo, processeur, batterie). Ceci permet de personnaliser l’ensemble en fonction du budget de l’utilisateur et du besoin (ex. : en ajoutant une batterie de plus grande capacité pour les grands nomades). Ceci facilite aussi les mises à jour et montées en puissance du système (ex : en changeant de processeur), et bien évidemment a un avantage en terme d’écologie et de durabilité : plutôt que de remplacer tout l’ensemble lorsqu’un élément est défectueux, il suffit de remplacer seulement un module. De plus, un même module peut être modifié plutôt que remplacé pour avoir des fonctionnalités avancées et s’adapter aux besoins de l’utilisateur final.
Par cette illustration, nous comprenons bien l’intérêt des systèmes ouverts, qui peut être appliqué à tout domaine.
Pour revenir à la CN et aux inconvénients des structures propriétaires, la comparaison peut être illustrée de la manière suivante (Figure 18).

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Objectifs visés
Plan de lecture de la thèse
Chapitre 1 – Évolutions de la chaîne numérique de fabrication
1.1. Chaîne numérique de fabrication classique : modèle courant et problématiques associées
1.1.1. Modèle courant de la chaîne numérique
1.1.2. La commande numérique au sein de la chaîne numérique
1.1.3. Problématiques de la chaîne numérique classique
1.2. Evolutions de la chaîne numérique et de la programmation des MOCN
1.2.1. Evolutions liées aux échanges de données au sein de la chaîne numérique
1.2.1.1. Evolutions des suites CAO/FAO
1.2.1.2. Code G : un format non adapté à la description de trajectoires complexes
1.2.1.3. Le standard STEP-NC pour étendre les possibilités d’échange de données
1.2.2. Evolutions de la méthode de programmation : vers une programmation avancée du process de fabrication
1.2.2.1. Méthodes de programmation prédictives
1.2.2.2. Méthodes de programmation correctives
1.2.2.3. Intérêt des méthodes de programmation correctives
1.2.2.4. Nécessité de compensations géométriques
1.2.2.5. Principe de l’usinage adaptatif temps réel
1.2.2.6. Approche de programmation basée sur STEP-NC
1.3. Synthèse des limitations des CNs propriétaires
1.4. Axes de recherche
1.5. Conclusion
Chapitre 2 – Possibilités et intérêts de la CNO
Motivations et objectifs d’une nouvelle CN
2.1.1. Constats et objectifs
2.1.2. XPAIM au sein du projet européen FoFdation – Concept de Smart Machine Controller
Commande numérique ouverte : définition et projets mondiaux
2.2.1. Définition d’une commande numérique ouverte
2.2.2. Etat de l’art de différents projets d’architecture ouverte
LinuxCNC : définitions et intégration au sein de la XPAIM
2.3.1. LinuxCNC
2.3.1.1. Historique et architecture générale de LinuxCNC
2.3.1.2. Les principaux composants de LinuxCNC
2.3.2. Cohabitation de CN et intégration d’une CNO au sein de la XPAIM
2.3.3. Analyse des performances de la XPAIM et fonctionnalités avancées
2.3.3.1. Utilisation « classique » de LinuxCNC
2.3.3.2. Intégration de fonctionnalités avancées
Conclusion
Chapitre 3 – Vers une nouvelle approche de génération de trajectoires en ligne : Compensation temps réel au sein de XPAIM
Actions correctives en temps réel : Frontière d’étude et démarche de mise en œuvre sur XPAIM
3.1.1. Principe de la génération de trajectoires en ligne et frontière d’étude au sein de XPAIM 70
3.1.2. Démarche expérimentale de démonstration d’actions correctives
Développement du montage expérimental de démonstration d’actions correctives
3.2.1. Développement matériel du montage expérimental
a. Quelles contraintes mécaniques doit supporter le montage ?
b. Quelles vitesses voulons-nous atteindre ?
c. Cinématique du montage expérimental
3.2.2. Développement logiciel du montage expérimental
a. Fonctionnement de HAL
b. Configuration HAL au sein de XPAIM
3.2.3. Conclusion de la démarche de mise en place du montage expérimental d’actions correctives
Démonstration d’actions correctives : expérimentations et résultats
3.3.1. Démonstration de compensations en ligne : des résultats bien visibles
3.3.2. Démonstration de compensations en ligne : cas d’un usinage dans des conditions industrielles
3.3.3. Démonstration de compensations en ligne : des améliorations possibles
Conclusion
Chapitre 4 – Adéquation de XPAIM avec l’usine du futur
4.1. Concept XPAIM : Un champ d’application étendu
4.1.1. Les différents niveaux d’information observables en temps réel sur XPAIM et possibilités associées
4.1.2. Illustration de configuration avancée au sein de LinuxCNC
4.2. Usine du futur : Concepts généraux et applications
4.2.1. Usine du futur dans sa globalité
4.2.2. XMIS : Pour une meilleure gestion des données au sein de l’usine du futur
4.2.3. Vers une CN étendue aux nombreuses applications
4.3. Conclusion
Conclusion et perspectives
Synthèse
Perspectives
Références bibliographiques

Télécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *