Le défi
par George Thiers, Timothy Sprock et Leon McGinnis (Georgia Institute of Technology), Adam Graunke (Boeing Research and Technology) et Michael Christian (The Boeing Company)
Présenté lors de la conférence d'hiver 2016 sur la simulation
Un projet de recherche pluriannuel axé sur la transition de la conception à la production d'une entreprise aérospatiale mondiale, et en particulier sur la manière de répondre aux questions liées à la production beaucoup plus tôt dans le cycle de conception d'un programme qu'il n'est possible de le faire aujourd'hui. Une difficulté fondamentale réside dans le fait que le temps et l'expertise nécessaires à la formulation de modèles d'analyse appropriés empêchent leur utilisation courante, en particulier dans le cadre du développement de nouveaux programmes. L'objectif du projet était de réduire ces exigences et, à la fin de 2014, une méthodologie a été développée pour la génération d'analyses à la demande afin de répondre aux questions courantes sur les systèmes de production. Un projet pilote a été mené en 2015 pour démontrer l'efficacité de la méthodologie, à savoir qu'elle pouvait effectivement réduire d'au moins un ordre de grandeur le temps nécessaire pour répondre à une question fréquemment posée, d'une manière reproductible, alors que les spécifications des produits, leurs plans de traitement, les installations prévues et les ressources disponibles changeaient fréquemment. Ce document résume la méthodologie, la mise en œuvre du projet pilote et les résultats préliminaires.
Introduction
Une entreprise aérospatiale internationale cherche à améliorer la conception de ses systèmes de production en abordant des questions clés plus tôt dans le cycle de vie du produit. Les outils de conception et d'ingénierie assistées par ordinateur (CAO) aident les concepteurs de produits en leur permettant d'évaluer, à l'aide d'un simple bouton, les paramètres mécaniques, aérospatiaux, thermiques et autres de la conception des produits candidats. Cependant, les outils informatiques qui aident les concepteurs de systèmes de production avec des capacités d'analyse à la demande sont plus limités. La vision de l'entreprise est donc d'améliorer les outils d'aide à la conception, au diagnostic et à l'amélioration continue des systèmes de production, en commençant par donner aux concepteurs la possibilité d'évaluer, à l'aide d'un bouton-poussoir, les mesures et les questions de "productibilité", notamment :
- Si la conception d'un avion devait inclure de nouveaux matériaux, existe-t-il une capacité à fabriquer les pièces nécessaires, à un certain rythme et à un certain coût ?
- Si un sous-ensemble important est divisé en sections distinctes fabriquées par différents fournisseurs et assemblées lors de l'assemblage final, comment le calendrier de livraison doit-il concilier une grande résistance aux ruptures d'approvisionnement et de faibles coûts de stockage ?
- Quel investissement en outils, montages, moules de stratification et autres ressources est nécessaire pour fabriquer un certain sous-ensemble à une certaine cadence de production ?
Quelle que soit la liste des questions, l'objet de la recherche est de savoir comment y répondre par un bouton-poussoir, et plusieurs facteurs rendent la tâche difficile. Tout d'abord, la capacité à répondre par un bouton-poussoir nécessite la formulation et la résolution d'une variété de modèles d'analyse de recherche opérationnelle, y compris des modèles statistiques, de simulation d'événements discrets et d'analyse d'optimisation.Les méthodes et algorithmes de résolution sont bien étudiés dans la littérature, mais la manière de formuler un modèle d'analyse à partir d'une description de système neutre du point de vue de l'analyse et d'une question sur le système de manière automatisée, robuste et réutilisable n'a pas été bien étudiée. Deuxièmement, au cours des premières étapes de la conception, les spécifications d'un produit peuvent n'exister qu'à un niveau d'abstraction élevé, ce qui signifie que la fonctionnalité du bouton-poussoir doit prendre en compte des quantités variables de détails. Troisièmement, si les informations sur les produits et les processus peuvent être rigoureusement saisies dans les systèmes de gestion du cycle de vie des produits (PLM), ce n'est souvent pas le cas des informations sur les ressources et les installations - dans de nombreuses entreprises, les connaissances en matière de production sont souvent informelles, tacites et transitoires. Si l'architecture d'une entreprise comprend la CAO, la gestion des données sur les produits (PDM), les systèmes d'exécution de la fabrication (MES) et la planification des ressources de fabrication (MRP), la combinaison de ces systèmes ne contient toujours pas les informations nécessaires pour répondre à de nombreuses questions relatives à la productibilité, notamment celles énumérées ci-dessus. Par conséquent, lorsqu'un concepteur appuie sur le bouton, il doit également s'attendre à fournir des informations supplémentaires, ce qui soulève la question de la nature exacte de ces informations, de la langue et du format qu'elles doivent prendre, et de la flexibilité qui existe pour les détailler.
L'analogie avec la vision de l'entreprise consiste à ajouter aux assistants personnels tels que Siri d'Apple, Voice Search de Google ou Cortana de Microsoft les fonctionnalités supplémentaires nécessaires pour répondre aux questions de productibilité concernant les conceptions des candidats. Pour comprendre en quoi les fonctionnalités nécessaires diffèrent de celles qui existent déjà, il faut savoir que de nombreuses questions posées aux assistants personnels peuvent être résolues par une simple recherche dans une base de données ou sur le web. Il existe également des exemples isolés de mécanismes plus avancés, l'un d'entre eux étant le calcul d'itinéraires de conduite. Les questions relatives à la navigation dans les réseaux de transport civilsnetrouvent généralementpasde réponse dans la recherche d'itinéraires préenregistrés dans des bases de données, mais plutôt dans la formulation d'une analyse d'optimisation du flux du réseau du chemin le plus court, sa résolution (peut-être en utilisant l'algorithme de Dijkstra avec des heuristiques), et ce en quelques secondes et de manière invisible pour l'utilisateur final. Avec cette analogie, les facteurs énumérés ci-dessus peuvent être résumés en deux défis : (1) une généralisation et une expansion nécessaires des capacités des assistants personnels en matière de formulation et de résolution d'analyses, et (2) la modélisation. Il est possible de répondre à des questions sur les itinéraires à suivre parce que les assistants personnels ont déjà une connaissance détaillée des réseaux de transport civils. Ils n'ont cependant aucune connaissance des produits, processus, ressources et installations propriétaires d'une entreprise arbitraire - et même s'ils avaient accès aux systèmes d'information de l'entreprise, ceux-ci ne sont pas complets et ne peuvent généralement pas jouer le rôle requis d'un environnement de conception expérimentale.
Fin 2014, une méthodologie a été mise au point pour relever ces défis, et en particulier celui de la modélisation. La méthodologie permet de répondre en un clin d'œil aux questions de productibilité via la formulation automatique de nombreux types de modèles d'analyse différents, mais le projet pilote s'est concentré exclusivement sur la formulation de modèles de simulation à événements discrets, conformément à l'observation de Nelson selon laquelle "la simulation est de plus en plus laseuleméthode capable d'analyser, de concevoir, d'évaluer ou de contrôler les systèmes complexes, incertains et à grande échelle auxquels nous nous intéressons" (Taylor et al. 2013). Une exigence imposée par l'entreprise est d'utiliser des outils commerciaux prêts à l'emploi (COTS) pour les modèles de simulation formulés automatiquement, notamment Simio et Tecnomatix Plant Simulation.
La solution
1.1 Travaux antérieurs : Génération de modèles et modélisation
De nombreux analystes en ingénierie ont essayé d'automatiser leur flux de travail, en suivant le paradigme qui consiste à séparer la description du système de l'analyse du système, à rédiger des descriptions du système d'une manière supposée plus facile, puis à les transformer automatiquement dans la sémantique et la syntaxe d'un langage d'analyse particulier en fonction des besoins. Yuan et al. (1993) décrit un générateur de modèles de simulation en langage SIMAN de "systèmes opérationnels discrets" qui sont modélisés par un "réseau d'opérations" et des "équations d'opérations". Son et Wysk (2001) décrivent la construction automatique de modèles de simulation dans le langage Arena pour répondre aux questions de contrôle des ateliers de fabrication, en utilisant une abstraction de réseau appelée "graphe d'état de pièce basé sur les messages" pour capturer les routages potentiels à travers les ressources d'un atelier. Fournier (2011) décrit la construction automatique de modèles de simulation dans différents langages (QUEST, Arena, ProModel, FlexSim) à l'aide de la norme CMSD (Core Manufacturing Simulation Data), et Bergmann et al. (2012) associe CMSD au langage de simulation SLX. Dong et Chen (2001) génèrent des réseaux de Petri orientés objet à partir des règles de comportement de Computer Integrated Manufacturing Open System Architecture (CIMOSA), et Deavours et al. (2002) génèrent des réseaux d'activités stochastiques (SAN) à partir de formalismes de modélisation compatibles avec le cadre Mobius. Les générateurs de modèles d'analyse de simulation utilisant des modèles de systèmes en langage SysML sont Batarseh et al. (2015) et Kapos et al. (2014), ce dernier générant des modèles exécutables de spécification de systèmes à événements discrets (DEVS).
Observez la variété des langages de description de systèmes dans les citations ci-dessus. Outre les "systèmes opérationnels discrets", les "graphes d'état partiels basés sur des messages", les CMSD, etc., il existe de nombreux autres langages candidats, allant d'idées de recherche à des normes adoptées. Une norme OASIS pour l'échange de données de planification et d'ordonnancement de la production est (OASIS 2011). Le comité ISO TC 184/SC4 a produit la norme ISO 10303 pour la capture et le partage de données de produits lisibles par machine (Pratt 2001). AutomationML est une norme de normes pour l'échange de données entre les outils d'ingénierie dans une installation de production (Drath et al. 2008). Ces efforts portent sur la normalisation des schémas de données, mais aussi sur la normalisation de la sémantique et des ontologies. Une norme de l'OMG formalisant la sémantique des processus d'entreprise est Business Process Model and Notation (BPMN) (OMG 2011). Une norme du Supply Chain Council formalisant la sémantique de la gestion de la chaîne d'approvisionnement est le Supply Chain Operations Reference (SCOR) (SCC 2012). Parmi les propositions de formalisation de la sémantique de la fabrication, citons Manufacturing Semantics Ontology (MASON) (Lemaignan et al. 2006), ainsi que Molina et Bell (1999), Cutting-Decelle et al. (2007), et Guerra-Zubiaga et Young (2008).
Tanenbaum (1981) fait remarquer que "l'avantage des normes, c'est qu'il y en a beaucoup parmi lesquelles on peut choisir"."Au cours des premières années du projet de recherche, les auteurs ont cherché un langage de description de système unique et "parfait" pour les systèmes de production (Thiers et McGinnis 2013), en agrégeant diverses contributions citées et en comblant les lacunes. Cependant, rien n'a jamais été développé que les auteurs pourraient plaider de manière plausible que le monde entier devrait utiliser, pour des raisons incluant une tension fondamentale entre le concret et l'abstrait (le premier est nécessaire pour l'accessibilité de l'utilisateur, le second est nécessaire pour la robustesse et la réutilisabilité), et aussi parce qu'un langage est inexorablement façonné par les cas d'utilisation de ses auteurs à un moment donné dans le temps.Inévitablement, les cas d'utilisation et le temps changent, le langage doit évoluer, les programmes de transformation qui sont étroitement liés au langage se cassent, et l'auteur doit maintenir un code qu'il a oublié depuis longtemps, si tant est que l'on puisse retrouver l'auteur original. Les progrès n'ont repris que lorsqu'il a finalement été admis qu'un langage de description de système unique et "parfait" pour les systèmes de production n'existerait peut-être jamais, et qu'un moyen a été conçu pour s'adapter à une pléthore de langages de description de système similaires mais différents.
1.2 Le défi des outils COTS de simulation d'événements discrets
Contrairement au domaine de l'analyse d'optimisation qui dispose d'un langage canonique "A Mathematical Programming Language" (AMPL) (Fourer et al. 1993), le domaine de la simulation d'événements discrets ne dispose pas, à la connaissance des auteurs, d'un tel langage canonique, et chaque choix de langage diffère des autres choix de langage tant au niveau de la sémantique que de la syntaxe. S'il existe m choix de langage de description de système etn choix de langage d'analyse de simulation, il en résultem n permutations de transformations de la description de système à l'analyse de simulation, ce qui limite considérablement le retour sur investissement de l'écriture et de la maintenance de chacune d'entre elles. La méthode décrite dans le présent document réduitm à1, mais autorise toujoursmlangages de description desystèmeen ajoutant une étape de transformation intermédiaire qui couple vaguement chaque langage à un langage d'abstraction de transition en arrière-plan.
Parmi les efforts cités à la section 1.1 pour générer automatiquement des modèles de simulation, il existe une grande variété dans l'emplacement de l'"intelligence" de transformation - elle peut être en amont dans le langage de description du système (confondant effectivement ce langage avec le langage d'analyse en aval), dans la transformation elle-même (comme avec les langages et outils de transformation de modèle à modèle polyvalents, y compris QVT (OMG 2016) et ATL (EMF 2016), ou en aval dans le langage d'analyse du système (confondant effectivement ce langage avec le langage de description en amont, l'approche de-facto de nombreux vendeurs d'outils de simulation COTS). Dans certains cas, les chercheurs tentent de simplifier les transformations en écrivant leur propre langage de simulation à événements discrets et leur propre solveur, comme dans Biswas et Narahari (2004), Chatfield et al. (2006), et Schonherr et Rose (2009), ce qui permet de transformer la description du système en analyse de simulation à l'aide de correspondances directes de un à un. Selon les auteurs, le développement d'outils d'analyse ad hoc lorsque des outils COTS appropriés sont disponibles - même si leur langage n'est pas pratique - ne semble pas être une voie durable. La méthodologie décrite dans le présent document place la majeure partie de l'"intelligence" de la transformation dans les transformations de modèle à modèle elles-mêmes, mais propose un petit pas en avant en construisant des modèles de simulation dans toute la mesure du possible à l'aide de blocs de bibliothèque de modèles qui sont des versions exécutables d'éléments de modèles d'abstraction de transition.
Méthodologie
Une méthodologie est un ensemble de processus, de méthodes et d'outils connexes (Estefan 2008), et le processus de la méthodologie du présent document est illustré à la figure 1. Le modèle du système en haut à gauche et le modèle d'abstraction de transition en haut au centre sont tous deux des descriptions uniquement, et tous deux sont en fait composés de deux niveaux différents d'abstraction de modélisation, que l'on pourrait appeler le schéma et les données ou le métamodèle et le modèle d'instance, ou encore les définitions de classes et les instanciations d'objets dans la terminologie des logiciels orientés objet. Le langage de description du système dont il est question en détail à la section 1.1 est la couche supérieure du schéma ou du métamodèle, et la distinction est importante car les transformations de modèle à modèle ne dépendent que de cette couche et devraient fonctionner avec n'importe quel modèle de données ou d'instance conforme. Le métamodèle Bridging Abstraction est une création abstraite qui capture les points communs sous-jacents partagés par tous les systèmes logistiques à événements discrets - systèmes de fabrication, chaînes d'approvisionnement, systèmes d'entreposage et de distribution, systèmes de transport et de logistique, systèmes de prestation de soins de santé, et bien d'autres encore. Une observation clé est que la plupart des systèmes étudiés en génie industriel ont une structure de réseau, et que la plupart des analyses de recherche opérationnelle de ces systèmes sont des analyses basées sur les réseaux. Le métamodèle d'abstraction de pontage a évolué depuis sa création en une collection de modèles en couches, mais la couche originale et fondamentale que les auteurs appellent un réseau de flux de jetons, dont un extrait est illustré à la figure 2.
Le modèle d'abstraction relais est introduit pour arbitrer une tension fondamentale entre le concret et l'abstrait - un modèle de système doit être aussi concret que nécessaire pour l'accessibilité, le modèle d'abstraction relais doit être aussi abstrait que possible pour la robustesse et la réutilisabilité, et l'efficacité dépend des correspondances facilement créées et maintenues entre les deux. Les correspondances se présentent comme des spécifications déclaratives de transformations de modèle à modèle, et leur mise à jour en réponse à des modèles de système nouveaux ou en évolution doit être aussi simple et rapide que possible. Dans la terminologie logicielle, l'étape intermédiaire ajoutée a pour effet d'atténuer le couplage étroit entre les langages de description du système et les langages d'analyse du système, afin de réduire les coûts lorsqu'un langage de description du système doit inévitablement changer en fonction des cas d'utilisation et du temps. Dans la figure 1, le couplage de deuxième étape entre le modèle d'abstraction relais et le modèle d'analyse restera étroit, mais le couplage de première étape entre le modèle de système et le modèle d'abstraction relais devrait être aussi lâche que possible pour s'adapter à des modèles de système nouveaux ou évolutifs. Il est important de noter qu'en raison de la stabilité du modèle d'abstraction relais, la tâche consistant à écrire et à maintenir les transformations de deuxième étape devrait avoir un retour sur investissement suffisant pour être adoptée par une équipe dédiée, par opposition à des analystes divers.
Beaucoup d'idées nouvelles sont des variations sur des idées anciennes, et le processus présenté dans la figure 1 peut être classé comme tel, une transplantation des meilleures pratiques de l'ingénierie logicielle à l'ingénierie des systèmes. La nouveauté de la méthodologie réside dans ses méthodes et ses outils qui abordent les grands défis de la recherche pour que cela fonctionne pour l'ingénierie des systèmes :
- Le métamodèle d'abstraction de transition - un métamodèle explicite, neutre du point de vue de l'analyse et lisible par l'homme et la machine, qui capture les points communs sous-jacents partagés par tous les systèmes logistiques à événements discrets. Au fur et à mesure de l'évolution du projet de recherche, il est rapidement apparu que le modèle d'abstraction de transition serait développé de manière itérative au cours des années à venir. La modélisation de la structure d'un système est généralement le fruit le plus facile à atteindre, la modélisation du comportement (pensez aux processus) est généralement plus difficile, et la modélisation du contrôle (pensez aux règles de gestion) est généralement la plus difficile de toutes. En outre, la plupart des langages candidats à la création de ce métamodèle (UML, SysML, Ecore, OPM, diagrammes entité-relation, etc. - le langage du langage) sont orientés objet, et la modélisation de systèmes orientés objet peut être un mode de pensée peu familier.
- Transformations de modèle à modèle. Pour transformer un modèle de système en un modèle d'abstraction de transition (figure 1), le mécanisme a évolué, passant de l'application de stéréotypes UML à des spécifications déclaratives dans des langages de transformation à usage général, notamment QVT et ATL, à un langage et un moteur de transformation de modèle à modèle personnalisés, décrits plus en détail à la section 3.
- Comprendre l'espace des questions sur les systèmes de production et les analyses capables d'y répondre. Ce défi est intimement lié à la connaissance approfondie du domaine. Si et quand une mise en œuvre de la méthodologie prend en charge une masse critique de questions courantes sur la productibilité, un nouveau défi se posera : comment faire un usage productif d'un "génie de la réponse aux questions" en posant les bonnes questions. Les auteurs estiment qu'il faudra pour cela saisir les processus de plus haut niveau (diagnostic, amélioration continue, conception, etc.) et les questions posées à chaque étape de l'exécution de ces processus.
Une discussion approfondie des processus, méthodes et outils de la méthodologie peut être trouvée dans Thiers (2014), Sprock et McGinnis (2014), et Sprock (2016). La recherche et l'expérimentation de nouvelles méthodes et de nouveaux outils se poursuivent, par exemple une méthode consistant à utiliser des blocs de bibliothèque de modèles qui sont des versions exécutables d'éléments de modèles d'abstraction de transition, dans toute la mesure du possible, lors de la construction de modèles d'analyse dans un domaine dépourvu de langage canonique.
PROJET PILOTE
Fin 2014, la méthodologie avait mûri sur le papier, et un projet pilote a été mené en 2015 pour démontrer son efficacité, c'est-à-dire qu'une mise en œuvre de la méthodologie pouvait effectivement réduire le temps nécessaire pour répondre à une question fréquemment posée d'au moins un ordre de grandeur, d'une manière reproductible, alors que les spécifications des produits, leurs plans de traitement, les installations prévues et les ressources disponibles changent continuellement. Les étapes à suivre sont les suivantes :
Étape 1 : Demander à l'utilisateur de choisir un scénario fréquemment rencontré pour lequel la formulation par bouton-poussoir de modèles de simulation à événements discrets, pour répondre à une variété de questions, pourrait être très utile.Le scénario pour ce projet impliquait l'évaluation de la capacité de fabrication pour la fabrication de pièces composites, avec la question fréquemment posée "Quel est le nombre minimum de ressources nécessaires pour soutenir une cadence de production donnée ?" Les ressources en moules de stratification et en autoclaves pour les composites sont particulièrement intéressantes. Pour les grandes pièces aérospatiales, ces ressources peuvent être très coûteuses et les délais d'approvisionnement très longs.
Étape 2 : Pour le scénario choisi, créer un langage de description de système.Cette étape nécessite de capturer la sémantique neutre que les utilisateurs emploient pour parler de leur activité et la représenter dans les systèmes d'information. Ce langage a évolué de manière itérative au cours du projet pilote, et son état lors de l'itération finale est illustré à la figure 3. Notez qu'il s'agit d'un modèle au niveau du schéma et non d'une instance de système de production - il sert de définition commune pour les installations, les processus de fabrication, les solutions de remplacement, les états futurs souhaités, etc.
Le langage de la figure 3 peut-il être considéré comme un métamodèle abstrait permettant de décrire des systèmes de production arbitraires ? Certainement pas - il s'agit du schéma d'un utilisateur particulier, et d'un schéma minimal pour un cas d'utilisation particulier, qui peut différer syntaxiquement et même sémantiquement des schémas d'autres utilisateurs. Les caractéristiques importantes comprennent la mise en lots à l'autoclave (par volume de pièce, ou par une liste spécifique de types et de quantités de pièces), ainsi que les ressources associées aux pièces à travers plusieurs étapes du processus (moules de stratification composite, de la pré-couche à la post-cuisson). Cette sémantique permet également de séparer les installations physiques des définitions des processus fonctionnels, car un élément clé de la question de la capacité est que les plans de processus ne s'exécutent pas dans le vide, mais plutôt dans des installations particulières qui exécutent plusieurs plans de processus simultanément tout en partageant des ressources communes. La sémantique qui n'est pas incluse, mais qui peut être importante dans d'autres scénarios, comprend les travaux avec des délais, les réseaux de déplacement à l'intérieur et entre les installations, le contrôle de l'acheminement des travaux et des ressources, et bien d'autres choses encore. L'innovation de la méthodologie réside dans le fait que les programmes du générateur d'analyse ne sont que faiblement couplés au langage de description du système de la figure 3, ce qui permet à ces programmes de continuer à travailler pendant que le langage évolue (au cours du projet pilote, le langage a évolué en huit itérations environ, espacées d'un mois). En d'autres termes, la méthodologie permet d'alléger le fardeau qui consiste à rendre un langage de description de système "parfait" avant d'investir dans les programmes des générateurs d'analyse qui en dépendent.
Étape 3 : Préciser la questionCette étape devrait devenir superflue à partir d'un certain niveau de maturité de l'outil, mais elle est impérative au cours des premiers projets pilotes. Il s'agit de déterminer les informations que le demandeur attend d'une réponse et la manière d'extraire ou de déduire ces informations des résultats de la simulation. À la question"Quel est le nombre minimum de ressources nécessaires pour soutenir un taux de production donné ?", supposons que la réponse renvoyée soit "x ety unités des types de ressources A et B sont les quantités minimales nécessaires pour soutenir, en moyenne, 20 avions par mois". Est-ce suffisant, ou faut-il également prévoir des qualificatifs de risque tels que"x et y unités de ressources de types A et B ne produiront que 19 avions dans α% des mois et seulement 18 avions dans β% des mois" ? Le retour des réponses avec des interprétations, des qualificatifs de risque, etc. est un point important pour le développement futur. La méthodologie permet de créer un outil d'aide à la décision, et non un outil de prise de décision, car la prise de décision doit refléter une évaluation humaine du risque, qui pourrait être l'axe x d'une certaine forme de diagramme Pareto-frontière qui est renvoyé comme réponse à une question.
La précision de la question a également nécessité des efforts qui étaient propres au premier projet. Comme l'essentiel du travail consistait à développer des logiciels, un paradigme de développement en spirale a été suivi, avec une période d'itération d'environ un mois. La question "Quel est le nombre minimum de ressources nécessaires pour soutenir un taux de production donné ?" est devenue le point culminant d'une série de questions clés :
- Quel est le temps de cycle brut (attendu) d'un certain travail ? Un modèle de simulation à événements discrets pour répondre à cette question est le plus simple et le plus intéressant que l'on puisse imaginer.
- Quel est le débit (attendu) de l'exécution régulière d'un certain travail ? La réponse à cette question ne nécessite qu'une simulation de processus, sans le contexte d'une installation de fabrication, d'autres plans de processus exécutés simultanément dans cette installation, de paradigmes de partage des ressources, etc.
- Quel est le débit (attendu) de la fabrication de certains (produits) dans une certaine (installation) ? Pour répondre à cette question, il faut simuler une seule installation de fabrication exécutant simultanément plusieurs plans de processus tout en partageant des ressources communes. Tout ce qui sépare la réponse à cette question de la question principale est l'ajout d'un optimiseur pour rechercher des nombres minimums de ressources.
- Quel est le nombre minimum de ressources nécessaires pour assurer un certain débit ? Il est intéressant de noter qu'un optimiseur n'a jamais été ajouté ; le promoteur du projet pilote a reconnu qu'il s'agissait d'une simple extension et a choisi de mieux utiliser le temps consacré à la fidélité de la description du système et, par conséquent, des modèles de simulation générés automatiquement.
L'efficacité de la méthodologie dépend du couplage le plus étroit possible entre ces deux modèles, et le plus étroit que nous puissions imaginer est une spécification déclarative d'une transformation de modèle à modèle, dont un exemple est illustré à la figure 4.
Le XML de la figure 4 est une représentation de bas niveau avec laquelle les utilisateurs ne devraient pas être censés interagir directement - des améliorations de la convivialité devraient rendre la rédaction et la mise à jour des spécifications déclaratives des transformations de modèle à modèle beaucoup plus faciles à utiliser. Au début du projet, les auteurs avaient imaginé réaliser ces mappings via le mécanisme d'application des stéréotypes UML (Batarseh et al. 2012). Cependant, cela est rapidement devenu intenable en raison de la rigidité - l'application d'un stéréotype UML définit effectivement une règle de transformation un-à-un, ce qui contraint le modèle du système et le modèle d'abstraction de pontage à se ressembler beaucoup et à ne différer que par la syntaxe. Les auteurs ont ensuite envisagé des langages de transformation de modèle à modèle généraux et normalisés, notamment QVT ou ATL, mais les spécifications de transformation étaient assez verbeuses et ils se sont rapidement rendu compte que l'incorporation de la connaissance de la cible de la transformation permettait une simplification considérable. Cette simplification entraîne une perte de flexibilité, mais une flexibilité qui n'était pas nécessaire, conformément à la conclusion de Cleenewerck et Kurtev (2007) selon laquelle "il est préférable d'aborder le problème de la sémantique translationnelle dans l'ingénierie pilotée par les modèles avec un langage de transformation spécifique au domaine plutôt qu'avec un langage à usage général". Les travaux futurs consisteront à réconcilier le langage de transformation personnalisé et spécifique au domaine avec une norme telle que QVT.
Étape 5 : Créer des modèles d'instance et appuyer sur "go". Pour répondre à une question de productibilité par un bouton poussoir, la dernière étape consiste à décrire rapidement l'objet de la question, à savoir des instances de produits, de processus, de ressources et d'installations. Le métamodèle de la figure 3 est analogue aux définitions de classes logicielles qui peuvent engendrer un grand nombre d'instanciations d'objets, et cette étape exige de créer ces instanciations d'objets. Dans le projet pilote, cela a été fait dans un environnement tabulaire et de type Excel, et un extrait est présenté dans la figure 5.
Les tables et leur schéma de la figure 5 sont conformes au métamodèle de la figure 3 - l'opération correspond à une table et chaque attribut correspond à une colonne. Les tables et le schéma d'un modèle d'instance sont générés par le biais d'un mappage objet-relationnel, et un utilisateur décrit le sujet de la question en remplissant les tables. Il s'agit d'un environnement de modélisation qui pourrait bénéficier de nombreuses améliorations en termes de convivialité ; l'une d'entre elles est que les tableaux présentés aux utilisateurs sont en fait des tableaux bruts de bases de données relationnelles, et l'ajout d'une couche de visualisation permettra de simplifier, d'organiser et de masquer les données redondantes (par exemple, les tableaux de jonction qui découlent de tout attribut dont la limite supérieure de la multiplicité est > 1). Une autre amélioration réside dans le fait que si les tableaux et les colonnes sont présentés dans la figure 5 pour chaque élément du métamodèle de la figure 3, la connaissance de la question de l'utilisateur permet de filtrer visuellement les tableaux et les colonnes pour ne retenir que ceux qui sont pertinents pour répondre à cette question. Une autre amélioration consiste à ajouter la visualisation quel que soit le modèle de système de l'utilisateur. À mesure que les lignes des tableaux sont remplies, un modèle d'abstraction de liaison est construit en arrière-plan et la visualisation devrait être possible au moins pour les vues du processus et de l'installation. L'amélioration de la convivialité de cet environnement est essentielle pour réduire au maximum le temps et l'expertise nécessaires pour répondre aux questions courantes sur la productibilité.
La figure 6 présente un exemple de modèle de simulation à événements discrets et d'expérience générés automatiquement lorsque l'on appuie sur "go".
L'impact sur les entreprises
Conclusions et travaux futurs
Le passage de la conception à la production est un processus commercial complexe, et la recherche décrite dans le présent document soutient ce processus en permettant aux concepteurs d'apprécier les conséquences des décisions de conception sur la production beaucoup plus tôt dans le cycle de conception d'un programme qu'il n'est possible de le faire aujourd'hui. Une méthodologie a été mise au point pour permettre de répondre aux questions de productibilité à l'aide d'un bouton-poussoir, et sa nouveauté réside dans son degré de séparation des préoccupations - elle sépare la description du système de l'analyse du système, et sépare en outre la description concrète du système frontal de la description abstraite du système dorsal. La mise en œuvre d'un projet pilote prend en charge les modèles de système rédigés dans le langage Ecore, l'ensemble des questions énumérées dans la section 3 et la génération par bouton-poussoir de modèles de simulation et d'expériences dans les langages Simio, SimEvents et Tecnomatix Plant Simulation pour répondre à ces questions. La question du projet pilote concernait le nombre de ressources - un changement paramétrique - et la mise en œuvre a également été démontrée pour prendre en compte les changements structurels, y compris les changements dans les plans de processus, les changements dans l'affectation des postes de travail, l'affinement des types de ressources, la description à des niveaux d'abstraction, et plus encore. Au moment de la rédaction du présent document, il n'y a pas de différence fonctionnelle entre les changements paramétriques et structurels puisque la mise en œuvre régénère entièrement un modèle de simulation pour toute modification du modèle d'instance, bien que cela puisse devenir plus sophistiqué à l'avenir pour des raisons d'efficacité.
À la fin du projet pilote, la mise en œuvre du logiciel de démonstration a été déployée chez le client pilote. Le client estime que pour les questions courantes concernant les systèmes de production, la mise en œuvre de la méthodologie à l'aide d'un outil peut entraîner une réduction considérable du temps, du coût et de l'expertise nécessaires pour utiliser la simulation et d'autres types d'analyse afin de répondre à ces questions, une réduction d'au moins un ordre de grandeur. Ces réductions peuvent être économisées ou consacrées à l'évaluation d'un plus grand nombre de scénarios de production et de leurs impacts, à l'examen d'un plus grand nombre d'idées et d'alternatives d'amélioration et à l'exploration d'une plus grande partie de l'espace de conception d'un système de production. Cependant, le client note également que plusieurs améliorations sont nécessaires pour atteindre un niveau de préparation technique (TRL) avancé et produire un outil que les analystes apprécieraient dans leur travail quotidien. L'outil est un environnement de modélisation et de transformation de modèles, et des améliorations du langage et de l'interface utilisateur sont nécessaires pour créer des schémas de description de système, des modèles d'instance de système conformes, des transformations en modèles d'abstraction de transition et des processus de formulation d'analyse automatisés. Ces améliorations permettront de délimiter les types de questions sur les systèmes de production qui sont en fait "de routine", ce qui pourrait constituer un ensemble étonnamment généreux.
On espère que cette recherche pourra développer le marché des analyses de recherche opérationnelle. Les analyses statistiques, les simulations d'événements discrets et les analyses d'optimisation peuvent répondre à des questions d'une importance cruciale, mais le temps, le coût et l'expertise nécessaires à leur utilisation dans le cadre du statu quo peuvent être prohibitifs pour toutes les entreprises, à l'exception des plus grandes d'entre elles. Il existe de nombreuses pistes de travail pour l'avenir, les plus urgentes étant, de l'avis des auteurs, l'évolution des descriptions de systèmes, de la structure principalement vers des modèles plus matures incluant le comportement et le contrôle, et la compréhension des processus de plus haut niveau, y compris la conception, le diagnostic et l'amélioration continue. Une compréhension approfondie des systèmes d'ingénierie industrielle, ainsi qu'une capacité à utiliser de manière rentable l'analyse de la recherche opérationnelle en fonction des besoins, sont des conditions préalables pour rendre la conception des systèmes de production aussi sophistiquée que la conception des produits eux-mêmes.
Remerciements
Les recherches présentées ici ont été soutenues par Georgia Tech par l'intermédiaire de la chaire Gwaltney des systèmes de fabrication, par une subvention de Rockwell-Collins et par des projets de recherche financés par le centre de recherche de United Technologies et le partenariat universitaire stratégique Boeing-Georgia Tech.