Skip to content

Objets intelligents : l'avenir de la simulation

  • AUTHOR
  • Simio Staff

Résumé

Cet article décrit un nouveau système de modélisation - Simio - conçu pour simplifier la construction de modèles en favorisant un changement de paradigme de modélisation, de l'orientation processus à l'orientation objet. Simio est un cadre de modélisation de simulation basé sur des objets intelligents. Les objets intelligents sont construits par les modélisateurs et peuvent ensuite être réutilisés dans plusieurs projets de modélisation. Bien que le cadre Simio soit axé sur la modélisation basée sur les objets, il prend également en charge l'utilisation transparente de plusieurs paradigmes de modélisation, y compris la modélisation basée sur les événements, les processus, les objets et les agents.

1. Paradigmes de modélisation

Dans les premiers temps de la simulation à événements discrets, le paradigme de modélisation dominant était l'orientation événementielle mise en œuvre par des outils tels que Simscript (Markowitz, et .al 1962.) et GASP (Pritsker, 1967). Dans ce paradigme de modélisation, le système est considéré comme une série d'événements instantanés qui modifient l'état du système. Le modélisateur définit les événements dans le système et modélise les changements d'état qui ont lieu lorsque ces événements se produisent. Cette approche de la modélisation est très souple et efficace, mais elle constitue également une représentation relativement abstraite du système. C'est pourquoi de nombreuses personnes ont trouvé que la modélisation à l'aide d'une orientation événementielle était difficile.

Dans les années 80, l'orientation processus a supplanté l'orientation événement en tant qu'approche dominante de la simulation à événements discrets. Dans la vue processus, nous décrivons le mouvement d'entités passives à travers le système comme un flux de processus. Le flux de processus est décrit par une série d'étapes de processus (par exemple, saisir, retarder, libérer) qui modélisent les changements d'état qui ont lieu dans le système. Cette approche remonte aux années 1960 avec l'introduction du GPSS (Gordon, 1960) et constitue un moyen plus naturel de décrire le système. Cependant, en raison des nombreux problèmes pratiques posés par le GPSS original (par exemple, une horloge à nombre entier et une exécution lente), il n'est pas devenu l'approche dominante jusqu'à ce que des versions améliorées du GPSS (Henriksen, 76) ainsi que des langages de processus plus récents tels que SLAM (Pegden/Pritsker, 79) et SIMAN (Pegden, 82) soient largement utilisés dans les années 80. Au cours des années 80 et 90, la modélisation graphique et l'animation sont également devenues des caractéristiques essentielles des outils de modélisation de simulation. La construction de modèles graphiques a simplifié le processus de construction de modèles de processus, et l'animation graphique a considérablement amélioré la visualisation et la validation des résultats de simulation. L'introduction de Microsoft Windows a permis de construire des interfaces utilisateur graphiques améliorées et un certain nombre de nouveaux outils graphiques ont vu le jour (par exemple ProModel et Witness).

Une autre avancée conceptuelle qui s'est produite à cette époque a été l'introduction d'outils de modélisation de processus hiérarchiques qui prenaient en charge la notion de bibliothèques de processus spécifiques à un domaine. Le concept de base ici est de permettre aux utilisateurs de créer de nouvelles étapes de processus en combinant des étapes de processus existantes. Le système de modélisation Arena (Pegden/Davis, 1992), largement utilisé, est un bon exemple de cette capacité.

Depuis le passage généralisé à une orientation graphique des processus, les outils ont été affinés et améliorés, mais le cadre sous-jacent n'a pas vraiment progressé. La grande majorité des modèles d'événements discrets continuent d'être construits en utilisant la même orientation de processus qui a été largement utilisée au cours des 25 dernières années.

Bien que l'orientation processus se soit avérée très efficace dans la pratique, l'orientation objet offre un paradigme de modélisation alternatif attrayant qui a le potentiel d'être plus naturel et plus facile à utiliser. Dans une orientation objet, nous modélisons le système en décrivant les objets qui le composent. Par exemple, nous modélisons une usine en décrivant les travailleurs, les machines, les convoyeurs, les robots et les autres objets qui composent le système. Le comportement du système émerge de l'interaction de ces objets.

Bien qu'un certain nombre de produits aient été introduits pour soutenir l'orientation objet, à ce jour, de nombreux praticiens ont choisi de s'en tenir à l'orientation processus. L'une des principales raisons en est que, si le paradigme de modélisation sous-jacent peut être plus simple et moins abstrait, la mise en œuvre spécifique peut être difficile à apprendre et à utiliser (par exemple, elle nécessite de la programmation) ou lente à exécuter. Cette situation n'est pas différente des difficultés rencontrées par l'orientation processus pour s'imposer face à l'orientation événement. Bien que le premier outil de modélisation de processus (GPSS) ait été introduit en 1961, il a fallu 25 ans pour que l'orientation processus soit développée au point de persuader les praticiens de changer de paradigme. Cet article décrit Simio, un nouvel outil de modélisation de simulation conçu pour rendre l'orientation objet facile à utiliser et efficace à exécuter. Bien que Simio intègre un certain nombre de caractéristiques innovantes dans la poursuite de cet objectif, seul le temps nous dira si cet outil a permis de résoudre les nombreuses questions pratiques qui doivent être abordées pour déclencher un changement de paradigme généralisé dans la façon dont les praticiens construisent les modèles.

L'outil est conçu dès le départ pour prendre en charge le paradigme de la modélisation objet, mais il permet également l'utilisation transparente de plusieurs paradigmes de modélisation, y compris l'orientation processus et l'orientation événement. Il prend également en charge les systèmes discrets et continus, ainsi que les applications à grande échelle basées sur la modélisation à base d'agents. Ces paradigmes de modélisation peuvent être librement mélangés au sein d'un même modèle.

2. Le paradigme objet Simio

Simio est un cadre de modélisation de simulation basé sur des objets intelligents. Les objets intelligents sont construits par les modélisateurs et peuvent ensuite être réutilisés dans plusieurs projets de modélisation. Les objets peuvent être stockés dans des bibliothèques et facilement partagés. Un modélisateur débutant peut préférer utiliser des objets préconstruits provenant de bibliothèques, mais le système est conçu pour permettre aux modélisateurs, même débutants, de construire facilement leurs propres objets intelligents à utiliser dans la construction de modèles hiérarchiques.

Un objet peut être une machine, un robot, un avion, un client, un médecin, un char, un bus, un bateau ou toute autre chose que vous pourriez rencontrer dans votre système. Un modèle est construit en combinant des objets qui représentent les composants physiques du système. Un modèle Simio ressemble au système réel. La logique et l'animation du modèle sont construites en une seule étape.

Un objet peut être animé en 3D pour refléter l'état changeant de l'objet. Par exemple, un chariot élévateur monte et descend son élévateur, un robot ouvre et ferme sa pince et un char de combat tourne sa tourelle. Le modèle animé fournit une image en mouvement du système en fonctionnement.

Les objets sont construits en utilisant les concepts de l'orientation objet. Cependant, contrairement à d'autres systèmes de simulation orientés objet, le processus de construction d'un objet est très simple et entièrement graphique. Il n'est pas nécessaire d'écrire un code de programmation pour créer de nouveaux objets.

L'activité de construction d'un objet dans Simio est identique à l'activité de construction d'un modèle - en fait, il n'y a pas de différence entre un objet et un modèle. Ce concept, appelé principe d'équivalence, est au cœur de la conception de Simio. Chaque fois que vous construisez un modèle, il s'agit par définition d'un objet qui peut être instancié dans un autre modèle. Par exemple, si vous combinez deux machines et un robot dans un modèle de cellule de travail, le modèle de cellule de travail est lui-même un objet qui peut être instancié un nombre illimité de fois dans d'autres modèles. La cellule de travail est un objet au même titre que les machines et le robot. Dans Simio, il n'y a aucun moyen de séparer l'idée de construction d'un modèle du concept de construction d'un objet. Chaque modèle construit dans Simio est automatiquement un bloc de construction qui peut être utilisé pour construire des modèles de niveau supérieur.

3. La fondation orientée objet

De nombreux langages de programmation populaires tels que C++, C# et Java sont tous construits autour des principes de base de la programmation orientée objet (POO). Dans ce paradigme de programmation, les logiciels sont construits comme une collection d'objets coopératifs qui sont instanciés à partir de classes. Ces classes sont conçues selon les principes fondamentaux de l'abstraction, de l'encapsulation, du polymorphisme, de l'héritage et de la composition.

Le principe d'abstraction peut se résumer à se concentrer sur l'essentiel. Le principe de base est de rendre la structure des classes aussi simple que possible.

Le principe d'encapsulation spécifie que seul l'objet peut modifier son état. L'encapsulation scelle l'implémentation de la classe d'objets par rapport au monde extérieur.

Le polymorphisme fournit une méthode cohérente pour que les messages déclenchent les actions de l'objet. Chaque classe d'objets décide de la manière de répondre à un message spécifique.

L'héritage est un concept clé qui permet à de nouvelles classes d'objets d'être dérivées de classes d'objets existantes : c'est ce que l'on appelle parfois la relation "is-a". On parle également de sous-classement, puisque nous créons une classe plus spécialisée d'un objet. La sous-classification permet généralement d'étendre le comportement de l'objet à l'aide d'une nouvelle logique et de le modifier en remplaçant une partie de la logique existante.

La composition permet de créer de nouvelles classes d'objets en combinant des classes d'objets existantes : c'est ce que l'on appelle parfois la relation "a-un". Les objets deviennent des blocs de construction pour créer des objets de niveau supérieur.

Il est intéressant de noter que les racines de ces idées remontent au début des années 1960 avec l'outil de modélisation Simula 67. Cet outil de modélisation a été créé par Kristen Nygaard et Ole-Johan Dahl (1962) du Centre informatique norvégien d'Oslo pour modéliser le comportement des navires. Ils ont introduit les concepts de base de la création de classes d'objets qui possèdent leurs données et leur comportement, et qui peuvent être instanciés dans d'autres objets. Ce fut la naissance de la modélisation hiérarchique et de la programmation orientée objet.

De nombreuses personnes pensent que les concepts de programmation orientée objet ont été développés dans le monde de la programmation, mais ce n'est pas le cas. Ces principes ont été développés pour construire des modèles de simulation, puis adoptés par le monde de la programmation.

Bien que le monde de la simulation ait créé les concepts orientés objet originaux, il n'a pas encore produit un cadre de modélisation orienté objet que les praticiens ont largement adopté. Bien qu'il y ait eu un certain nombre de tentatives pour fournir un tel cadre, les praticiens s'en sont finalement tenus, pour la plupart, à leur orientation processus éprouvée pour la modélisation. L'une des principales raisons en est que la plupart des tentatives antérieures ont simplement consisté en des bibliothèques de programmation orientées objet qui obligent l'utilisateur à revenir 25 ans en arrière et à coder à nouveau ses modèles et/ou objets dans un langage de programmation.

4. Le cadre objet de Simio

Le cadre objet de Simio repose sur les mêmes principes de base que les langages de programmation orientés objet, mais ces principes sont appliqués dans un cadre de modélisation et non dans un cadre de programmation. Par exemple, l'équipe de développement de Microsoft qui a conçu C# a appliqué ces principes de base dans la conception de ce langage de programmation. Bien que ces mêmes principes guident la conception de Simio, le résultat n'est pas un langage de programmation, mais plutôt un système de modélisation graphique. Cette distinction est importante pour comprendre la conception de Simio.

Simio n'est pas simplement un outil de modélisation de simulation programmé dans un langage OOP (bien qu'il soit programmé en C#). De même, il ne s'agit pas d'un simple ensemble de classes disponibles dans un langage OOP tel que Java ou C++ qui sont utiles pour construire des modèles de simulation. Simio est un cadre de modélisation graphique destiné à soutenir la construction de modèles de simulation et conçu autour des principes de base de l'orientation objet. Par exemple, lorsque vous créez un objet tel qu'une "machine" dans Simio, le principe d'héritage vous permet de créer une nouvelle classe de machines qui hérite du comportement de base d'une "machine", mais ce comportement peut être modifié (surchargé) et étendu. Alors que dans un langage de programmation, nous étendons ou remplaçons un comportement en écrivant des méthodes, dans Simio, nous étendons ou remplaçons un comportement en ajoutant et en remplaçant des modèles de processus définis graphiquement.

Cette distinction entre la modélisation orientée objet et la programmation orientée objet est cruciale. Avec Simio, les compétences requises pour définir et ajouter de nouveaux objets au système sont des compétences de modélisation et non de programmation.

5. L'anatomie d'un objet (modèle)

Lorsque vous créez un modèle dans Simio, vous créez une classe d'objets à partir de laquelle plusieurs instances peuvent être créées. Ce processus est appelé instanciation.

Lorsque vous instanciez un objet dans un modèle, vous pouvez spécifier les propriétés de l'objet qui régissent le comportement de cette instance spécifique de l'objet. Par exemple, les propriétés d'une machine peuvent inclure le temps de préparation, de traitement et de démontage, ainsi qu'une nomenclature et un opérateur requis pendant la préparation. Le créateur de l'objet décide du nombre et de la signification des propriétés. Les propriétés dans Simio sont fortement typées et peuvent représenter des valeurs numériques, des booléens, des chaînes de caractères, des références d'objets, des dates et des heures, etc. Puisque tout modèle que vous construisez est par définition un objet, vous avez la possibilité de paramétrer votre modèle par le biais de propriétés.

Il convient de noter que l'instanciation d'un modèle n'est pas la même chose que la copie ou le clonage du modèle. Lorsqu'un modèle est utilisé comme élément constitutif dans la construction d'autres modèles, il peut être instancié plusieurs fois dans de nombreux modèles différents. L'instance de modèle contient simplement une référence à la définition du modèle qui est utilisée à plusieurs reprises. L'instance contient également les valeurs des propriétés puisqu'elles sont uniques à chaque instance. Cependant, la logique du modèle est partagée par toutes les instances. Quel que soit le nombre d'instances créées, il n'existe qu'une seule définition de classe de l'objet, et chaque instance renvoie à cette définition unique. Chaque instance détient les propriétés qui lui sont propres, mais se réfère à la définition pour obtenir son comportement sous-jacent. Si le comportement de la définition est modifié, toutes les instances utilisent automatiquement ce nouveau comportement.

Outre les propriétés, les objets ont également des états. Les états sont également fortement typés, mais ils correspondent toujours à une valeur numérique. Par exemple, les booléens true et false correspondent à 1 et 0, et une liste énumérée de noms d'états correspond à la position de l'index de la liste (0, 1, ...., N). Un état change à la suite de l'exécution de la logique à l'intérieur de l'objet. Les propriétés peuvent être considérées comme des entrées dans un objet, et les états comme des réponses de sortie qui changent tout au long de l'exécution de la logique de l'objet. Un état peut représenter le nombre de pièces terminées, l'état d'une machine sélectionnée dans une liste d'états énumérés, la température d'un lingot chauffé dans un four, le niveau d'huile dans un navire en cours de remplissage ou le niveau d'accumulation sur un convoyeur à bande.

Il existe deux types fondamentaux d'états : discrets et continus. Un état discret est une valeur qui ne change qu'au moment d'un événement (arrivée d'un client, panne d'une machine, etc.). Un état continu (par exemple, le niveau d'un réservoir, la position d'un chariot, etc.

6. Trois niveaux d'objets

L'une des caractéristiques importantes et uniques de la conception interne de Simio est l'utilisation d'une structure d'objet à trois niveaux qui sépare un objet en une définition d'objet, une instance d'objet et une réalisation d'objet. La définition de l'objet spécifie le comportement de l'objet et est partagée par toutes les instances de l'objet. Une instance d'objet est simplement une instance de cet objet au sein d'une définition d'objet parent (par exemple, une instance de tour est placée à l'intérieur d'une définition de cellule de travail). L'instance d'objet définit les valeurs des propriétés de chaque instance individuelle de l'objet et ces données d'instance sont à leur tour partagées par toutes les réalisations d'objets.

La réalisation d'objet est utilisée pour représenter une réalisation spécifique d'une instance au sein d'une hiérarchie de modèle étendue. Par exemple, chaque fois qu'une nouvelle instance de cellule de travail est placée dans une définition d'objet parent (par exemple, une ligne de production), il est nécessaire de créer une nouvelle réalisation pour le tour intégré. Bien que la définition de la cellule de travail soit construite à partir d'une seule instance de tour, cette instance ne peut pas contenir les valeurs d'état correspondant à plusieurs réalisations de tour résultant de plusieurs instances de la cellule de travail. Les réalisations d'objets fournissent le mécanisme permettant de conserver ces informations d'état hiérarchiques sous une forme très compacte. Les réalisations d'objets ne sont créées que pendant l'exécution du modèle et ne contiennent que les variables d'état du modèle et une référence à leur instance d'objet parent. Il s'agit d'une structure très efficace qui est cruciale pour les applications à grande échelle telles que les modèles basés sur des agents qui peuvent avoir plusieurs milliers de réalisations d'objets.

7. Trois façons de construire des définitions d'objets

L'exemple précédent, dans lequel nous avons défini un nouvel objet (cellule de travail) en combinant d'autres objets (machines et robot), est un exemple de la manière dont nous pouvons créer des définitions d'objets dans Simio. Ce type d'objet est appelé objet composé car nous créons cet objet en combinant deux ou plusieurs objets composants. Cette approche de la construction d'objets est entièrement hiérarchique, c'est-à-dire qu'un objet composé peut être utilisé comme objet composant dans la construction d'objets de niveau supérieur. Ce n'est qu'une des façons de créer des objets dans Simio ; il existe deux autres méthodes importantes.

La méthode la plus élémentaire pour créer des objets dans Simio consiste à définir les processus logiques qui modifient leur état en réponse à des événements. Par exemple, un objet machine peut être construit en définissant les processus qui modifient l'état de la machine en fonction d'événements tels que l'arrivée d'une pièce, la panne d'un outil, etc. Ce type de modélisation est similaire à la modélisation des processus effectuée dans les systèmes de modélisation traditionnels utilisés aujourd'hui, tels que Arena ou GPSS. Un objet défini par la description de ses processus natifs est appelé objet de base. Un objet de base peut à son tour être utilisé comme objet composant pour la construction d'objets de niveau supérieur.

La dernière méthode de construction d'objets dans Simio est basée sur le concept d'héritage. Dans ce cas, nous créons un objet à partir d'un objet existant en remplaçant un ou plusieurs processus au sein de l'objet, ou en ajoutant des processus supplémentaires pour étendre son comportement. En d'autres termes, nous commençons par un objet qui correspond presque à ce que nous voulons, puis nous le modifions et l'étendons si nécessaire pour qu'il réponde à nos besoins. Par exemple, nous pourrions construire un objet de forage spécialisé à partir d'un objet de machine généralisé en ajoutant des processus supplémentaires pour gérer la défaillance et le remplacement du trépan. Un objet construit de cette manière est appelé objet dérivé, car il est sous-classé à partir d'un objet existant.

Quelle que soit la méthode utilisée pour créer un objet, une fois créé, il est utilisé exactement de la même manière. Un objet peut être instancié un nombre illimité de fois dans un modèle. Il vous suffit de sélectionner l'objet qui vous intéresse et de le placer (l'instancier) dans votre modèle

8. Classe d'objets

Il existe six classes d'objets de base dans Simio. Ces six classes d'objets constituent un point de départ pour la création d'objets intelligents dans Simio. Par défaut, ces six classes d'objets ont très peu d'intelligence native, mais toutes ont la capacité de gagner en intelligence. Vous construisez des versions intelligentes de ces objets en modélisant leur comportement comme un ensemble de processus événementiels.

La première classe est celle des objets fixes. Cet objet a un emplacement fixe dans le modèle et est utilisé pour représenter les éléments de votre système qui ne se déplacent pas d'un endroit à l'autre. Les objets fixes sont utilisés pour représenter les équipements stationnaires tels que les machines, les stations de ravitaillement en carburant, etc.

Les agents sont des objets qui peuvent se déplacer librement dans un espace tridimensionnel. Les agents sont également utilisés pour développer des modèles basés sur les agents. Ce type de modélisation est utile pour étudier les systèmes composés de nombreux objets intelligents indépendants qui interagissent les uns avec les autres et créent ainsi le comportement global du système. Parmi les exemples d'applications, on peut citer l'acceptation par le marché d'un nouveau produit ou service, ou la croissance de la population d'espèces concurrentes dans un environnement.

Une entité est une sous-classe de la classe Agent et possède un comportement supplémentaire important. Les entités peuvent se déplacer dans le système d'un objet à l'autre par le biais d'un réseau de liens et de nœuds. Parmi les exemples d'entités, on peut citer les clients dans un système de services, les pièces dans un système de fabrication, les navires dans un système de transport, les chars dans un système de combat, les médecins, les infirmières et les patients dans un système de santé.

Notez que dans les systèmes de modélisation traditionnels tels que GPSS ou Arena, les entités sont passives et agissent sur les processus du modèle. Cependant, dans Simio, les entités peuvent être intelligentes et contrôler leur propre comportement.

Les objets lien et nœud sont utilisés pour construire des réseaux sur lesquels les entités peuvent circuler. Un lien définit un chemin pour le mouvement des entités entre les objets. Un nœud définit un point de départ ou d'arrivée pour un lien. Les liens et les nœuds peuvent être combinés pour former des réseaux complexes. Bien que le lien de base ait peu d'intelligence, nous pouvons lui ajouter un comportement qui lui permette de modéliser des flux non contraints, des flux de circulation encombrés ou des systèmes de manutention complexes tels que des convoyeurs à accumulation ou des systèmes de puissance et de liberté.

La dernière classe d'objets est celle des transporteurs et elle est sous-catégorisée par rapport à la classe des entités. Un transporteur est une entité qui a la capacité supplémentaire de ramasser, de transporter et de déposer une ou plusieurs autres entités. Par défaut, les transporteurs n'ont aucun de ces comportements, mais en ajoutant une logique de modèle à cette classe, nous pouvons créer un large éventail de comportements pour les transporteurs. Un transporteur peut modéliser un taxi, un bus, un AGV, un wagon de métro, un chariot élévateur ou tout autre objet ayant la capacité de transporter d'autres entités d'un endroit à un autre.

L'une des principales caractéristiques de Simio est la possibilité de créer une large gamme de comportements d'objets à partir de ces six classes de base. Le cadre de modélisation Simio est neutre par rapport au domaine d'application, c'est-à-dire que ces six classes de base ne sont pas spécifiques à la fabrication, aux systèmes de service, aux soins de santé, à l'armée, etc. Cependant, il est facile de construire des bibliothèques axées sur les applications, composées d'objets intelligents issus de ces six classes et conçus pour des applications spécifiques. Par exemple, il est relativement simple de construire un objet (dans ce cas, un lien) qui représente un convoyeur à accumulation complexe pour une utilisation dans des applications de fabrication. La philosophie de conception de Simio veut que ce type de logique spécifique au domaine appartienne aux objets construits par les utilisateurs et non pas programmés dans le système central.

9. Création d'objets intelligents avec des processus

La modélisation dans Simio commence par les objets de base - c'est la fondation sur laquelle les objets de niveau supérieur sont construits. Un objet de base dans Simio est un objet fixe, un agent, une entité, un lien, un nœud ou un transporteur auquel on a ajouté de l'intelligence grâce à un ou plusieurs processus. Les processus confèrent à un objet son intelligence en définissant la logique qui est exécutée en réponse à des événements.

Chaque processus est une séquence d'étapes déclenchée par un événement et exécutée par un jeton. Un processus commence toujours par une seule étape de début et se termine par une seule étape de fin. Un jeton est libéré par l'étape Begin et est simplement un fil d'exécution (similaire aux entités dans Arena). Un jeton peut avoir des propriétés (paramètres d'entrée) et des états (valeurs modifiables en cours d'exécution) qui contrôlent l'exécution des étapes du processus. Vous pouvez définir vos propres classes de jetons avec différentes combinaisons de propriétés et d'états.

La puissance de modélisation de Simio provient de l'ensemble des événements qui sont automatiquement déclenchés pour les six classes d'objets de base, ainsi que des étapes du processus qui sont disponibles pour modéliser les changements d'état qui se produisent en réponse à ces événements. La maîtrise complète de l'art de construire des objets intelligents implique l'apprentissage des événements et de la collection d'étapes de processus disponibles, ainsi que la connaissance et l'expérience de la façon de combiner ces étapes pour représenter une logique complexe.

Chaque étape de Simio modélise un processus simple tel que le maintien du jeton pendant un certain temps, la saisie/libération d'une ressource, l'attente d'un événement, l'attribution d'une nouvelle valeur à un état ou la prise de décision entre deux chemins de flux alternatifs. Certaines étapes (par exemple le délai) sont des étapes générales qui sont utiles pour modéliser des objets, des liens, des entités, des transporteurs, des agents et des groupes. D'autres étapes ne sont utiles que pour des objets spécifiques. Par exemple, les étapes Pickup et Dropoff ne sont utiles que pour ajouter de l'intelligence aux transporteurs et les étapes Engage et Disengage ne sont utiles que pour ajouter de l'intelligence aux liens.

Chaque classe d'objets possède son propre ensemble d'événements. Par exemple, un lien fournit des événements qui se déclenchent lorsque des entités entrent et sortent du lien, fusionnent complètement sur le lien, entrent en collision avec d'autres entités résidant sur le lien ou s'en séparent, se déplacent dans un rayon spécifié d'une autre entité, etc. En fournissant une logique de modèle pour répondre à ces événements, nous pouvons contrôler complètement le mouvement des entités sur le lien. Par exemple, pour ajouter une logique d'accumulation au lien, il suffit d'écrire un petit processus qui se déclenche lorsqu'une entité entre en collision avec l'entité qu'elle suit, et qui réaffecte la vitesse de l'entité pour qu'elle corresponde à la vitesse de l'entité qu'elle suit.

Les étapes du processus qui sont utilisées pour définir la logique sous-jacente d'un objet sont sans état, c'est-à-dire qu'elles ont des propriétés (paramètres d'entrée) mais pas d'états (réponses de sortie). Ceci est important car cela signifie qu'une seule copie du processus peut être détenue par la définition de la classe d'objet, et partagée par un nombre arbitraire d'instances d'objets. Si la logique du processus est modifiée, ce fait est automatiquement reflété par toutes les instances de l'objet.

Les états d'une instance d'objet sont conservés dans des éléments. Les éléments définissent les composants dynamiques d'un objet et peuvent avoir à la fois des propriétés (paramètres d'entrée) et des états (valeurs modifiables en cours d'exécution). Au sein d'un objet, les jetons peuvent exécuter des étapes qui modifient les états des éléments appartenant à l'objet.

Un exemple d'élément est la station qui définit un emplacement dans un objet. Les stations sont également utilisées pour définir les points d'entrée et de sortie d'un objet. Les entités peuvent être transférées dans et hors des stations (à l'aide de l'étape Transfert), et une station maintient une file d'attente des entités qui s'y trouvent actuellement ainsi que des entités qui attendent d'être transférées dans la station. Une station a une capacité qui limite les transferts dans une station. Ainsi, une entité arrivant à un objet par un lien ne peut quitter le lien et entrer dans l'objet que si la station d'entrée de l'objet dispose d'une capacité disponible.

10. Ordonnancement à capacité finie

Bien que la simulation ait traditionnellement été appliquée au problème de la conception, elle peut également être utilisée sur une base opérationnelle pour générer des programmes de production pour l'usine. Lorsqu'elle est utilisée dans ce mode, la simulation est un planificateur de capacité finie (FCS) et constitue une alternative à d'autres méthodes FCS telles que les algorithmes d'optimisation et les séquenceurs job-at-atime. Cependant, le FCS basé sur la simulation présente un certain nombre d'avantages importants (par exemple, la vitesse d'exécution et la logique d'ordonnancement flexible) qui en font une solution puissante pour les applications d'ordonnancement.

La simulation fournit une méthode simple mais flexible pour générer un programme à capacité finie pour l'atelier. L'approche de base de la planification basée sur la simulation consiste à exécuter le modèle d'usine en utilisant l'état initial de l'usine et l'ensemble des commandes planifiées à produire. Des règles de décision sont incorporées dans le modèle pour sélectionner les tâches, les ressources et les itinéraires. La simulation construit un calendrier en simulant le flux de travail dans l'usine et en prenant des décisions "intelligentes" basées sur les règles d'ordonnancement spécifiées. Les résultats de la simulation sont généralement affichés sous forme de tâches chargées sur un diagramme de Gantt interactif qui peut être manipulé par l'utilisateur. Il existe un grand nombre de règles qui peuvent être appliquées dans un modèle de simulation pour générer différents types de programmes axés sur des mesures telles que la maximisation du débit, le maintien d'une utilisation élevée sur un goulot d'étranglement, la minimisation des changements ou le respect des dates d'échéance spécifiées.

En raison des exigences particulières imposées par les applications de planification (par exemple, le besoin de règles de décision spécialisées et la nécessité de visualiser les résultats sous la forme d'un diagramme de Gantt interactif), les applications de planification basées sur la simulation ont généralement fait appel à des simulateurs spécialisés spécialement conçus pour ce domaine d'application. Le problème de cette approche est que les simulateurs spécialisés ont des modèles d'usine intégrés, basés sur des données, qui ne peuvent pas être modifiés pour s'adapter à l'application. Dans de nombreux cas, ce modèle intégré est une vue trop simplifiée des complexités de l'atelier de production. Cette approche unique limite considérablement la gamme d'applications de ces outils. Certains processus de production peuvent être représentés de manière adéquate par ce modèle fixe, mais beaucoup d'autres ne le peuvent pas.

Simio adopte une approche différente en permettant au modèle d'usine d'être défini en utilisant toute la puissance de modélisation générale de l'outil. Ainsi, la gamme d'applications n'est plus limitée par un modèle fixe intégré qui ne peut pas être modifié ou changé d'une application à l'autre. Les complexités du processus de production peuvent être entièrement capturées par le modèle Simio construit par l'utilisateur. Cela inclut non seulement la logique au sein de chaque poste de travail, mais aussi la manutention nécessaire pour déplacer les tâches entre les postes de travail.

Les exigences particulières des applications FCS sont prises en compte par l'incorporation dans Simio de fonctionnalités qui répondent spécifiquement aux besoins des FCS. Ces fonctionnalités incluent la prise en charge d'ensembles de données de travail définis en externe, ainsi qu'une modélisation très souple des ressources et des matériaux. Bien que ces fonctionnalités soient spécifiquement conçues pour libérer toute la puissance de modélisation de Simio pour les applications FCS, elles sont également utiles dans les applications de modélisation générales.

Un ensemble de données de travail Simio permet de définir en externe une liste de travaux à traiter par le modèle de simulation. Les travaux sont définis dans un ensemble de données contenant une ou plusieurs tables, avec des relations définies entre les colonnes des tables. Le schéma spécifique des données relatives aux travaux est arbitraire et peut être défini par l'utilisateur pour correspondre au schéma des données de fabrication (par exemple, un système ERP). Les données relatives aux commandes comprennent généralement les dates de lancement et d'échéance, les routages, les temps de préparation et de traitement, les besoins en matériaux, ainsi que d'autres propriétés pertinentes pour le système concerné. Les objets de Simio peuvent faire directement référence aux valeurs spécifiées dans l'ensemble des données de la commande (par exemple, le temps de traitement) sans connaître le schéma qui a été mis en œuvre pour stocker les données.

Tout objet dans Simio peut servir de ressource capacitée et peut avoir son propre comportement indépendant. Les ressources peuvent être sélectionnées à partir d'une liste basée sur des règles flexibles telles que le temps de changement minimum ou le temps d'inactivité le plus long. . Les ressources supportent également des règles très flexibles (date d'échéance la plus proche, moindre marge de manœuvre restante, ratio critique, etc.) pour choisir entre des tâches concurrentes qui attendent de s'emparer de la ressource. Enfin, l'historique de l'utilisation des ressources peut être affiché sur un diagramme de Gantt interactif.

L'élément Matériaux de Simio fournit un support direct pour modéliser les choses qui peuvent être consommées et produites pendant l'exécution du modèle. Les matériaux peuvent également être définis de manière hiérarchique pour modéliser une nomenclature traditionnelle pour les applications de fabrication. Ainsi, une étape de fabrication peut être modélisée comme la consommation d'une liste spécifique de matériaux au sein de la nomenclature hiérarchique.

11. Résumé

Simio est un nouveau cadre de modélisation basé sur les principes fondamentaux de la modélisation orientée objet. Il est unique en son genre pour les raisons suivantes :

  1. Le cadre de Simio est un cadre de modélisation graphique orienté objet, par opposition à un simple ensemble de classes dans un langage de programmation orienté objet qui sont utiles pour la modélisation de simulation. Le cadre de modélisation graphique de Simio prend entièrement en charge les principes fondamentaux de la modélisation orientée objet sans nécessiter de compétences en programmation pour ajouter de nouveaux objets au système.
  2. Le cadre de Simio est neutre du point de vue du domaine et permet de construire des objets qui soutiennent de nombreux domaines d'application différents. Les fonctions de modélisation des processus de Simio permettent de créer de nouveaux objets au comportement complexe.
  3. Le cadre de Simio prend en charge plusieurs paradigmes de modélisation. Il prend en charge la modélisation de systèmes discrets et continus, ainsi que la modélisation d'événements, de processus, d'objets et d'agents.
  4. Le cadre Simio fournit des caractéristiques spécialisées pour soutenir directement les applications d'émulation et d'ordonnancement à capacité finie qui exploitent pleinement les capacités générales de modélisation de Simio.

Références :

  • Gordon, Geoffrey, 1960 25 octobre. A general purpose systems simulator. (Manuel non publié.) White Plains, N.Y. : IBM. Corp. ASDD Commercial Dept.
  • Henriksen, J. O. 1976. Building a better GPSS : a 3:1 enhancement. In Proceedings of the 1975 Winter Simulation Conference, 465-469. New Jersey : AFIPS Press
  • Markowitz, H., Hausner, B., et Karr, H. SIMSCRIPT : A simulation programming language, Prentice Hall, Englewood Cliffs, N. J. 1962
  • Nygaard, K et O-J Dahl, . SIMULA -An Extension of ALGOL to the Description of Discrete-Event Networks, présenté à la deuxième conférence internationale sur le traitement de l'information (1962).
  • Pegden, C. D. et A. A. B. Pritsker (1979). SLAM : Simulation Language for Alternatives Modeling. Simulation, Vol. 33, No. 5.
  • Pegden, C. D. (1982). Introduction à SIMAN. Systems Modeling Corporation.
  • Pegden, C. D. et D. A. Davis (1992) Arena : a SIMAN/Cinema-based Hierarchical Modeling System ; In Proceedings of the 1975 Winter Simulation Conference 390-399
  • Pritsker, A. A. B. 1967. GASP H User's Manual. Arizona State University.