# Un DSL pour représenter et analyser des systèmes à événements discrets *

Pascal Andre, Hugo Locteau, Yasmina Dali Youcef, Erwan Bousse, Olivier Cardin

► To cite this version:

Pascal Andre, Hugo Locteau, Yasmina Dali Youcef, Erwan Bousse, Olivier Cardin. Un DSL pour représenter et analyser des systèmes à événements discrets *. Modélisation des Systèmes Réactifs (MSR'25), CReSTIC et LICIIS, Nov 2025, Reims (51), France. hal-05384922

HAL Id: hal-05384922

https://hal.science/hal-05384922v1

Submitted on 27 Nov 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Un DSL pour représenter et analyser des systèmes à événements discrets *

Pascal André, Hugo Locteau, Yasmina Dali Youcef, Erwan Bousse, and Olivier Cardin

LS2N, Nantes Université, France
{firstname.lastname}@ls2n.fr

## Résumé

Il existe de nombreuses approches (langages, techniques, outils) pour étudier (i.e. modéliser, analyser) des systèmes à événements discrets dans différents contextes. Les langages généralistes, i.e. indépendant du contexte d'application, ont fait leur preuve en terme d'expressivité ou d'efficacité d'analyse, mais souffrent de deux inconvénients. D'une part, ils pêchent à s'adapter à leur contexte d'application, on a donc besoin de spécialistes pour définir et analyser les systèmes. D'autre part, les outils manquent de généralité quand à l'éventail des propriétés à démontrer, ce qui amène à utiliser différents outils et nécessite donc encore plus de spécialistes pour un projet donné. Dans cet article, nous exploitons l'usage de Domain-Specific Languages (DSLs) pour étudier des SED adaptés à leur contexte : définition d'un langage, d'un outillage de modélisation et de vérification. Cette contribution est illustrée sur une étude de cas de production manufacturière pour alimenter empiriquement la réflexion sur le sujet de l'accessibilité des langages de modélisation. Le langage est suffisamment générique pour s'adapter à d'autres contextes.

## 1 Introduction

Pour mettre en place des systèmes dont la dynamique est relativement complexe, on utilise des méthodes, techniques et outils fondées sur des modèles mathématiques ou informatiques. La modélisation permet d'abstraire les caractéristiques souhaitées du système pour les étudier, l'analyse du modèle permet d'en déterminer les propriétés. On se place dans une démarche d'ingénierie classique dans laquelle le processus vise à modéliser le système, vérifier ses propriétés et/ou simuler son comportement dans le temps pour estimer s'il répond aux besoins de l'organisation qui implante le système réel. Les propriétés du modèle sont sa correction ou sa validité vis-à-vis du besoin. Les propriétés fonctionnelles du système peuvent être des invariants à vérifier comme des contraintes de sûreté de fonctionnement (safety) ou de non blocage (likeness). Les propriétés non-fonctionnelles apparaissent sous forme de contraintes de qualité de service ou d'indicateurs clés de performance cible (Key Performance Indicators, KPI).

Nous considérons pour ce travail des Systèmes dynamiques à Evénements Discrets (SED). Les SED sont des systèmes dynamiques non linéaires à états discrets et à évolution événementielle. Contrairement aux systèmes (à états) continus décrits par des équations différentielles (temps continu) ou des équations aux différences (temps discret) contrôlés par le temps, les SED ont un espace d'états décrit par un ensemble discret [16].

Il existe de nombreuses approches (langages, techniques, outils) pour étudier (i.e. modéliser, analyser) des systèmes à événements discrets dans différents contextes. Les langages peuvent inclure la description explicite ou implicite d'états, de synchronisation, de concurrence ou de

<footnote>*Les auteurs remercient l'Agence Nationale de la Recherche (ANR) pour son soutien financier dans le cadre du projet RODIC, numéro de subvention ANR-21-CE10-0017.</footnote>
communication, inclure du temps (temporel, temporisé), ou des probabilités (stochastique). Les techniques d'analyse couvrent la vérification statique de propriétés, l'analyse symbolique, le model checking. Elle peuvent s'appuyer sur l'exploration des états possibles du système ou des chemins. L'analyse peut s'appuyer aussi sur la simulation selon des scénarios d'exécution. Les langages généralistes, i.e. indépendant du contexte d'application, ont fait leur preuve en terme d'expressivité (ici au sens de paradigmes pris en compte comme les états, le temps ou les événements) ou d'efficacité d'analyse.

Ces langages pour SED souffrent de deux inconvénients pour une prise en main par des non-spécialistes. D'une part, ils ne s'adaptent guère au contexte d'application, leur expressivité est limitée au modèle mathématique associé et on a besoin de spécialiste pour définir et analyser les systèmes. D'autre part, les outils ne couvrent pas l'éventail des propriétés à démontrer. Couvrir avec plusieurs outils implique encore plus de spécialistes pour un projet donné.

Dans cet article, nous explorons l'usage d'un Domain-Specific Languages (DSL) pour étudier des SED : définition du langage et de l'outillage de modélisation et de vérification. Le cas d'usage sous-jacent est la production manufacturière mais le langage est plus générique et peut s'adapter à d'autres contextes. Cette contribution est illustrée sur une étude de cas et permet d'alimenter empiriquement la réflexion sur le sujet en la comparant avec les approches classiques.

L'article est organisé comme suit. Nous commençons par introduire les éléments de contexte dans la section 2. La section 3 décrit la contribution principale, à savoir un DSL pour modéliser des systèmes à événements discrets, applicable notamment aux systèmes manufacturiers. La mise en œuvre de ce DSL est détaillée dans la section 4. Le langage été expérimenté sur plusieurs études de cas, nous en décrivons une dans la section 5. Nous discutons des propriétés du DSL, son positionnement dans les systèmes à événements discrets ; sa combinaison avec d'autres DSL en section 6 avant de conclure.

## 2 Contexte

Le contexte général de ce travail est celui de l'ingénierie système (system engineering) [22] au niveau de la conception abstraite. Plus particulièrement, nous nous intéressons à la modélisation de systèmes (system modelling) qui couvre trois points de vue complémentaires, la structure, le comportement dynamique (le contrôle) et le comportement fonctionnel (les calculs) [4, 5]. Comme indiqué dans l'introduction, on se focalise sur les systèmes à temps discret avec des événements. L'application se fait ici aux systèmes manufacturiers [11], ce qui a une certaine importance pour les caractéristiques des langages de modélisation choisis.

### Formalismes et outils (l'offre)

Pour concevoir les systèmes, on a besoin d'une méthode avec des concepts (philosophie), des notations (langage), un processus (modélisation, vérification, validation, exploitation) et des outils pour automatiser les traitements sur les modèles. On parle aussi d'ingénierie des modèles pour produire les outils. La littérature sur le sujet est conséquente et de nombreuses propositions existent [4]. Leurs langages se distinguent notamment par (i) le degré de formalisme avec des méthodes formelles (réseaux de Petri RDP, systèmes de transitions, automates, modèle relationnel MR, Z, B...) ou semi-formelles (Entité-Association EAP, UML, SysML, flots de données DFD...), (ii) la couverture des aspects du système : structure (EAP, MR), dynamique (RDP, automates), fonctionnel (Z, DFD...), (iii) leur généralité (applicabilité/adéquation à des cas différents), (iv) leur propriétés ou qualités (expressivité, degré d'abstraction, modularité, correction, cohérence, complétude, testabilité, performance...), (v) l'outillage associé, etc.
Il existe des langages large spectre comme UML, SDL ou SysML, très expressifs mais dont l'outillage associé aux étapes du processus reste limité. A l'inverse les langages se focalisant sur un aspect du système dans une théorie donnée sont équipés d'outils performants de vérification mais manquent alors d'expressivité.

## Domaine étudié et besoins identifiés

Le domaine d'application choisi pour cette étude est celui des systèmes manufacturiers et plus particulièrement les Reconfigurable Manufacturing Systems (RMS). Nous souhaitons modéliser des chaînes de production et analyser leur performance avant leur mise en place effective. Le point de vue est celui d'un opérateur humain : on s'abstrait donc de la structure cyber-physique de production (les machines) et du contexte organisationnel (le système d'information de l'entreprise) duquel on ne retient que les ordres de fabrication, les produits et les indicateurs de performance.

- La modélisation pour cette application doit couvrir les trois aspects du système (structure, dynamique, fonctions). L'aspect dynamique est incontournable et le contrôle, dans un système de production, suit deux logiques non-exclusives : l'approche flots de données (la chaîne est cadencée par l'arrivée des produits) et l'approche flot de contrôles (des événements modifient/perturbent le déroulement du processus de production).

- L'analyse doit couvrir à la fois la vérification formelle et la simulation, ce qui exclut les approches semi-formelles comme UML ou SysML.

- Une contrainte importante est que les acteurs du systèmes de production (responsable d'ateliers, conducteur de lignes ou opérateur) sont aussi les utilisateurs des outils de modélisation. L'expressivité est donc un critère d'acceptabilité de l'approche. Les approches purement mathématiques comme les systèmes de contrainte, les algèbres, les logiques mathématiques de base, le calcul matriciel et autres sont donc exclues.

- Une dernière contrainte du domaine est la *scalabilité*, c'est-à-dire la possibilité de passer à l'échelle de manière naturelle. On souhaite en particulier composer des systèmes de systèmes à plusieurs niveaux de profondeurs.

## Alternatives et solution choisie

Parmi les approches candidates, on trouve des systèmes à événements discrets (SED) de deux types : les outils de vérification formelle et les simulateurs à événements discrets.

Bérard et al. [7] proposent un éventail de langages et outils pour la modélisation et la vérification par *model-checking* de la dynamique des systèmes dits réactifs tels que les réseaux de Petri, les automates communicants ou les algèbres de processus. Ils peuvent, ou pas, prendre en compte le temps réel et des paramètres plus riches tels que des objets. Notons que la vérification formelle par *model-checking* peut se faire à partir de l'exploration de l'espace d'états du système et/ou l'analyse des chemins (traces) par des logiques adaptées comme les logiques temporelles. Les traces peuvent être obtenues par simulation (exécutions indépendantes les unes des autres) ou par parcours de l'espace d'états du système (les chemins produisent les traces). Nous retenons principalement les automates et les réseaux de Petri comme formalisme visuel accessible aux opérateurs, nous avons testé Romeo [14], Tina [8] et CPN Tools [21]. L'inconvénient majeur des réseaux de Petri est le manque de modularité pour réutiliser des parties de modèles dans d'autres modèles, ce qu'un opérateur souhaite faire lors de la conception de la chaîne de production. Les automates synchronisés ou communicants (ou variantes de systèmes de transition) sont plus modulaires et a priori adaptés mais les outils existants tels que UPPAAL [6] restent limités
dans l'expressivité des données et des calculs. Les algèbres de processus sont plus expressives, notamment leur extensions comme LOTOS et l'outil CADP [13], mais la description reste technique et le découpage pas toujours naturel. Un manque récurrent est la possibilité de mixer flots de données et flots de contrôle dans les outils formels.

Jadri et al. comparent des outils de simulation d'événements discrets dans un environnement académique [17]. Dans nos travaux, nous avons utilisé Arena [18] et FlexSim [20]. Une comparaison entre Simio et Arena est proposée dans [23]. Ces outils sont puissants à la fois pour l'expressivité avec des IHM très réalistes et pour la simulation avec du calcul d'indicateurs. Par contre le niveau d'expertise est souvent élevé (description structurelle vs flots de contrôles) et le niveau d'abstraction bas (nombreux paramètres très cachés dans les sous-fenêtres d'IHM).

Nous n'avons pas trouvé un trouvé d'outil couvrant l'ensemble des besoins entre expressivité, simplicité, adaptation au domaine manufacturier, avec vérification et simulation. Nous avons donc décidé de développer notre propre langage, plus léger, adapté au domaine des systèmes manufacturiers reconfigurables. On qualifie ces langages de *domain specific* ou DSL.

# 3 Un DSL pour modéliser les systèmes manufacturiers

Cette section présente conceptuellement un DSL pour modéliser et étudier des RMS pour lesquels des descriptions de type SED modulaires sont requises. Nous résumons d'abord la syntaxe de ce DSL, dans sa forme dite abstraite définie par un métamodèle et dans sa forme dite concrète définie par une grammaire. Nous résumons ensuite la sémantique opérationnelle de ce DSL, à savoir la définition de l'état de simulation et de son évolution dans le temps. Notez que, pour des raisons de place, nous n'exposons ici qu'un extrait du métamodèle et une version détaillée figure en Section A.1 de l'annexe que nous avons mise à disposition en ligne<fnref n="1" />.

## 3.1 Syntaxe abstraite

La syntaxe abstraite du DSL proposé est définie sous la forme d'un métamodèle, à savoir un modèle orienté objet définissant un ensemble de concepts sous forme de classes. Ce métamodèle est structuré en deux parties : d'abord les concepts permettant la définition de la *structure* d'un système, à savoir l'assemblage des modules du système de production modélisé, puis les concepts permettant la définition du *comportement* dynamique et fonctionnel des modules, à savoir l'évolution dans le temps et les traitements réalisés.

Pour définir la structure d'un système, le concept principal est nommé *ProductionSystem*, qui décrit une configuration du système de production. La modularité est une caractéristique majeure des RMS<fnref n="2" />. Pour la mettre en œuvre, le modèle est organisé en *Modules* définis par des *ModuleTypes*. Un extrait<fnref n="3" /> du métamodèle structurel illustre ces concepts dans la FIGURE 1. Un même module type peut donc être instancié plusieurs fois dans le système, avec des paramètres différents. Les modules sont reliés entre eux par des liens *Binding* via des connecteurs (*Connectors*), qui peuvent être soit "offerts" (c'est à dire, mentionnent une caractéristique sortante) ou "requis" (c'est à dire, mentionnent une caractéristique entrante). Des *Elements* (produits, conteneurs, événements) transitent par ces liens. Selon l'interprétation choisie, on peut souhaiter travailler en flot de données (produits) ou flot de contrôle. Un module dispose de différentes *Zones* pour stocker ces éléments. Il peut rendre accessible ses zones à d'autres

<footnote n="1">1. https://uncloud.univ-nantes.fr/index.php/s/2depFJSeJ6RkeiR</footnote>

<footnote n="2">2. Les *Reconfigurable Manufacturing Systems* sont une classe de systèmes manufacturiers dans laquelle la production peut évoluer selon le contexte (demande, aléas techniques, pannes...) [19].</footnote>

<footnote n="3">3. La structure est détaillée dans FIGURE 8 de l'annexe web¹.</footnote>
<figure><img src="image_2.png" /><figcaption>FIGURE 1 – Extrait de la syntaxe abstraite (Module, ModuleType et Connector)</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>FIGURE 2 – Exemple partiel de modèle conforme à la syntaxe abstraite du DSL, sous forme arborescente</figcaption></figure>

```xml
modules {
    Module TourDeStockage {
        type Stock
        initialelementsets {
            InitialElementSet {
                stock 3
                elementtype "Rotor"
                zone "Stock.etage2"
            }
        }
    },
    Module Poste1 {
        type PosteDeTravail
    }
}
```

<caption>FIGURE 3 – Représentation textuelle partielle du modèle montré en FIGURE 2</caption>

modules via les connecteurs pour l'échange d'éléments. La structure modulaire de la configuration facilite l'évolution du système. La FIGURE 2 montre partiellement sous forme arborescente un exemple de modèle conforme à la partie structurelle de la syntaxe abstraite du DSL. La racine du modèle est une instance du concept ProductionSystem, auquel est associé une durée de simulation souhaitée de 1000 unités de temps. Deux ModuleTypes sont définis, un premier appelé Stock qui décrit la structure et le comportement d'une zone de stockage, et un second appelé PosteDeTravail qui décrit la structure et le comportement d'un poste de travail d'assemblage. Deux Modules sont définis, un premier appelé TourDeStockage instance du type Stock, et un second appelé Poste1 instance du type PosteDeTravail. Un Binding connecte ces deux modules.
Le comportement dynamique et fonctionnel (*Behavior*) des modules est défini dans leur type (*ModuleType*) sous forme de tâches dont le déclenchement est défini par des règles (*TaskRule*). Cette partie comportementale du modèle est donnée dans FIGURE 9 de l'annexe web¹. Il n'y a donc pas de notion explicite d'état (et état courant) comme dans un automate ou un réseau de Petri. Une *TaskRule* spécifie une unité de logique d'exécution, incluant les conditions de déclenchement de la règle *Precondition* et les *Actions* à effectuer. Une précondition définit les conditions logiques qui doivent être remplies pour que la règle de tâche correspondante soit éligible à l'exécution. En particulier, on peut tester la présence d'un *Element* ayant un état donné dans une *Zone* donnée. Chaque *TaskRule* encapsule une ou plusieurs actions qui définissent la sémantique opérationnelle du comportement. Le DSL prend en charge diverses actions spécifiques au domaine permettant la modélisation de comportements tels que la création, le déplacement et la reconfiguration structurelle des *Elements*.

## 3.2 Syntaxe concrète textuelle

La syntaxe concrète textuelle du DSL est directement destinée aux utilisateurs du DSL, et permet de définir des modèles conformes sous forme de texte. Elle est définie sous la forme d'une grammaire qui structure textuellement un modèle principalement à l'aide d'accolades et de mots-clés associés aux différents concepts de la syntaxe abstraite. Cette grammaire permet de produire un analyseur syntaxique capable de traduire un modèle textuel en un arbre syntaxique conforme à la syntaxe abstraite présentée précédemment.

La FIGURE 3 montre partiellement sous forme textuelle le modèle présenté initialement sous forme arborescente en FIGURE 2. Chaque module est déclaré à l'aide du mot-clé *Module*, et le type d'un module est déclaré à l'aide du mot-clé *type*. Le mot-clé *InitialElementSet* permet de définir un stock initial de produits présents au sein d'une zone d'un module.

## 3.3 Sémantique opérationnelle

La sémantique opérationnelle du DSL définit l'état de simulation du système et son évolution dans le temps. Une simulation est une suite d'états, qui pourra *in fine* être stockée dans une trace d'exécution de la simulation. Les changements d'états se font par les tâches inscrites dans un échéancier et qui ont une certaine durée.

L'état de simulation est défini sous la forme d'un métamodèle distinct de la syntaxe abstraite, visible au sein de la FIGURE 10 de l'annexe web¹. Le concept principal est appelé *ProductionSystemSimulation*, qui maintient le contexte de simulation, y compris le système actif actuel et le temps de simulation. Il contient des instances les états d'entités telles que *Product*, *Container*, *ModuleState* et *ZoneState*, qui reflètent la configuration réelle, avec l'emplacement des produits et les conditions du module. Le comportement d'exécution est représenté par les instances *Task*, qui suivent des attributs tels que *startTime*, les comportements associés et l'état d'exécution (par exemple, *OFF*, *ON*). L'inclusion du *ZoneState* permet un suivi détaillé du placement des éléments dans les modules.

La sémantique opérationnelle du DSL définit également de quelle manière un tel état de simulation évolue dans le temps. On détermine la suite des tâches qui déclenchent les changements d'état (plusieurs tâches peuvent se terminer au même moment). Lors d'un changement d'état, on détermine les *TaskRules* applicables et donc les tâches à entrer dans l'échéancier de simulation. Lorsque les tâches se terminent dans la chronologie du temps simulée, les éléments et produits concernés par ces tâches sont déplacés de zones en zones (dont les contenus sont capturés par des objets *ZoneState*) comme spécifiés dans les comportements des *ModuleTypes*.
<figure><img src="image_4.png" /><figcaption>FIGURE 4 – Extrait de l’API Java générée à partir du métamodèle Ecore montré en FIGURE 1, avec la classe Java pour le concept Module</figcaption></figure>

Une exécution complète de modèle à l'aide de la sémantique opérationnelle peut être mémo-
risée sous la forme d'une trace d'exécution, à savoir la suite des états de simulation, estampillés
par le temps de simulation. Une telle trace peut ensuite être analysée pour étudier les propriétés
du système modélisé.

4 Implantation du DSL proposé

Dans cette section, nous décrivons comment nous avons implémenté le DSL décrit concep-
tuellement en Section 3 afin d'obtenir un outillage complet utilisable pour un expert du domaine.
Nous avons utilisé ECLIPSE GEMOC STUDIO <fnref n="4" /> [9, 12], un atelier de création de DSLs basé sur
l'écosystème Eclipse Modeling Framework (EMF) <fnref n="5" />, qui présente plusieurs avantages, notam-
ment celui d'intégrer plusieurs outils compatibles tels que le langage de métamodélisation Ecore,
le framework Xtext permettant de définir une syntaxe concrète textuelle, le framework Sirius
permettant de définir une syntaxe concrète graphique, ou encore le langage de métaprogram-
mation K3 dédié à la définition d'une sémantique opérationnelle. En outre, ECLIPSE GEMOC
STUDIO fournit un ensemble d'outils de support à l'exécution de modèles, en particulier un
débogueur de modèles et un constructeur de traces d'exécutions.

4.1 Syntaxe abstraite et d'un éditeur arborescent de modèles

La syntaxe abstraite du DSL a été implémentée à l'aide du langage de métamodélisation
Ecore. Ce langage permet de définir graphiquement un ensemble de classes, des attributs de
classes, et des liens entre celles-ci, comme les références, la composition ou encore l'héritage. La
FIGURE 1 présentée précédemment montre un extrait du métamodèle du DSL définit à l'aide du
langage graphique Ecore. Une force du langage Ecore est être accompagné de l'environnement

<footnote n="4">4. https://gemoc.org/studio.html</footnote>

<footnote n="5">5. https://eclipse.dev/emf/</footnote>
EMF, qui permet notamment de générer automatiquement une API Java complète permettant de créer, modifier, sauvegarder et charger un modèle conforme au métamodèle considéré. Cette API générée est principalement composée d'une ensemble de classes Java, chacune étant générée à partir d'une classe du métamodèle Ecore. La FIGURE 4 montre un extrait de code généré pour la classe Module. En outre, il est possible de générer à partir du métamodèle un éditeur arborescent permettant d'éditer un modèle sous forme d'arbre. Un modèle peut alors être sérialisé sous forme d'un fichier à l'aide du format standard XMI (basé sur le format XML). La FIGURE 2 présentée précédemment montre un extrait de modèle en cours d'édition dans l'éditeur arborescent généré pour le DSL.

## 4.2 Syntaxe concrète textuelle et d'un éditeur associé

L'éditeur arborescent généré présente des inconvénients, comme celui d'être difficile à utiliser pour de larges modèles, rendant la compréhension du modèle par l'utilisateur difficile. Cette limitation est l'une des raisons pour lesquelles le DSL a été adjoint d'une syntaxe concrète textuelle, dans le but de pouvoir éditeur les modèles directement sous forme de texte (ou, dit autrement, de code).

La syntaxe concrète textuelle du DSL a été implémentée à l'aide du framework Xtext. Cette implémentation prend principalement la forme d'une grammaire écrite à l'aide du langage Xtext, à laquelle est associé un ensemble de modules écrits en Java pour préciser certaines caractéristiques de la syntaxe (la portée des identifiants, etc.) et du fonctionnement de l'éditeur textuel souhaité (autocomplétion, règles de validation de modèles, etc.). Le grand avantage d'Xtext est sa capacité, à partir d'une grammaire, de générer automatiquement non seulement un analyseur syntaxique capable de charger en mémoire un modèle textuel, mais également un éditeur textuel complet de modèles intégré à Eclipse. Un éditeur généré par Xtext vient directement avec une coloration syntaxique, la possibilité de naviguer entre éléments, un plan du code en cours d'édition, et un outil d'autocomplétion.

La FIGURE 3, présentée précédemment, montre un extrait de modèle représenté textuellement à l'aide de la syntaxe concrète, ouvert au sein de l'éditeur de modèle généré à l'aide d'Xtext. On peut voir les mots-clés mis en évidence par la coloration syntaxique.

## 4.3 Sémantique opérationnelle en simulateur de modèles

La sémantique opérationnelle du DSL a été implémentée à l'aide du langage de métaprogrammation K3. Ce programme K3 peut exécuter un modèle conforme à la syntaxe du DSL à l'aide de l'API Java générée précédemment à partir du métamodèle Ecore (voir Section 4.1). Une sémantique K3 se compose d'une opération pour initialiser l'état d'exécution initial d'un modèle (à l'aide d'une annotation `@InitializeModel`), d'une opération principale pour démarrer l'exécution d'un modèle (à l'aide d'une annotation `@Main`), et d'un ensemble d'opérations qui définissent les pas d'exécutions qui font avancer la simulation (à l'aide d'une annotation `@Step`). Ces annotations sont automatiquement reconnues par ECLIPSE GEMOC STUDIO lors de l'exécution d'un modèle, et permettent à l'environnement d'être informé lorsque chaque pas d'exécution se produit. Ce mécanisme (décrit plus en détail dans [10]) permet entre autre à ECLIPSE GEMOC STUDIO de générer automatiquement une trace d'exécution qui capture la séquence d'états atteints par un modèle durant son exécution.

La sémantique opérationnelle du DSL est *in fine* un programme Java qu'on peut ensuite exécuter, dans un framework lié à Eclipse GEMOC Studio.
# 5 Expérimentation de l'outil

Dans cette section, nous décrivons l'étude cas support, sa mise en œuvre dans notre DSL et les premiers résultats de simulation.

## 5.1 Etude de cas

Le système manufacturier considéré ici est imaginaire. Il a été conçu et étudié via le logiciel FlexSim comme détaillé dans la section A.5 de l'annexe web¹. Il est principalement constitué d'une boucle de convoyeurs à accumulation sur laquelle circulent des palettes. Les palettes sont toujours sur le convoyeur, et avacent à vitesse constante de 1m/s. Des bloqueurs sont installés devant les emplacements de travail afin de permettre aux opérations de production de se dérouler dans de bonnes conditions mécaniques. Le premier poste de travail est équipé d'un robot polyarticulé 6 axes. Ce robot prend un par un des produits dans un stock placé à son pied lorsqu'une palette est disponible et arrêtée au poste. Prendre un produit nécessite 5 secondes, le déposer sur la palette 5 secondes supplémentaires. Les produits arrivent dans le stock un par un, séparés par un temps inter-arrivée suivant une loi normale, de moyenne 14.5s et d'écart-type 3s. Le robot place 2 produits sur chaque palette, puis la palette est libérée et avance sur le convoyeur. Au second poste de travail, situé 15m50 après le premier, un opérateur humain prend un produit, puis va le déposer sur une machine de traitement 1 située à 5m du point de prise. La palette est libérée dès que l'opérateur a pris le produit et avance au poste suivant. L'opérateur traite le produit sur la machine, puis vient la déposer sur la palette, qui a donc avancé entre temps. Au troisième poste de travail, situé 6m après le second, un opérateur humain prend le second produit, puis va le déposer sur une machine de traitement 2 située à 5.6m du point de prise. L'opérateur traite le produit sur la machine, puis revient la déposer sur la palette. Lorsque la palette a reçu les 2 produits, elle est libérée et avance au poste suivant. Au quatrième poste de travail, situé 5m10 après le troisième poste, un chariot de transfert vient retirer les 2 produits un par un, et les dépose dans un stock final. L'opération totale dure 18s (arrivée de la palette pleine jusqu'au départ de la palette vide). Lorsque la palette est vide, elle est libérée et retourne au premier poste, situé à 10m du quatrième poste de travail.

## 5.2 Modélisation

Le modèle est défini comme un assemblage de modules $M_i$, chacun disposant de zones $Z_i$ qu'il peut partager via ses connecteurs. La FIGURE 5 met en évidence ces modules et les zones associées; les modules décrivant les postes de travail mais aussi les éléments modulaires du convoyeur à bloqueurs. Notre métamodèle RMS a permis de modéliser le système décrit ci-dessus de la façon suivante : (1) Les 4 palettes sont présentes à l'état initial dans une zone d'un module nommé Source1. (2) Un module Source 2 génère toutes les 14 secondes un nouveau produit. (3) Le convoyeur est divisé en plusieurs modules sur lesquels les palettes transitent. (4) Les postes de travail correspondent à un module composé de 2 zones. Le produit change d'état en passant d'une zone à l'autre. (5) A la fin de leur parcours, les produits atteignent la zone Sink d'un module dédié. Le Listing 1 de l'annexe web¹ donne la représentation textuelle.

## 5.3 Evaluation, traces...

Des logs ont été ajoutés à la sémantique pour nous permettre de vérifier que le comportement du système à l'exécution est bien celui attendu, et ainsi de valider notre modélisation. Ils
<figure><img src="image_5.png" /><figcaption>FIGURE 5 – Modélisation du système de production</figcaption></figure>

seront désactivés dans un environnement de production. Pour chaque pas d'exécution les informations transmises par les logs sont les suivantes : (1) temps du système (exprimé en secondes), (2) déplacement d'un élément (produits ou conteneurs) d'une zone à l'autre, (3) déplacement d'un produit dans ou hors d'un conteneur, (4) modification de l'état d'un produit.

A titre d'exemple, pour les conditions suivantes ((1) durée de simulation = 2500 secondes, (2) génération d'un produit toutes les 14 secondes dans la *source2*, (3) déplacement d'un produit de 20 seconds de la zone Z5b à la zone Z7 et (4) déplacement d'un produit de 10 secondes entre les autres zones), nous obtenons les résultats suivants : (a) 76 produits ont atteint la zone Sink-M9. (b) 96 produits sont en attente dans le stock *Source2-M2*. (c) Le module M5 fonctionne durant 1982 secondes et et M6 1558 secondes. (d) Le temps de traitement des produits ayant l'identifiant 20 est de 140 secondes. C'est le temps mis par ce produit pour quitter la zone *Source2* et atteindre la zone Sink. Ces informations peuvent également être déduites de la lecture du fichier *trace* généré pendant l'exécution grâce au plugin *simple.trace*. S'agissant d'un fichier XMI, il peut être lu par un humain dans l'éditeur d'arbre du *ECLIPSE GEMOC STUDIO*, mais cette tâche est assez complexe, en particulier pour les grandes simulations. Pour une vérification pas à pas du mouvement d'un élément, les journaux sont plus pratiques. Cependant, lorsque le produit logiciel final sera validé et publié, les journaux d'exécution seront désactivés de la sémantique. Le fichier *trace* sera interrogé à l'aide d'un autre DSL appelé TraceDQL [1], ou d'un DSL d'extraction de KPI spécifique qui reste à concevoir, afin de fournir à l'opérateurs l'évaluation de performance de sa simulation.

# 6 Discussion

Dans cette section, nous discutons des apports et limites de la proposition, vis-à-vis d'autres formalismes/outils utilisés dans les SEDs selon le positionnement fixé dans la section 2. Ces outils sont les outils de vérification formelle et les simulateurs à événements discrets, et ont été introduit dans la Section 2.
## 6.1 Comparaison avec les outils de vérification formelle

Pour permettre la vérification du modèle, nous utilisons habituellement des outils puissants pour la dynamique des systèmes tels que Tina [8], Romeo [14], UPPAAL [6] ou SPIN [15]. Nous illustrons ici le cas des Réseaux de Petri (RdP) avec Tina, d'autre exemples sont donnés dans la Section A.3 de l'annexe web¹.

<figure><img src="image_6.png" /><figcaption>FIGURE 6 - Cas d'étude simplifié traité avec Tina</figcaption></figure>

La FIGURE 6 illustre une simulation du cas avec l'outil Tina (le modèle est donné dans la FIGURE 11 de la section A.3 l'annexe web¹). On y retrouve distinctement les 4 postes ainsi que les 5 convoyeurs formant un système circulaire. Chaque convoyeur est représenté par 5 places pour 5 emplacements de palettes, chaque place d'un convoyeur dispose d'une place de garde supplémentaire permettant de limiter le passage des palettes. Cette garde empêche les palettes de se superposer dans le système en créant une file de palettes. Le temps est ajouté à chaque transition indiquant la durée de chaque étape. Tina n'utilisant que le formalisme des jetons simples le flux des palettes sans objets se déroule avec un seul jeton et une fois que deux objets sont sur les palettes ce sont deux jetons qui se déplacent simultanément de place en place. Une fois le modèle réalisé dans Tina, il est possible de vérifier les propriétés du RDP grâce au outils de vérification de Tina. Nous ne détaillons pas ici les résultats, le lecteur pourra consulter la section A.3 de l'annexe web¹.

Concernant la simulation, l'intérêt de Tina par rapport aux autres outils testés est qu'il conserve une horloge globale de simulation pour le temps. Il permet de plus de simuler pas à pas ou globalement. En tenant compte d'une règle aléatoire pour les intervalles de temps, on obtient un temps de simulation, ici on obtient 342 avec 3 palettes et 10 produits.
## 6.2 Comparaison avec un langage de spécification large spectre

Kmelia [2] est un langage permettant de décrire un modèle de composant basé sur la description de services complexes. Les composants Kmelia sont abstraits, indépendants de leur environnement et donc non exécutables. Kmelia peut être utilisé pour modéliser des architectures logicielles et leurs propriétés, ces modèles étant ensuite affinés pour devenir des plates-formes d'exécution. Il peut également servir de modèle commun pour étudier les propriétés des modèles de composants ou de services (abstraction, interopérabilité, composabilité). COSTO est l'outil associé à Kmelia, il a été développé en Java.

Pour l'étude de cas, chaque poste est représenté par un composant Kmelia, dont les services sont les opérations sur les produits. Le convoyeur est un composant muni de services "bloqueurs" pour échanger les palettes et les produits avec les compostants "Postes". Le convoyeur est spécifié par un tableau qui implante la file circulaire. L'ensemble des services étant concurrent, ils sont implantés par des threads et l'état des composants implique des synchronisations pour conserver la cohérence des objets. La multiplication des threads pose des problèmes de blocages lorsque trois postes sont spécifiés. Ces problèmes sont dus à la version actuelle de la sémantique opérationnelle Java dans COSTO, rendant cette approche inexploitable dans l'immédiat. Bien que Kmelia soit plus expressif que la plupart des outils d'analyse formelle mentionnés dans cette section, il reste limité : on a besoin de types de données plus sophistiqués que les ensembles et tableaux pour représenter le comportement fonctionnel. Des détails de la modélisation et de l'évaluation dans COSTO/Kmelia sont donnés dans la section A.4 de l'annexe web¹.

## 6.3 Comparaison avec des simulateurs

Une simulation de ce système a été réalisée avec le logiciel FlexSim 6. Flexsim est un environnement logiciel orienté objet utilisé pour développer, modéliser, simuler, visualiser et contrôler les activités et les systèmes de flux dynamiques [20]. L'environnement Flexsim est complètement intégré au compilateur C++ et utilise flexscript (une bibliothèque C++ précompilée) ou C++ directement. Toutes les animations sont OpenGL et offrent un rendu attractif en 2D ou en 3D. Flexsim a été utilisé pour modéliser des processus de fabrication ou de logistique.

FlexSim fournit une interface graphique conviviale pour décrire les systèmes de fabrication et une simulation visuelle qui sont également très pratiques pour être observés par des utilisateurs non experts parce que des éléments physiques ainsi que la mise en page sont impliqués. En contrepartie, l'effort de modélisation est important et nécessite une solide expérience, en particulier pour la partie relative au contrôle des flux. En outre, le modèle n'est pas modulaire, malgré les possibilités de regroupement, car le flux de contrôle est unique. L'approche DSL permet plusieurs niveaux d'abstraction et d'évolutivité par la composition et l'encapsulation de modules. Les détails de la modélisation et de l'évaluation de FlexSim sont donnés dans la section A.5 de l'annexe web¹.

Nous avons observé des valeurs KPI similaires entre la simulation des paramètres déterministes de FlexSim et les calculs DSL/trace. Bien que l'environnement FlexSim soit beaucoup plus puissant, nous constatons que son usage reste l'apanage de spécialistes et l'investissement beaucoup plus important par rapport à notre DSL.

## 6.4 Complémentarité

Nous ne nous positionnons pas comme des concurrents des outils mentionnées dans cette section, qui sont bien plus puissants et performants. Avec un DSL, le positionnement vise à in-

<footnote n="6">6. https://www.flexsim.com/</footnote>
troduire l'utilisateur final au centre de l'activité, à fournir des fonctions de base suffisantes pour étudier rapidement la performance (KPI) de leurs systèmes. Les concepts sont personnalisés et donc plus facilement appréhendables par l'utilisateur final. Plus exactement, nous suggérons plusieurs langages : un pour les modèles, un pour les performances, un pour les scénarios de simulation, un pour les propriétés, etc. Pour vérifier des propriétés, l'idée, que nous avions déjà développée avec Kmelia [2] pour les propriétés dynamiques et les contrats : les DSL servent de pivot pour traduire vers des outils dédiés selon les propriétés à vérifier. Chaque outils a en effet des capacités à traiter telle ou telle propriété. La transformation vers les réseaux de Petri nous semble assez naturelle (les zones sont des places, les tasks sont des transitions) et permettra de couvrir la vérification formelle de propriétés non couvertes par la simulation. Inversement, une traduction vers FlexSim semble très compliquée car c'est un langage très opérationnel s'appuyant sur des bibliothèques de composants de base spécifiques.

## 7 Conclusion

De nombreux outils existent pour représenter et analyser des systèmes à événements discrets. D'une part, les outils généralistes à base d'automates, de réseaux de Petri ou d'algèbres de processus s'appuient sur des bases formelles pour vérifier les propriétés, ils s'appuient aussi sur la simulation pour les propriétés temporelles. Dans les deux cas, une certaine expérience est nécessaire pour maîtriser la preuve. D'autre part, les outils de simulation à base d'agents, sont plus expressifs mais nécessitent aussi de l'expertise pour décrire la logique et calculer les indicateurs de performance. Nous proposons dans cet article une approche plus légère, dont l'intérêt majeur est de s'adapter au domaine ciblé, notamment pour nommer les concepts du langage. On cible des utilisateurs plus spécialistes du domaines que des techniques de modélisation et de preuve. Nous avons montré comment écrire un tel langage et l'exploiter sur un exemple de système manufacturier de type flow-shop pour en évaluer la performance.

Les perspectives de ce travail sont nombreuses. A court terme, nous devons développer l'expressivité du langage en termes de calculs, mais aussi enrichir la spécification des éléments de simulation pour une exploitation personnalisée via le langage de traces. En particulier, un langage pour décrire les scénarios de simulation est à l'étude. Concernant la vérification formelle, notre vision est celle de la réutilisation des outils performants via des transformations de modèles pour générer les spécifications, par exemple dans les RDP ou les automates, mais surtout d'un langage pour exprimer les propriétés, qui devront elles aussi être transformées pour être exploitables dans les outils mentionnés.

## Références

[1] Hiba Ajabri, Jean-Marie Mottu, Christian Attiogbé, and Pascal Berruet. Navigating the trace of executable domain specific languages through a trace domain query language. In Proceedings of the European Conference on Modelling Foundations and Applications (ECMFA 2025), June 2025.

[2] Pascal Andre, Gilles Ardourel, and Christian Attiogbé. Kmelia: un modèle abstract et formel pour la description et la composition de compo-sants et de services. Revue des Sciences et Technologies de l'Information, 30(6):627-658, 2011.

[3] Pascal André and Olivier Cardin. A core reference model for applicable reconfigurable manufacturing systems. In Theodor Borangiu et al., editor, Proceedings of SOHOMA 2023, volume 1136 of Studies in Computational Intelligence, pages 507-519. Springer, 2023.
[4] Pascal André and Alain Vailly. Conception de systèmes d'information; Panorama des méthodes et des techniques, volume 1 of Collection Technosup. Editions Ellipses, 2001. ISBN 2-7298-0479-X.

[5] Pascal André and Alain Vailly. Spécification des logiciels ; Deux exemples de pratiques récentes : Z et UML, volume 2 of Collection Technosup. Editions Ellipses, 2001. ISBN 2-7298-0774-8.

[6] Johan Bengtsson, Kim Larsen, Fredrik Larsson, Paul Pettersson, and Wang Yi. UPPAAL—a tool suite for automatic verification of real-time systems. Springer, 1996.

[7] Béatrice Bérard, Michel Bidoit, François Laroussinie, Antoine Petit, and Philippe Schnoebelen. Vérification de logiciels : techniques et outils du model-checking. Vuibert Informatique. Vuibert, 1999. ISBN 2-7117-8646-3.

[8] Bernard Berthomieu, P-O Ribet, and François Vernadat. The tool TINA -construction of abstract state spaces for Petri nets and time Petri nets. International journal of production research, 42(14):2741-2756, 2004.

[9] Erwan Bousse, Thomas Degueule, Didier Vojtisek, Tanja Mayerhofer, Julien Deantoni, and Benoit Combemale. Execution framework of the gemoc studio (tool demo). In Proceedings of the 2016 ACM SIGPLAN International Conference on Software Language Engineering, SLE '16, page 84-89. ACM, October 2016.

[10] Erwan Bousse, Thomas Degueule, Didier Vojtisek, Tanja Mayerhofer, Julien Deantoni, and Benoit Combemale. Execution framework of the gemoc studio (tool demo). In Proceedings of the 2016 ACM SIGPLAN International Conference on Software Language Engineering, pages 84-89, 2016.

[11] G. Chrysolouris. Manufacturing Systems : Theory and Practice. Mechanical Engineering Series. Springer, 2006.

[12] Benoit Combemale, Olivier Barais, and Andreas Wortmann. Language engineering with the gemoc studio. In 2017 IEEE International Conference on Software Architecture Workshops (ICSAW), pages 189-191. IEEE, 2017.

[13] Hubert Garavel, Frédéric Lang, Radu Mateescu, and Wendelin Serwe. CADP 2010 : A toolbox for the construction and analysis of distributed processes. In International conference on tools and algorithms for the construction and analysis of systems, pages 372-387. Springer, 2011.

[14] Guillaume Gardey, Didier Lime, Morgan Magnin, and Olivier Roux. Romeo : A tool for analyzing time Petri nets. In International Conference on Computer Aided Verification, pages 418-423. Springer, 2005.

[15] Gerard J Holzmann. The SPIN model checker : Primer and reference manual, volume 1003. Addison-Wesley Reading, 2004.

[16] R. Husson, C. Iung, J.F. Aubry, J. Daafouz, and D. Wolf. Automatique : Du cahier des charges à la réalisation de systèmes. EEA. Dunod, 2017.

[17] Mario Jadrić, Maja Ćukušić, and Antonia Bralić. Comparison of discrete event simulation tools in an academic environment. Croatian Operational Research Review, 5(2):203-219, December 2014.

[18] Kassu Jilcha, Esheitie Berhan, and Hannan Sherif. Workers and machine performance modeling in manufacturing system using arena simulation. Journal of Computer Science & Systems Biology, 8(4):185-190, 2015.

[19] Yoram Koren, Xi Gu, and Weihong Guo. Reconfigurable manufacturing systems : Principles, design, and future trends. Frontiers of Mechanical Engineering, 13(2):121-136, November 2017.

[20] W.B. Nordgren. Flexsim simulation environment. In Proceedings of the Winter Simulation Conference, volume 1, pages 250-252 vol.1, 2002.

[21] Anne Vinter et al. Ratzer. CPN tools for editing, simulating, and analysing coloured Petri nets. In International conference on application and theory of petri nets, pages 450-462. Springer, 2003.

[22] A.P. Sage. Systems Engineering. Wiley Series in Systems Engineering and Management. Wiley, 1992.

[23] António Vieira, Luís Dias, Guilherme Pereira, and José A Oliveira. Comparison of simio and arena simulation tools, 2014.
# A Annexe en ligne

## A.1 Métamodèle du DSL

Une première version du métamodèle est proposée dans [3], Elle couvre de nombreux concepts pour les systèmes de production, au delà de la seule modélisation ; elle est donc qualifiée de *modèle de référence*. Elle est relativement complète et ouverte et peut servir de modèle d'implantation dans différents langages et outils, au delà de la seule étape de modélisation.

La version décrite ici est celle mise en oeuvre par le DSL, est donc plus réduite. Nous décrivons le métamodèle du DSL en deux parties : (i) la partie syntaxe abstraite (*model*) décrit les éléments du langage et leurs relation, (ii) la partie exécution (*runtime*) introduit des éléments utiles à la sémantique du langage, opérationalisée dans l'implantation de la section 4. Dans la suite, nous exposons ces deux parties.

La FIGURE 7 illustre la version actuelle du métamodèle DSL. Le langage spécifique au domaine (DSL) proposé pour les systèmes de fabrication reconfigurables (RMS) est composé de trois parties interconnectées : un structurel pour modéliser les configurations du système, un comportemental pour spécifier la logique interne des modules, et un temps d'exécution qui prend en charge la simulation et le traçage de l'exécution. Chaque partie aborde un aspect distinct de la conception des systèmes de fabrication reconfigurables et, ensemble, elles constituent un cadre de simulation exécutable précoce pour les systèmes de fabrication modulaires complexes.

<figure><img src="image_7.png" /><figcaption>FIGURE 7 – Métamodèle comprenant à la fois la syntaxe abstraite du DSL (à gauche), et la définition de l'état de simulation de la sémantique opérationnelle du DSL (à droite)</figcaption></figure>
### A.1.1 Structure

La partie structurelle du DSL capture les principaux concepts d'une configuration RMS (cf. FIGURE 8). Au cœur du DSL se trouve le `ProductionSystem`, qui encapsule une configura-

<figure><img src="image_8.png" /><figcaption>FIGURE 8 – Métamodèle du DSL proposé – Zoom sur les concepts structurels de la Figure 7</figcaption></figure>

tion complète du système de fabrication. Il comprend un ensemble d'éléments `Module` instanciés, une collection d'éléments `ProductType` et `ContainerType` disponibles, ainsi qu'une référence aux modèles comportementaux et d'exécution correspondants. Chaque `Module` est défini sur la base d'un `ModuleType`, qui spécifie ses rôles fonctionnels et ses ports structurels. Les éléments `ModuleType` peuvent contenir divers composants `Zone` qui servent de points génériques, ainsi que des interfaces explicites `Provide` et `Require`, prenant en charge une architecture basée sur les composants. Les modules sont interconnectés par des éléments `Binding`, qui relient l'interface `Provide` d'un module à l'interface `Require` d'un autre, ce qui permet la reconfigurabilité et la variabilité structurelle de la chaîne de production. En outre, les connexions définies entre les modules déterminent les transitions valides des instances de `ProductType` dans l'ensemble du système. Les produits peuvent également être regroupés ou manipulés par l'intermédiaire d'éléments `ContainerType`, représentant des moyens physiques tels que des palettes ou des conteneurs.

### A.1.2 Comportement dynamique et fonctionnel

La partie comportementale du DSL capture la dynamique interne de l'exécution du module par le biais d'un modèle de processus orienté tâches (cf. FIGURE 9). Chaque `ModuleType` peut faire référence à un `Comportement` correspondant, qui est défini comme une collection d'éléments `TaskRule`. Une `TaskRule` spécifie une unité de logique d'exécution, y compris les conditions dans lesquelles la règle est déclenchée et les actions à effectuer. Le contrôle de l'exécution entre les
<figure><img src="image_9.png" /><figcaption>FIGURE 9 – Métamodèle du DSL proposé – Zoom sur les concepts comportementaux de la Figure 7</figcaption></figure>

tâches est géré par un séquençage explicite, où les instances de *TaskRule* peuvent faire référence
à des règles ultérieures par le biais de liens régis par *Preconditions*. Une *Precondition* définit les
conditions logiques qui doivent être remplies pour que la règle de tâche correspondante soit
éligible à l'exécution. Chaque *TaskRule* encapsule une ou plusieurs actions qui définissent la
sémantique opérationnelle du comportement. Le DSL prend en charge une variété d'actions
spécifiques au domaine qui permettent de modéliser des comportements tels que la création de
produits, le mouvement et la reconfiguration structurelle. Ce modèle comportemental permet
aux concepteurs de définir le fonctionnement attendu de chaque module de manière modulaire
et réutilisable, en s'abstrayant des détails procéduraux de bas niveau tout en préservant la
sémantique d'exécution logique nécessaire à l'efficacité du système.

### A.1.3 Système à l'exécution

Pour mettre en œuvre l'exécution et la simulation, le métamodèle du DSL comprend une
partie d'exécution dédiée qui capture l'état évolutif du système (cf. FIGURE 10).

L'élément central, *ProductionSystemSimulation*, maintient le contexte de simulation, y compris le système actif actuel et le temps de simulation. Le système simulé contient des instances dynamiques d'entités telles que *Product*, *Container*, *ModuleState*, and *ZoneState*, reflétant les emplacements des éléments de configuration, les états des tâches et les conditions internes des modules. Le comportement d'exécution est représenté par des instances *Task*, qui suivent des attributs tels que *startTime*, les comportements associés et l'état d'exécution (par exemple, *OFF*, *ON*). Ces tâches rendent opérationnelles les définitions comportementales du niveau du type. L'inclusion du *ZoneState* permet un suivi détaillé du placement des éléments dans les modules, ce qui permet à la simulation de faire la distinction entre les sous-régions ou les tampons. Ce modèle d'exécution prend en charge la simulation précise et progressive du comportement du RMS, en donnant un aperçu de la dynamique de reconfiguration et en permettant le débogage, la traçabilité et l'analyse des performances.
<figure><img src="image_10.png" /><figcaption>FIGURE 10 – Métamodèle du DSL proposé – Zoom sur la définition de l'état de simulation de la Figure 7</figcaption></figure>

## A.2 Spécification textuelle du cas d'étude avec le DSL

Listing 1 donne un exemple de système manufacturier complet modélisé à l'aide du DSL proposé, représenté à l'aide de la syntaxe concrète textuelle.

Listing 1 – Exemple de système manufacturier complet modélisé à l'aide du DSL proposé, représenté à l'aide de la syntaxe concrète textuelle

```
ProductionSystem {
```

```
simulationDuration 2500
```

```
bindings {
```

```
Binding {
```

```
require "M1.ReqNewPlt"
```

```
provide "MS1.PrdNewPlt"
```

1

2

6

8
<table>
  <tbody>
    <tr>
      <td>9</td>
      <td>} ,</td>
      <td>62</td>
      <td>}</td>
    </tr>
    <tr>
      <td>10</td>
      <td>Binding {</td>
      <td>63</td>
      <td>}</td>
    </tr>
    <tr>
      <td>11</td>
      <td>require "M3.ReqEmptyPlt"</td>
      <td>64</td>
      <td>} ,</td>
    </tr>
    <tr>
      <td>12</td>
      <td>provide "M1.PrdEmptyPlt"</td>
      <td>65</td>
      <td>Module M1 {</td>
    </tr>
    <tr>
      <td>13</td>
      <td>}</td>
      <td>66</td>
      <td>type M1Type</td>
    </tr>
    <tr>
      <td>14</td>
      <td>Binding {</td>
      <td>67</td>
      <td>provides {</td>
    </tr>
    <tr>
      <td>15</td>
      <td>require "M3.ReqNewCp"</td>
      <td>68</td>
      <td>Provide PrdEmptyPlt {</td>
    </tr>
    <tr>
      <td>16</td>
      <td>provide "M2.PrdNewCp"</td>
      <td>69</td>
      <td>providetype "M1Type.PrdEmptyPlt"</td>
    </tr>
    <tr>
      <td>17</td>
      <td>} ,</td>
      <td>70</td>
      <td>}</td>
    </tr>
    <tr>
      <td>18</td>
      <td>Binding {</td>
      <td>71</td>
      <td>}</td>
    </tr>
    <tr>
      <td>19</td>
      <td>require "M4.ReqPlt"</td>
      <td>72</td>
      <td>requires {</td>
    </tr>
    <tr>
      <td>20</td>
      <td>provide "M3.PrdPlt"</td>
      <td>73</td>
      <td>Require ReqNewPlt {</td>
    </tr>
    <tr>
      <td>21</td>
      <td>}</td>
      <td>74</td>
      <td>requiretype "M1Type.ReqNewPlt"</td>
    </tr>
    <tr>
      <td>22</td>
      <td>Binding {</td>
      <td>75</td>
      <td>},</td>
    </tr>
    <tr>
      <td>23</td>
      <td>require "M5.ReqCp"</td>
      <td>76</td>
      <td>Require ReqEmptyPlt {</td>
    </tr>
    <tr>
      <td>24</td>
      <td>provide "M4.PrdCp"</td>
      <td>77</td>
      <td>requiretype "M1Type.ReqEmptyPlt"</td>
    </tr>
    <tr>
      <td>25</td>
      <td>}</td>
      <td>78</td>
      <td>}</td>
    </tr>
    <tr>
      <td>26</td>
      <td>Binding {</td>
      <td>79</td>
      <td>}</td>
    </tr>
    <tr>
      <td>27</td>
      <td>require "M7.ReqPlt1Cp"</td>
      <td>80</td>
      <td>} ,</td>
    </tr>
    <tr>
      <td>28</td>
      <td>provide "M4.PrdPlt1Cp"</td>
      <td>81</td>
      <td>Module M2 {</td>
    </tr>
    <tr>
      <td>29</td>
      <td>}</td>
      <td>82</td>
      <td>type M2Type</td>
    </tr>
    <tr>
      <td>30</td>
      <td>Binding {</td>
      <td>83</td>
      <td>provides {</td>
    </tr>
    <tr>
      <td>31</td>
      <td>require "M7.ReqCpFromM5"</td>
      <td>84</td>
      <td>Provide PrdNewCp {</td>
    </tr>
    <tr>
      <td>32</td>
      <td>provide "M5.PrdCp"</td>
      <td>85</td>
      <td>providetype "M2Type.PrdNewCp"</td>
    </tr>
    <tr>
      <td>33</td>
      <td>}</td>
      <td>86</td>
      <td>}</td>
    </tr>
    <tr>
      <td>34</td>
      <td>Binding {</td>
      <td>87</td>
      <td>}</td>
    </tr>
    <tr>
      <td>35</td>
      <td>require "M7.ReqCpFromM6"</td>
      <td>88</td>
      <td>} ,</td>
    </tr>
    <tr>
      <td>36</td>
      <td>provide "M6.PrdCp"</td>
      <td>89</td>
      <td>Module M3 {</td>
    </tr>
    <tr>
      <td>37</td>
      <td>}</td>
      <td>90</td>
      <td>type M3Type</td>
    </tr>
    <tr>
      <td>38</td>
      <td>Binding {</td>
      <td>91</td>
      <td>provides {</td>
    </tr>
    <tr>
      <td>39</td>
      <td>require "M6.ReqCp"</td>
      <td>92</td>
      <td>Provide PrdPlt {</td>
    </tr>
    <tr>
      <td>40</td>
      <td>provide "M7.PrdCp"</td>
      <td>93</td>
      <td>providetype "M3Type.PrdPlt"</td>
    </tr>
    <tr>
      <td>41</td>
      <td>}</td>
      <td>94</td>
      <td>}</td>
    </tr>
    <tr>
      <td>42</td>
      <td>Binding {</td>
      <td>95</td>
      <td>}</td>
    </tr>
    <tr>
      <td>43</td>
      <td>require "M8.ReqPlt"</td>
      <td>96</td>
      <td>requires {</td>
    </tr>
    <tr>
      <td>44</td>
      <td>provide "M7.PrdPlt"</td>
      <td>97</td>
      <td>Require ReqEmptyPlt {</td>
    </tr>
    <tr>
      <td>45</td>
      <td>} ,</td>
      <td>98</td>
      <td>requiretype "M3Type.ReqEmptyPlt"</td>
    </tr>
    <tr>
      <td>46</td>
      <td>Binding {</td>
      <td>99</td>
      <td>},</td>
    </tr>
    <tr>
      <td>47</td>
      <td>require "M1.ReqEmptyPlt"</td>
      <td>100</td>
      <td>Require ReqNewCp {</td>
    </tr>
    <tr>
      <td>48</td>
      <td>provide "M8.PrdEmptyPlt"</td>
      <td>101</td>
      <td>requiretype "M3Type.ReqNewCp"</td>
    </tr>
    <tr>
      <td>49</td>
      <td>}</td>
      <td>102</td>
      <td>}</td>
    </tr>
    <tr>
      <td>50</td>
      <td>Binding {</td>
      <td>103</td>
      <td>}</td>
    </tr>
    <tr>
      <td>51</td>
      <td>require "M9.ReqCp"</td>
      <td>104</td>
      <td>} ,</td>
    </tr>
    <tr>
      <td>52</td>
      <td>provide "M8.PrdCp"</td>
      <td>105</td>
      <td>Module M4 {</td>
    </tr>
    <tr>
      <td>53</td>
      <td>}</td>
      <td>106</td>
      <td>type M4Type</td>
    </tr>
    <tr>
      <td>54</td>
      <td>}</td>
      <td>107</td>
      <td>provides {</td>
    </tr>
    <tr>
      <td>55</td>
      <td>modules {</td>
      <td>108</td>
      <td>Provide PrdCp {</td>
    </tr>
    <tr>
      <td>56</td>
      <td>Module MS1 {</td>
      <td>109</td>
      <td>providetype "M4Type.PrdCp"</td>
    </tr>
    <tr>
      <td>57</td>
      <td>type MS1Type</td>
      <td>110</td>
      <td>},</td>
    </tr>
    <tr>
      <td>58</td>
      <td>provides {</td>
      <td>111</td>
      <td>Provide PrdPlt1Cp {</td>
    </tr>
    <tr>
      <td>59</td>
      <td></td>
      <td>112</td>
      <td>providetype "M4Type.PrdPlt1Cp"</td>
    </tr>
    <tr>
      <td>60</td>
      <td>Provide PrdNewPlt {</td>
      <td>113</td>
      <td>}</td>
    </tr>
    <tr>
      <td>61</td>
      <td>providetype "MS1Type.PrdNewPlt"</td>
      <td>114</td>
      <td>}</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>115</td>
      <td>requires {</td>
      <td>168</td>
      <td>} ,</td>
    </tr>
    <tr>
      <td>116</td>
      <td>Require ReqPlt {</td>
      <td>169</td>
      <td>Module M8 {</td>
    </tr>
    <tr>
      <td>117</td>
      <td>requiretype "M4Type.ReqPlt"</td>
      <td>170</td>
      <td>type M8Type</td>
    </tr>
    <tr>
      <td>118</td>
      <td>}</td>
      <td>171</td>
      <td>provides {</td>
    </tr>
    <tr>
      <td>119</td>
      <td>}</td>
      <td>172</td>
      <td>Provide PrdEmptyPlt {</td>
    </tr>
    <tr>
      <td>120</td>
      <td>}</td>
      <td>173</td>
      <td>providetype "M8Type.PrdEmptyPlt"</td>
    </tr>
    <tr>
      <td>121</td>
      <td>Module M5 {</td>
      <td>174</td>
      <td>}</td>
    </tr>
    <tr>
      <td>122</td>
      <td>type M5Type</td>
      <td>175</td>
      <td>Provide PrdCp {</td>
    </tr>
    <tr>
      <td>123</td>
      <td>provides {</td>
      <td>176</td>
      <td>providetype "M8Type.PrdCp"</td>
    </tr>
    <tr>
      <td>124</td>
      <td>Provide PrdCp {</td>
      <td>177</td>
      <td>}</td>
    </tr>
    <tr>
      <td>125</td>
      <td>providetype "M5Type.PrdCp"</td>
      <td>178</td>
      <td>}</td>
    </tr>
    <tr>
      <td>126</td>
      <td>}</td>
      <td>179</td>
      <td>requires {</td>
    </tr>
    <tr>
      <td>127</td>
      <td>}</td>
      <td>180</td>
      <td>Require ReqPlt {</td>
    </tr>
    <tr>
      <td>128</td>
      <td>requires {</td>
      <td>181</td>
      <td>requiretype "M8Type.ReqPlt"</td>
    </tr>
    <tr>
      <td>129</td>
      <td>Require ReqCp {</td>
      <td>182</td>
      <td>}</td>
    </tr>
    <tr>
      <td>130</td>
      <td>requiretype "M5Type.ReqCp"</td>
      <td>183</td>
      <td>}</td>
    </tr>
    <tr>
      <td>131</td>
      <td>}</td>
      <td>184</td>
      <td>} ,</td>
    </tr>
    <tr>
      <td>132</td>
      <td>}</td>
      <td>185</td>
      <td>Module M9 {</td>
    </tr>
    <tr>
      <td>133</td>
      <td>}</td>
      <td>186</td>
      <td>type M9Type</td>
    </tr>
    <tr>
      <td>134</td>
      <td>Module M6 {</td>
      <td>187</td>
      <td>requires {</td>
    </tr>
    <tr>
      <td>135</td>
      <td>type M6Type</td>
      <td>188</td>
      <td>Require ReqCp {</td>
    </tr>
    <tr>
      <td>136</td>
      <td>provides {</td>
      <td>189</td>
      <td>requiretype "M9Type.ReqCp"</td>
    </tr>
    <tr>
      <td>137</td>
      <td>Provide PrdCp {</td>
      <td>190</td>
      <td>}</td>
    </tr>
    <tr>
      <td>138</td>
      <td>providetype "M6Type.PrdCp"</td>
      <td>191</td>
      <td>}</td>
    </tr>
    <tr>
      <td>139</td>
      <td>}</td>
      <td>192</td>
      <td>}</td>
    </tr>
    <tr>
      <td>140</td>
      <td>}</td>
      <td>193</td>
      <td>}</td>
    </tr>
    <tr>
      <td>141</td>
      <td>requires {</td>
      <td>194</td>
      <td></td>
    </tr>
    <tr>
      <td>142</td>
      <td>Require ReqCp {</td>
      <td>195</td>
      <td>moduletypes {</td>
    </tr>
    <tr>
      <td>143</td>
      <td>requiretype "M6Type.ReqCp"</td>
      <td>196</td>
      <td>ModuleType MS1Type {</td>
    </tr>
    <tr>
      <td>144</td>
      <td>}</td>
      <td>197</td>
      <td>behavior Behavior {</td>
    </tr>
    <tr>
      <td>145</td>
      <td>}</td>
      <td>198</td>
      <td></td>
    </tr>
    <tr>
      <td>146</td>
      <td>}</td>
      <td>199</td>
      <td></td>
    </tr>
    <tr>
      <td>147</td>
      <td>Module M7 {</td>
      <td>200</td>
      <td>zones {</td>
    </tr>
    <tr>
      <td>148</td>
      <td>type M7Type</td>
      <td>201</td>
      <td>Zone "Source1"</td>
    </tr>
    <tr>
      <td>149</td>
      <td>provides {</td>
      <td>202</td>
      <td>}</td>
    </tr>
    <tr>
      <td>150</td>
      <td>Provide PrdCp {</td>
      <td>203</td>
      <td>provides {</td>
    </tr>
    <tr>
      <td>151</td>
      <td>providetype "M7Type.PrdCp"</td>
      <td>204</td>
      <td>ProvideType PrdNewPlt {</td>
    </tr>
    <tr>
      <td>152</td>
      <td>}</td>
      <td>205</td>
      <td>zone "Source1"</td>
    </tr>
    <tr>
      <td>153</td>
      <td>Provide PrdPlt {</td>
      <td>206</td>
      <td>}</td>
    </tr>
    <tr>
      <td>154</td>
      <td>providetype "M7Type.PrdPlt"</td>
      <td>207</td>
      <td></td>
    </tr>
    <tr>
      <td>155</td>
      <td>}</td>
      <td>208</td>
      <td>initialelementsets {</td>
    </tr>
    <tr>
      <td>156</td>
      <td>}</td>
      <td>209</td>
      <td>InitialElementSet {</td>
    </tr>
    <tr>
      <td>157</td>
      <td>requires {</td>
      <td>210</td>
      <td>stock 4</td>
    </tr>
    <tr>
      <td>158</td>
      <td>Require ReqPlt1Cp {</td>
      <td>211</td>
      <td>elementtype "Pallet"</td>
    </tr>
    <tr>
      <td>159</td>
      <td>requiretype "M7Type.ReqPlt1Cp"</td>
      <td>212</td>
      <td>zone "Source1"</td>
    </tr>
    <tr>
      <td>160</td>
      <td>}</td>
      <td>213</td>
      <td></td>
    </tr>
    <tr>
      <td>161</td>
      <td>Require ReqCpFromM5 {</td>
      <td>214</td>
      <td></td>
    </tr>
    <tr>
      <td>162</td>
      <td>requiretype "M7Type.ReqCpFromM5"</td>
      <td>215</td>
      <td></td>
    </tr>
    <tr>
      <td>163</td>
      <td>}</td>
      <td>216</td>
      <td>ModuleType M1Type {</td>
    </tr>
    <tr>
      <td>164</td>
      <td>Require ReqCpFromM6 {</td>
      <td>217</td>
      <td>behavior Behavior {</td>
    </tr>
    <tr>
      <td>165</td>
      <td>requiretype "M7Type.ReqCpFromM6"</td>
      <td>218</td>
      <td>taskrules {</td>
    </tr>
    <tr>
      <td>166</td>
      <td>}</td>
      <td>219</td>
      <td>TaskRule {</td>
    </tr>
    <tr>
      <td>167</td>
      <td>}</td>
      <td>220</td>
      <td>preconditions {</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>327</td>
      <td>}</td>
      <td>380</td>
      <td>Zone "Z3"</td>
    </tr>
    <tr>
      <td>328</td>
      <td>action Take {</td>
      <td>381</td>
      <td>}</td>
    </tr>
    <tr>
      <td>329</td>
      <td>duration 10</td>
      <td>382</td>
      <td>provides {</td>
    </tr>
    <tr>
      <td>330</td>
      <td>output {</td>
      <td>383</td>
      <td>ProvideType PrdPlt {</td>
    </tr>
    <tr>
      <td>331</td>
      <td>location "Z3"</td>
      <td>384</td>
      <td>zone "Z3"</td>
    </tr>
    <tr>
      <td>332</td>
      <td>elementtype "Pallet"</td>
      <td>385</td>
      <td>}</td>
    </tr>
    <tr>
      <td>333</td>
      <td>}</td>
      <td>386</td>
      <td>}</td>
    </tr>
    <tr>
      <td>334</td>
      <td>input {</td>
      <td>387</td>
      <td>requires {</td>
    </tr>
    <tr>
      <td>335</td>
      <td>location ReqEmptyPlt</td>
      <td>388</td>
      <td>RequireType ReqEmptyPlt,</td>
    </tr>
    <tr>
      <td>336</td>
      <td>elementtype "Pallet"</td>
      <td>389</td>
      <td>RequireType ReqNewCp</td>
    </tr>
    <tr>
      <td>337</td>
      <td>}</td>
      <td>390</td>
      <td>}</td>
    </tr>
    <tr>
      <td>338</td>
      <td>}</td>
      <td>391</td>
      <td>},</td>
    </tr>
    <tr>
      <td>339</td>
      <td>},</td>
      <td>392</td>
      <td>ModuleType M4Type {</td>
    </tr>
    <tr>
      <td>340</td>
      <td>TaskRule {</td>
      <td>393</td>
      <td>behavior Behavior {</td>
    </tr>
    <tr>
      <td>341</td>
      <td>preconditions {</td>
      <td>394</td>
      <td>taskrules {</td>
    </tr>
    <tr>
      <td>342</td>
      <td>Precondition {</td>
      <td>395</td>
      <td>TaskRule {</td>
    </tr>
    <tr>
      <td>343</td>
      <td>minimumQuantity 0</td>
      <td>396</td>
      <td>preconditions {</td>
    </tr>
    <tr>
      <td>344</td>
      <td>maximumQuantity 1</td>
      <td>397</td>
      <td>Precondition {</td>
    </tr>
    <tr>
      <td>345</td>
      <td>possibleelement {</td>
      <td>398</td>
      <td>minimumQuantity 2</td>
    </tr>
    <tr>
      <td>346</td>
      <td>state initial</td>
      <td>399</td>
      <td>maximumQuantity 2</td>
    </tr>
    <tr>
      <td>347</td>
      <td>location "Z3"</td>
      <td>400</td>
      <td>possibleelement {</td>
    </tr>
    <tr>
      <td>348</td>
      <td>elementtype "Component"</td>
      <td>401</td>
      <td>state initial</td>
    </tr>
    <tr>
      <td>349</td>
      <td>containertype "Pallet"</td>
      <td>402</td>
      <td>location ReqPlt</td>
    </tr>
    <tr>
      <td>350</td>
      <td>}</td>
      <td>403</td>
      <td>elementtype "Component"</td>
    </tr>
    <tr>
      <td>351</td>
      <td>},</td>
      <td>404</td>
      <td>containertype "Pallet"</td>
    </tr>
    <tr>
      <td>352</td>
      <td>Precondition {</td>
      <td>405</td>
      <td>}</td>
    </tr>
    <tr>
      <td>353</td>
      <td>minimumQuantity 1</td>
      <td>406</td>
      <td>},</td>
    </tr>
    <tr>
      <td>354</td>
      <td>maximumQuantity 10000</td>
      <td>407</td>
      <td>Precondition {</td>
    </tr>
    <tr>
      <td>355</td>
      <td>possibleelement {</td>
      <td>408</td>
      <td>minimumQuantity 0</td>
    </tr>
    <tr>
      <td>356</td>
      <td>state initial</td>
      <td>409</td>
      <td>maximumQuantity 0</td>
    </tr>
    <tr>
      <td>357</td>
      <td>location ReqNewCp</td>
      <td>410</td>
      <td>possibleelement {</td>
    </tr>
    <tr>
      <td>358</td>
      <td>elementtype "Component"</td>
      <td>411</td>
      <td>location "Z4"</td>
    </tr>
    <tr>
      <td>359</td>
      <td>}</td>
      <td>412</td>
      <td>elementtype "Pallet"</td>
    </tr>
    <tr>
      <td>360</td>
      <td>}</td>
      <td>413</td>
      <td>}</td>
    </tr>
    <tr>
      <td>361</td>
      <td>}</td>
      <td>414</td>
      <td>}</td>
    </tr>
    <tr>
      <td>362</td>
      <td>action Take {</td>
      <td>415</td>
      <td>}</td>
    </tr>
    <tr>
      <td>363</td>
      <td>duration 10</td>
      <td>416</td>
      <td>action Take {</td>
    </tr>
    <tr>
      <td>364</td>
      <td>output {</td>
      <td>417</td>
      <td>duration 10</td>
    </tr>
    <tr>
      <td>365</td>
      <td>state initial</td>
      <td>418</td>
      <td>output {</td>
    </tr>
    <tr>
      <td>366</td>
      <td>location "Z3"</td>
      <td>419</td>
      <td>location "Z4"</td>
    </tr>
    <tr>
      <td>367</td>
      <td>elementtype "Component"</td>
      <td>420</td>
      <td>elementtype "Pallet"</td>
    </tr>
    <tr>
      <td>368</td>
      <td>containertype "Pallet"</td>
      <td>421</td>
      <td>}</td>
    </tr>
    <tr>
      <td>369</td>
      <td>}</td>
      <td>422</td>
      <td>input {</td>
    </tr>
    <tr>
      <td>370</td>
      <td>input {</td>
      <td>423</td>
      <td>location ReqPlt</td>
    </tr>
    <tr>
      <td>371</td>
      <td>state initial</td>
      <td>424</td>
      <td>elementtype "Pallet"</td>
    </tr>
    <tr>
      <td>372</td>
      <td>location ReqNewCp</td>
      <td>425</td>
      <td>}</td>
    </tr>
    <tr>
      <td>373</td>
      <td>elementtype "Component"</td>
      <td>426</td>
      <td>}</td>
    </tr>
    <tr>
      <td>374</td>
      <td>}</td>
      <td>427</td>
      <td>}</td>
    </tr>
    <tr>
      <td>375</td>
      <td>}</td>
      <td>428</td>
      <td>}</td>
    </tr>
    <tr>
      <td>376</td>
      <td>}</td>
      <td>429</td>
      <td>}</td>
    </tr>
    <tr>
      <td>377</td>
      <td>}</td>
      <td>430</td>
      <td>zones {</td>
    </tr>
    <tr>
      <td>378</td>
      <td>}</td>
      <td>431</td>
      <td>Zone "Z4"</td>
    </tr>
    <tr>
      <td>379</td>
      <td>zones {</td>
      <td>432</td>
      <td>}</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>433</td>
      <td>provides {</td>
      <td>486</td>
      <td>}</td>
    </tr>
    <tr>
      <td>434</td>
      <td>ProvideType PrdCp {</td>
      <td>487</td>
      <td>}</td>
    </tr>
    <tr>
      <td>435</td>
      <td>zone "Z4"</td>
      <td>488</td>
      <td>action Take {</td>
    </tr>
    <tr>
      <td>436</td>
      <td>,</td>
      <td>489</td>
      <td>duration 40</td>
    </tr>
    <tr>
      <td>437</td>
      <td>ProvideType PrdPlt1Cp {</td>
      <td>490</td>
      <td>output {</td>
    </tr>
    <tr>
      <td>438</td>
      <td>zone "Z4"</td>
      <td>491</td>
      <td>state completed</td>
    </tr>
    <tr>
      <td>439</td>
      <td>}</td>
      <td>492</td>
      <td>location "Z5b"</td>
    </tr>
    <tr>
      <td>440</td>
      <td>}</td>
      <td>493</td>
      <td>elementtype "Component"</td>
    </tr>
    <tr>
      <td>441</td>
      <td>requires {</td>
      <td>494</td>
      <td>}</td>
    </tr>
    <tr>
      <td>442</td>
      <td>RequireType ReqPlt</td>
      <td>495</td>
      <td>input {</td>
    </tr>
    <tr>
      <td>443</td>
      <td>}</td>
      <td>496</td>
      <td>state initial</td>
    </tr>
    <tr>
      <td>444</td>
      <td>}</td>
      <td>497</td>
      <td>location "Z5a"</td>
    </tr>
    <tr>
      <td>445</td>
      <td>ModuleType M5Type {</td>
      <td>498</td>
      <td>elementtype "Component"</td>
    </tr>
    <tr>
      <td>446</td>
      <td>behavior Behavior {</td>
      <td>499</td>
      <td>}</td>
    </tr>
    <tr>
      <td>447</td>
      <td>taskrules {</td>
      <td>500</td>
      <td>}</td>
    </tr>
    <tr>
      <td>448</td>
      <td>TaskRule {</td>
      <td>501</td>
      <td>}</td>
    </tr>
    <tr>
      <td>449</td>
      <td>preconditions {</td>
      <td>502</td>
      <td>}</td>
    </tr>
    <tr>
      <td>450</td>
      <td>Precondition {</td>
      <td>503</td>
      <td>}</td>
    </tr>
    <tr>
      <td>451</td>
      <td>minimumQuantity 2</td>
      <td>504</td>
      <td>zones {</td>
    </tr>
    <tr>
      <td>452</td>
      <td>maximumQuantity 2</td>
      <td>505</td>
      <td>Zone "Z5a",</td>
    </tr>
    <tr>
      <td>453</td>
      <td>possibleelement {</td>
      <td>506</td>
      <td>Zone "Z5b"</td>
    </tr>
    <tr>
      <td>454</td>
      <td>state initial</td>
      <td>507</td>
      <td>}</td>
    </tr>
    <tr>
      <td>455</td>
      <td>location ReqCp</td>
      <td>508</td>
      <td>provides {</td>
    </tr>
    <tr>
      <td>456</td>
      <td>elementtype "Component"</td>
      <td>509</td>
      <td>ProvideType PrdCp {</td>
    </tr>
    <tr>
      <td>457</td>
      <td>containertype "Pallet"</td>
      <td>510</td>
      <td>zone "Z5b"</td>
    </tr>
    <tr>
      <td>458</td>
      <td>}</td>
      <td>511</td>
      <td>}</td>
    </tr>
    <tr>
      <td>459</td>
      <td>}</td>
      <td>512</td>
      <td>}</td>
    </tr>
    <tr>
      <td>460</td>
      <td>}</td>
      <td>513</td>
      <td>requires {</td>
    </tr>
    <tr>
      <td>461</td>
      <td>action Take {</td>
      <td>514</td>
      <td>RequireType ReqCp</td>
    </tr>
    <tr>
      <td>462</td>
      <td>duration 10</td>
      <td>515</td>
      <td>}</td>
    </tr>
    <tr>
      <td>463</td>
      <td>output {</td>
      <td>516</td>
      <td>,</td>
    </tr>
    <tr>
      <td>464</td>
      <td>state initial</td>
      <td>517</td>
      <td>ModuleType M6Type {</td>
    </tr>
    <tr>
      <td>465</td>
      <td>location "Z5a"</td>
      <td>518</td>
      <td>behavior Behavior {</td>
    </tr>
    <tr>
      <td>466</td>
      <td>elementtype "Component"</td>
      <td>519</td>
      <td>taskrules {</td>
    </tr>
    <tr>
      <td>467</td>
      <td>}</td>
      <td>520</td>
      <td>TaskRule {</td>
    </tr>
    <tr>
      <td>468</td>
      <td>input {</td>
      <td>521</td>
      <td>preconditions {</td>
    </tr>
    <tr>
      <td>469</td>
      <td>state initial</td>
      <td>522</td>
      <td>Precondition {</td>
    </tr>
    <tr>
      <td>470</td>
      <td>location ReqCp</td>
      <td>523</td>
      <td>minimumQuantity 1</td>
    </tr>
    <tr>
      <td>471</td>
      <td>elementtype "Component"</td>
      <td>524</td>
      <td>maximumQuantity 1</td>
    </tr>
    <tr>
      <td>472</td>
      <td>containertype "Pallet"</td>
      <td>525</td>
      <td>possibleelement {</td>
    </tr>
    <tr>
      <td>473</td>
      <td>}</td>
      <td>526</td>
      <td>state initial</td>
    </tr>
    <tr>
      <td>474</td>
      <td>}</td>
      <td>527</td>
      <td>location ReqCp</td>
    </tr>
    <tr>
      <td>475</td>
      <td>}</td>
      <td>528</td>
      <td>elementtype "Component"</td>
    </tr>
    <tr>
      <td>476</td>
      <td>TaskRule {</td>
      <td>529</td>
      <td>containertype "Pallet"</td>
    </tr>
    <tr>
      <td>477</td>
      <td>preconditions {</td>
      <td>530</td>
      <td>}</td>
    </tr>
    <tr>
      <td>478</td>
      <td>Precondition {</td>
      <td>531</td>
      <td>}</td>
    </tr>
    <tr>
      <td>479</td>
      <td>minimumQuantity 1</td>
      <td>532</td>
      <td></td>
    </tr>
    <tr>
      <td>480</td>
      <td>maximumQuantity 1</td>
      <td>533</td>
      <td>action Take {</td>
    </tr>
    <tr>
      <td>481</td>
      <td>possibleelement {</td>
      <td>534</td>
      <td>duration 10</td>
    </tr>
    <tr>
      <td>482</td>
      <td>state initial</td>
      <td>535</td>
      <td>output {</td>
    </tr>
    <tr>
      <td>483</td>
      <td>location "Z5a"</td>
      <td>536</td>
      <td>state initial</td>
    </tr>
    <tr>
      <td>484</td>
      <td>elementtype "Component"</td>
      <td>537</td>
      <td>location "Z6a"</td>
    </tr>
    <tr>
      <td>485</td>
      <td>}</td>
      <td>538</td>
      <td>elementtype "Component"</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>539</td>
      <td>}</td>
      <td>592</td>
    </tr>
    <tr>
      <td>540</td>
      <td>input {</td>
      <td>593</td>
    </tr>
    <tr>
      <td>541</td>
      <td>state initial</td>
      <td>594</td>
    </tr>
    <tr>
      <td>542</td>
      <td>location ReqCp</td>
      <td>595</td>
    </tr>
    <tr>
      <td>543</td>
      <td>elementtype "Component"</td>
      <td>596</td>
    </tr>
    <tr>
      <td>544</td>
      <td>containertype "Pallet"</td>
      <td>597</td>
    </tr>
    <tr>
      <td>545</td>
      <td>}</td>
      <td>598</td>
    </tr>
    <tr>
      <td>546</td>
      <td>}</td>
      <td>599</td>
    </tr>
    <tr>
      <td>547</td>
      <td>}</td>
      <td>600</td>
    </tr>
    <tr>
      <td>548</td>
      <td>TaskRule {</td>
      <td>601</td>
    </tr>
    <tr>
      <td>549</td>
      <td>preconditions {</td>
      <td>602</td>
    </tr>
    <tr>
      <td>550</td>
      <td>Precondition {</td>
      <td>603</td>
    </tr>
    <tr>
      <td>551</td>
      <td>minimumQuantity 1</td>
      <td>604</td>
    </tr>
    <tr>
      <td>552</td>
      <td>maximumQuantity 1</td>
      <td>605</td>
    </tr>
    <tr>
      <td>553</td>
      <td>possibleelement {</td>
      <td>606</td>
    </tr>
    <tr>
      <td>554</td>
      <td>state initial</td>
      <td>607</td>
    </tr>
    <tr>
      <td>555</td>
      <td>location "Z6a"</td>
      <td>608</td>
    </tr>
    <tr>
      <td>556</td>
      <td>elementtype "Component"</td>
      <td>609</td>
    </tr>
    <tr>
      <td>557</td>
      <td>}</td>
      <td>610</td>
    </tr>
    <tr>
      <td>558</td>
      <td>}</td>
      <td>611</td>
    </tr>
    <tr>
      <td>559</td>
      <td>}</td>
      <td>612</td>
    </tr>
    <tr>
      <td>600</td>
      <td>action Take {</td>
      <td>613</td>
    </tr>
    <tr>
      <td>601</td>
      <td>duration 30</td>
      <td>614</td>
    </tr>
    <tr>
      <td>602</td>
      <td>output {</td>
      <td>615</td>
    </tr>
    <tr>
      <td>603</td>
      <td>state completed</td>
      <td>616</td>
    </tr>
    <tr>
      <td>604</td>
      <td>location "Z6b"</td>
      <td>617</td>
    </tr>
    <tr>
      <td>605</td>
      <td>elementtype "Component"</td>
      <td>618</td>
    </tr>
    <tr>
      <td>606</td>
      <td>}</td>
      <td>619</td>
    </tr>
    <tr>
      <td>607</td>
      <td>input {</td>
      <td>620</td>
    </tr>
    <tr>
      <td>608</td>
      <td>state initial</td>
      <td>621</td>
    </tr>
    <tr>
      <td>609</td>
      <td>location "Z6a"</td>
      <td>622</td>
    </tr>
    <tr>
      <td>610</td>
      <td>elementtype "Component"</td>
      <td>623</td>
    </tr>
    <tr>
      <td>611</td>
      <td>}</td>
      <td>624</td>
    </tr>
    <tr>
      <td>612</td>
      <td>}</td>
      <td>625</td>
    </tr>
    <tr>
      <td>613</td>
      <td>action Take {</td>
      <td>626</td>
    </tr>
    <tr>
      <td>614</td>
      <td>duration 10</td>
      <td>627</td>
    </tr>
    <tr>
      <td>615</td>
      <td>output {</td>
      <td>628</td>
    </tr>
    <tr>
      <td>616</td>
      <td>location "Z7"</td>
      <td>629</td>
    </tr>
    <tr>
      <td>617</td>
      <td>elementtype "Pallet"</td>
      <td>630</td>
    </tr>
    <tr>
      <td>618</td>
      <td>}</td>
      <td>631</td>
    </tr>
    <tr>
      <td>619</td>
      <td>input {</td>
      <td>632</td>
    </tr>
    <tr>
      <td>620</td>
      <td>location ReqPlt1Cp</td>
      <td>633</td>
    </tr>
    <tr>
      <td>621</td>
      <td>elementtype "Pallet"</td>
      <td>634</td>
    </tr>
    <tr>
      <td>622</td>
      <td>}</td>
      <td>635</td>
    </tr>
    <tr>
      <td>623</td>
      <td>}</td>
      <td>636</td>
    </tr>
    <tr>
      <td>624</td>
      <td>}</td>
      <td>637</td>
    </tr>
    <tr>
      <td>625</td>
      <td>TaskRule {</td>
      <td>638</td>
    </tr>
    <tr>
      <td>626</td>
      <td>preconditions {</td>
      <td>639</td>
    </tr>
    <tr>
      <td>627</td>
      <td>Precondition {</td>
      <td>640</td>
    </tr>
    <tr>
      <td>628</td>
      <td>minimumQuantity 1</td>
      <td>641</td>
    </tr>
    <tr>
      <td>629</td>
      <td>maximumQuantity 1</td>
      <td>642</td>
    </tr>
    <tr>
      <td>630</td>
      <td>possibleelement {</td>
      <td>643</td>
    </tr>
    <tr>
      <td>631</td>
      <td>state completed</td>
      <td>644</td>
    </tr>
    <tr>
      <td>632</td>
      <td>location ReqCpFromM5</td>
      <td></td>
    </tr>
    <tr>
      <td>633</td>
      <td>elementtype "Component"</td>
      <td></td>
    </tr>
    <tr>
      <td>634</td>
      <td>}</td>
      <td></td>
    </tr>
    <tr>
      <td>635</td>
      <td>,</td>
      <td></td>
    </tr>
    <tr>
      <td>636</td>
      <td>Precondition {</td>
      <td></td>
    </tr>
    <tr>
      <td>637</td>
      <td>minimumQuantity 0</td>
      <td></td>
    </tr>
    <tr>
      <td>638</td>
      <td>maximumQuantity 0</td>
      <td></td>
    </tr>
    <tr>
      <td>639</td>
      <td>possibleelement {</td>
      <td></td>
    </tr>
    <tr>
      <td>640</td>
      <td>state completed</td>
      <td></td>
    </tr>
    <tr>
      <td>641</td>
      <td>location "Z7"</td>
      <td></td>
    </tr>
    <tr>
      <td>642</td>
      <td>elementtype "Component"</td>
      <td></td>
    </tr>
    <tr>
      <td>643</td>
      <td>containertype "Pallet"</td>
      <td></td>
    </tr>
    <tr>
      <td>644</td>
      <td>}</td>
      <td></td>
    </tr>
  </tbody>
</table>

<table>
  <tbody>
    <tr>
      <td>592</td>
      <td>TaskRule {</td>
    </tr>
    <tr>
      <td>593</td>
      <td>preconditions {</td>
    </tr>
    <tr>
      <td>594</td>
      <td>Precondition {</td>
    </tr>
    <tr>
      <td>595</td>
      <td>minimumQuantity 1</td>
    </tr>
    <tr>
      <td>596</td>
      <td>maximumQuantity 1</td>
    </tr>
    <tr>
      <td>597</td>
      <td>possibleelement {</td>
    </tr>
    <tr>
      <td>598</td>
      <td>state initial</td>
    </tr>
    <tr>
      <td>599</td>
      <td>location ReqPlt1Cp</td>
    </tr>
    <tr>
      <td>600</td>
      <td>elementtype "Component"</td>
    </tr>
    <tr>
      <td>601</td>
      <td>containertype "Pallet"</td>
    </tr>
    <tr>
      <td>602</td>
      <td>}</td>
    </tr>
    <tr>
      <td>603</td>
      <td>,</td>
    </tr>
    <tr>
      <td>604</td>
      <td>Precondition {</td>
    </tr>
    <tr>
      <td>605</td>
      <td>minimumQuantity 0</td>
    </tr>
    <tr>
      <td>606</td>
      <td>maximumQuantity 0</td>
    </tr>
    <tr>
      <td>607</td>
      <td>possibleelement {</td>
    </tr>
    <tr>
      <td>608</td>
      <td>location "Z7"</td>
    </tr>
    <tr>
      <td>609</td>
      <td>elementtype "Pallet"</td>
    </tr>
    <tr>
      <td>610</td>
      <td>}</td>
    </tr>
    <tr>
      <td>611</td>
      <td>}</td>
    </tr>
    <tr>
      <td>612</td>
      <td>}</td>
    </tr>
    <tr>
      <td>613</td>
      <td>action Take {</td>
    </tr>
    <tr>
      <td>614</td>
      <td>duration 10</td>
    </tr>
    <tr>
      <td>615</td>
      <td>output {</td>
    </tr>
    <tr>
      <td>616</td>
      <td>location "Z7"</td>
    </tr>
    <tr>
      <td>617</td>
      <td>elementtype "Pallet"</td>
    </tr>
    <tr>
      <td>618</td>
      <td>}</td>
    </tr>
    <tr>
      <td>619</td>
      <td>input {</td>
    </tr>
    <tr>
      <td>620</td>
      <td>location ReqPlt1Cp</td>
    </tr>
    <tr>
      <td>621</td>
      <td>elementtype "Pallet"</td>
    </tr>
    <tr>
      <td>622</td>
      <td>}</td>
    </tr>
    <tr>
      <td>623</td>
      <td>}</td>
    </tr>
    <tr>
      <td>624</td>
      <td>,</td>
    </tr>
    <tr>
      <td>625</td>
      <td>TaskRule {</td>
    </tr>
    <tr>
      <td>626</td>
      <td>preconditions {</td>
    </tr>
    <tr>
      <td>627</td>
      <td>Precondition {</td>
    </tr>
    <tr>
      <td>628</td>
      <td>minimumQuantity 1</td>
    </tr>
    <tr>
      <td>629</td>
      <td>maximumQuantity 1</td>
    </tr>
    <tr>
      <td>630</td>
      <td>possibleelement {</td>
    </tr>
    <tr>
      <td>631</td>
      <td>state completed</td>
    </tr>
    <tr>
      <td>632</td>
      <td>location ReqCpFromM5</td>
    </tr>
    <tr>
      <td>633</td>
      <td>elementtype "Component"</td>
    </tr>
    <tr>
      <td>634</td>
      <td>}</td>
    </tr>
    <tr>
      <td>635</td>
      <td>,</td>
    </tr>
    <tr>
      <td>636</td>
      <td>Precondition {</td>
    </tr>
    <tr>
      <td>637</td>
      <td>minimumQuantity 0</td>
    </tr>
    <tr>
      <td>638</td>
      <td>maximumQuantity 0</td>
    </tr>
    <tr>
      <td>639</td>
      <td>possibleelement {</td>
    </tr>
    <tr>
      <td>640</td>
      <td>state completed</td>
    </tr>
    <tr>
      <td>641</td>
      <td>location "Z7"</td>
    </tr>
    <tr>
      <td>642</td>
      <td>elementtype "Component"</td>
    </tr>
    <tr>
      <td>643</td>
      <td>containertype "Pallet"</td>
    </tr>
    <tr>
      <td>644</td>
      <td>}</td>
    </tr>
  </tbody>
</table>
645 } 698 ProvideType PrdPlt {
646 } 699 zone "Z7"
647 action Take { 700 }
648 duration 20 701 }
649 output { 702 requires {
650 state completed 703 RequireType ReqPlt1Cp,
651 location "Z7" 704 RequireType ReqCpFromM5,
652 elementtype "Component" 705 RequireType ReqCpFromM6
653 containertype "Pallet" 706 }
654 } 707 },
655 input { 708 ModuleType M8Type {
656 state completed 709 behavior Behavior {
657 location ReqCpFromM5 710 taskrules {
658 elementtype "Component" 711 TaskRule {
659 } 712 preconditions {
660 } 713 Precondition {
661 }, 714 minimumQuantity 2
662 TaskRule { 715 maximumQuantity 2
663 preconditions { 716 possibleelement {
664 Precondition { 717 state completed
665 minimumQuantity 1 718 location ReqPlt
666 maximumQuantity 1 719 elementtype "Component"
667 possibleelement { 720 containertype "Pallet"
668 state completed 721 }
669 location ReqCpFromM6 722 }
670 elementtype "Component" 723 }
671 } 724 action Take {
672 } 725 duration 10
673 } 726 output {
674 action Take { 727 location "Z8"
675 duration 10 728 elementtype "Pallet"
676 output { 729 }
677 state completed 730 input {
678 location "Z7" 731 location ReqPlt
679 elementtype "Component" 732 elementtype "Pallet"
680 containertype "Pallet" 733 }
681 } 734 }
682 input { 735 }
683 state completed 736 }
684 location ReqCpFromM6 737 }
685 elementtype "Component" 738 zones {
686 } 739 Zone "Z8"
687 } 740 }
688 } 741 provides {
689 } 742 ProvideType PrdEmptyPlt {
690 } 743 zone "Z8"
691 zones { 744 },
692 Zone "Z7" 745 ProvideType PrdCp {
693 } 746 zone "Z8"
694 provides { 747 }
695 ProvideType PrdCp { 748 }
696 zone "Z7" 749 requires {
697 }, 750 RequireType ReqPlt
<table><tr><td>751</td><td>}</td><td>776</td><td>input {</td></tr><tr><td>752</td><td>}</td><td>777</td><td>state completed</td></tr><tr><td>753</td><td>ModuleType M9Type {</td><td>778</td><td>location ReqCp</td></tr><tr><td>754</td><td>behavior Behavior {</td><td>779</td><td>elementtype "Component"</td></tr><tr><td>755</td><td>taskrules {</td><td>780</td><td>containertype "Pallet"</td></tr><tr><td>756</td><td>TaskRule {</td><td>781</td><td>}</td></tr><tr><td>757</td><td>preconditions {</td><td>782</td><td>}</td></tr><tr><td>758</td><td>Precondition {</td><td>783</td><td>}</td></tr><tr><td>759</td><td>minimumQuantity 1</td><td>784</td><td>}</td></tr><tr><td>760</td><td>maximumQuantity 2</td><td>785</td><td>}</td></tr><tr><td>761</td><td>possibleelement {</td><td>786</td><td>zones {</td></tr><tr><td>762</td><td>state completed</td><td>787</td><td>Zone "Sink"</td></tr><tr><td>763</td><td>location ReqCp</td><td>788</td><td>}</td></tr><tr><td>764</td><td>elementtype "Component"</td><td>789</td><td>requires {</td></tr><tr><td>765</td><td>containertype "Pallet"</td><td>790</td><td>RequireType ReqCp</td></tr><tr><td>766</td><td>}</td><td>791</td><td>}</td></tr><tr><td>767</td><td>}</td><td>792</td><td>}</td></tr><tr><td>768</td><td>}</td><td>793</td><td>}</td></tr><tr><td>769</td><td>action Take {</td><td>794</td><td></td></tr><tr><td>770</td><td>duration 10</td><td>795</td><td>elementtype {</td></tr><tr><td>771</td><td>output {</td><td>796</td><td>ContainerType "Pallet".</td></tr><tr><td>772</td><td>state completed</td><td>797</td><td>ProductType "Component" { }</td></tr><tr><td>773</td><td>location "Sink"</td><td>798</td><td>}</td></tr><tr><td>774</td><td>elementtype "Component"</td><td>799</td><td></td></tr><tr><td>775</td><td>}</td><td></td><td></td></tr></table>

## A.3 Modélisation avec de l'étude de cas avec des outils SED traditionnels

Nous avons expérimenté l'étude de cas avec différents outils de modélisation et de vérification dédiés à la vérification formelle de la dynamique des systèmes. Entre autres, nous utilisons des outils de réseaux de Petri (Tina, Romeo, CPN tools), des automates communicants (UPPAAL, Itemis), ou des processus (SPIN, CADP).

Ces travaux font l'objet d'une autre communication soumise à MSR 2025 et dont voici l'URL de l'annexe en ligne 7. Nous ne donnons ici que l'édition du modèle avec Tina dans la FIGURE 11.

## A.4 Vérification et exécution avec Kmelia

Kmelia [2] est un langage permettant de décrire un modèle de composant basé sur la description de services complexes. Les composants Kmelia sont abstraits, indépendants de leur environnement et donc non exécutables. Kmelia peut être utilisé pour modéliser des architectures logicielles et leurs propriétés, ces modèles étant ensuite affinés pour devenir des plates-formes d'exécution. Il peut également servir de modèle commun pour étudier les propriétés des modèles de composants ou de services (abstraction, interopérabilité, composabilité). Les principales caractéristiques de Kmelia sont les suivantes : composants, services, architectures logicielles, protocoles, contrats, spécification de l'interaction complexe entre les services.

COSTO (Component Study Toolbox) 8 est un outil dédié au développement de systèmes lo-

<footnote n="7">7. https://tinyurl.com/mubvedjd</footnote>

<footnote n="8">8. https://costo.univ-nantes.fr/</footnote>
<figure><img src="image_11.png" /><figcaption>FIGURE 11 – Cas d'étude simplifié traité avec Tina</figcaption></figure>

giciels basés sur les services et les composants. Ces systèmes sont modélisés à l'aide du langage Kmelia. COSTO gère les spécifications de Kmelia et s'occupe de la vérification des propriétés primaires (analyse syntaxique, vérification de type, analyse statique, ...). Les vérifications de propriétés complexes telles que l'absence de blocage, la cohérence des composants ou des assemblages sont déléguées à d'autres outils externes appropriés (MEC, Altarica, Lotos/CADP, AtelierB, Rodin...). COSTO est conçu comme une famille de plugins Eclipse.

Pour ds raisons de place, le document de 44 pages qui contient la spécification du cas avec 2 postes et le convoyeur est disponible en ligne <fnref n="9" />.

## A.5 Simulation de l'étude de cas avec FlexSim

L'étude décrite dans la section 5 a été modélisée dans FlexSim. Les modules sont appelés Posteᵢ dans cette implantation du cas. La division en modules n'est pas la même que celle de notre DSL. Ici, le convoyeur et les machines de traitement ont été divisés en 4 stations de travail. La simulation a été réalisée pour différentes reconfigurations de la ligne : (1) configuration de base comme dans la FIGURE ??, (2) panne du convoyeur, (3) optimisation du nombre de palettes, (4) découplage de Poste2 et Poste3, (5) découplage de Poste2 et Poste3 avec rupture du convoyeur.

Des indicateurs clés de performance (KPI) ont été définis pour permettre la comparaison des scénarios : (1) taux d'utilisation des postes de travail, (2) nombre de produits saisis/traités, (3) évolution du niveau de stock de composants, (4) temps moyen de traitement (*throughput*), (5) évolution du nombre de palettes disponibles sur le convoyeur entre Poste 4 et Poste 1.

Dans FlexSim, une expérience est un ensemble de variables, de réplications et de scénarios exécutés successivement à l'aide du même modèle de simulation. Une variable est un aspect simple d'un modèle de simulation, différent selon le scénario (e.g. dans notre cas, les plannings

<footnote n="9">9. https://uncloud.univ-nantes.fr/index.php/s/6kp56wPKdN5tXjk</footnote>
<figure><img src="image_12.png" /><figcaption>FIGURE 12 – FlexSim Screenshot of the case Study</figcaption></figure>

d'arrivée des éléments de flux). Un scénario est un ensemble d'une ou plusieurs variables qui changent lors de l'exécution d'un modèle de simulation. Une réplication est une exécution unique d'un modèle de simulation pour un scénario spécifique (10 dans notre cas pour obtenir des données statistiques plus précises).

Chaque scénario a été évalué avec les mêmes paramètres. Dans un cas, ces paramètres sont stochastiques : le temps d'arrivée des composants en stock suit une distribution normale avec une moyenne de 14,25 secondes et un écart type de 3 secondes. Dans un autre cas, ils sont déterministes : un nouveau composant arrive en stock toutes les 14,25 secondes.

Voici les valeurs des paramètres déterministes<fnref n="10" /> : (1) Nombre de palettes : 5 (2) Heure d'arrivée des composants (initialisation) : 0 seconde, (3) Temps entre l'arrivée de deux composants en stock : 14,25 secondes, (4) Heure de première arrivée pour Poste 1 : 0 seconde, (5) Temps de traitement pour Poste 2 : 10 secondes, (6) Temps de traitement pour Poste 3 : 10 secondes.

Avec ces paramètres, pour une durée de simulation de 8 heures, nous obtenons, entre autres, les résultats suivants :

Average throughput time

<table><caption>FIGURE 13 – Temps de traitement moyen (Average Throughput Time)</caption><thead><tr><td>Scenario</td><td>AvgStaytime - Mean</td><td>MinStaytime - Mean</td><td>MaxStaytime - Mean</td></tr></thead><tbody><tr><td>5 palette</td><td>145.21</td><td>84.35</td><td>202.53</td></tr></tbody></table>

<footnote n="10">10. Nous disposons également d'autres scénarios avec des paramètres aléatoires, un nombre de palettes différent, des événements et des pannes différents, etc.</footnote>
<figure><img src="image_13.png" /><figcaption>FIGURE 14 – Taux d'utilisation de chaque poste de travail</figcaption></figure>

Table des matières

<table><tr><td>1 Introduction</td><td>1</td></tr><tr><td>2 Contexte</td><td>2</td></tr><tr><td>3 Un DSL pour modéliser les systèmes manufacturiers</td><td>4</td></tr><tr><td>3.1 Syntaxe abstraite</td><td>4</td></tr><tr><td>3.2 Syntaxe concrète textuelle</td><td>6</td></tr><tr><td>3.3 Sémantique opérationnelle</td><td>6</td></tr><tr><td>4 Implantation du DSL proposé</td><td>7</td></tr><tr><td>4.1 Syntaxe abstraite et d'un éditeur arborescent de modèles</td><td>7</td></tr><tr><td>4.2 Syntaxe concrète textuelle et d'un éditeur associé</td><td>8</td></tr><tr><td>4.3 Sémantique opérationnelle en simulateur de modèles</td><td>8</td></tr><tr><td>5 Expérimentation de l'outil</td><td>9</td></tr><tr><td>5.1 Etude de cas</td><td>9</td></tr><tr><td>5.2 Modélisation</td><td>9</td></tr><tr><td>5.3 Evaluation, traces...</td><td>9</td></tr></table>
# 6 Discussion 10

6.1 Comparaison avec les outils de vérification formelle 11

6.2 Comparaison avec un langage de spécification large spectre 12

6.3 Comparaison avec des simulateurs 12

6.4 Complémentarité 12

# 7 Conclusion 13

# A Annexe en ligne 15

A.1 Métamodèle du DSL 15

A.1.1 Structure 16

A.1.2 Comportement dynamique et fonctionnel 16

A.1.3 Système à l'exécution 17

A.2 Spécification textuelle du cas d'étude avec le DSL 18

A.3 Modélisation avec de l'étude de cas avec des outils SED traditionnels 26

A.4 Vérification et exécution avec Kmelia 26

A.5 Simulation de l'étude de cas avec FlexSim 27