Impact de l’Architecture de Simulation

Nous allons étudier quelles perturbations peuvent être engendrées par l’ajout des éléments de l’environ-nement de simulation au modèle de l’Architecture Opérationnelle. En effet, il serait fort dommageable d’avoir modélisé correctement l’Architecture Opérationnelle et que ces ajouts perturbent la simulation ou les performances observées. Ces perturbations peuvent affecter l’évaluation de performance au tra-vers de la simulation elle même ou en polluant les indicateurs de performance mesurées. Nous étudie-rons dans un premier temps, l’impact de l’introduction des générateurs de jetons et dans un deuxième temps, l’impact des observateurs.

3.5.4.1 Impact des générateur de jetons Les générateurs sont-ils non-invasifs ?

Les modèles des générateurs étant externes au modèle de l’architecture Opérationnelle, il n’y a pas de modifications de comportement par l’adjonction des générateurs. Toutefois, les générateur de jetons peuvent avoir un effet néfaste si les périodes de génération de jetons sont corrélées aux temps internes

Figure 79 : Implantation des générateur d’événements et des modèles PO

API2 API3 API1 RX1 RX2 API5 API4 T3 T1 T2 Générateur & Modèles Partie Opérative INAPI INEXT d’événements

des équipements matériels. Le choix de ces périodes ou de la méthode de stimulation est donc très importante.

Les générateurs ont-ils un impact sur le temps de simulation ?

Les générateurs de jetons introduisent de nombreux franchissements de transition, et donc de jetons, dans le modèle. Le modèle va donc voir son nombre de jetons croître au cours de la simulation, ce qui a pour effet de faire croître le temps de simulation de façon très importante. Cette augmentation du temps de simulation a une allure exponentielle due à l’augmentation de jetons à gérer à chaque pas de l’hor-loge temporelle de simulation. Cette croissance dure jusqu’à ce que la mémoire vive (RAM) soit pleine. Au delà de cette limite, c’est la mémoire SWAP qui prend le relais, ce qui implique des temps d’accès mémoire beaucoup plus important donc une «explosion» du temps de simulation. Il est de plus néces-saire de contrer l’augmentation du nombre de jetons dans le modèle, car les jetons qui permettent d’observer une réponse après stimulation finissent dans une place et ne sont plus jamais utilisés. Nous avons donc créés des «absorbeurs» de jetons dont l’intérêt est de maintenir un nombre fini de jetons dans les modèles réseaux de Petri. Effectuons une comparaison entre un modèle muni d’un seul généra-teur de jetons et un modèle qui génère et absorbe les jetons (fig. 80).

Le nombre de jetons augmente au fur et à mesure que la simulation se déroule pour le modèle figure 80a alors que le nombre de jetons reste constant dans le modèle figure 80b. Les temps de simulation résul-tants sont représenté sur la figure 81 et montrent la pertinence des absorbeurs.

Figure 80 : Modèles pour l’étude de l’impact des absorbeurs

Figure 81 : Temps de simulation avec ou sans absorption de jetons

a - Modèle sans absorbeur b - Modèle avec absorbeur

color NRM = with e timed; 1‘e NRM NRM 1‘e 1‘e NRM NRM e e e e _e e @+1 PI PO PO PI T T Déclarations globales e durée de simulation Nombre de franchissements (en s)

3.5.4.2 Impact des observateurs Les observateurs sont-ils non-invasifs ?

Étant donné que les observateurs sont des codes ML associés à des transitions du modèle RdP de l’Architecture Opérationnelle, il n’y a donc pas de modification de la structure RdP du modèle. De plus, nous nous sommes interdit toute action sur la production de jetons lors du tir des transitions dans les codes associés aux observateurs ce qui nous garanti une véritable indépendance entre les observateurs et le comportement modélisé. Il n’y a donc aucune modification du comportement par l’adjonction des générateurs.

Les observateurs ont-ils un impact sur le temps de simulation ?

Il convient d’étudier l’impact des codes ML sur le temps de simulation. Pour ce faire, nous étudions dans un premier temps l’influence des codes de calculs puis du code qui va inscrire dans un fichier la mesure effectuée.

Les codes associés aux transitions permettent de réaliser des calcul. Nous les avons utilisés afin de rem-placer des structures places/transitions qui peuvent parfois être très lourdes. Mais quel est leur impact au niveau du temps de simulation ? Pour répondre à cette question, nous avons comparé un modèle sans code avec absorbeur (figure 80b) avec un modèle similaire auquel on associe un code à la transition T. Plusieurs opérations ont été utilisées dans ces codes :

- opérations sur entiers : addition, multiplication, modulo; on examinera aussi le temps induit par la répétition d’une même opération (dans notre cas, l’addition);

- opérations sur fonction interne : time( ) ; on utilise la fonction InfInt.toInt( ) pour convertir le résultat de la fonction time( ) en un entier.

Comme l’indique la figure 82, les durées d’exécution sont quasiment identiques, nous pouvons donc conclure que la durée d’un calcul est négligeable par rapport à la durée de franchissement d’une transi-tion.

Maintenant que nous avons évalué l’impact des codes de calculs au niveau du temps de simulation, il reste à évaluer l’impact du code permettant l’écriture dans un fichier; une fois cette étude effectuée, nous pourrons en conclure quant à l’impact des observateurs sur le temps de simulation. Afin de déter-miner cet impact, nous avons simulé un modèle qui, à chaque franchissement de sa transition, exécute le

Figure 82 : Temps de simulation pour divers codes de transition

0 100 200 300 0 250 500 750 1000 sans code code A+B 10*(A+B) Code Time code A*B Code A mod B durée de simulation (en s)

Nombre de milliers de franchissements

code qui écrit (ouverture, écriture et fermeture) dans un fichier un entier qui est incrémenté entre chaque franchissement. On obtient les mesures suivantes :

En observant la figure 83, on remarque que le temps nécessaire à l’écriture de données dans un fichier est d’environ deux fois le temps de franchissement d’une transition. Toutefois, étant donné que l’écri-ture de données n’est réalisée que sur le tirage d’un petit nombre de transitions et qu’en plus ces transi-tions ne sont franchies que rarement, on peut conclure que l’impact au niveau du temps de simulation est négligeable.

3.6 Conclusion

Dans ce chapitre, nous avons montré que :

- Les tâches composant l’Architecture Fonctionnelle sont modélisées en grande partie de manière générique et nous avons proposé des approches de modélisation pour les tâches ayant un compor-tement spécifique ;

- Le modèle de l’Architecture Matérielle se construit à l’aide de composants existant que l’on con-necte aisément suivant deux méthodes proposées (fusion de places ou connexion structurelle) ; - Le modèle de l’Architecture Opérationnelle est réalisée par le biais de l’association des tâches

fonctionnelles aux équipements de traitement par la même méthodologie que pour la construction de l’Architecture Matérielle et par la fonction de routage de l’information dont la conception est facilitée par la définition des tables de routages ;

- L’Architecture de Simulation est obtenue en complétant le modèle de l’Architecture Opération-nelle par des générateurs de stimuli et des observateurs. Pour chacun de ces modèles, nous propo-sons plusieurs variantes afin que l’architecte puisse choisir selon ses besoins.

L’ensemble de ces aides permet à l’architecte d’être accompagné durant chacune des phases composant la modélisation du comportement dynamique de son architecture de contrôle-commande en vue de l’évaluation de ses performances. Cependant, l’architecte peut ne pas disposer dans sa bibliothèque de modèle correspondant à l’équipement qu’il souhaite inclure dans son architecture. C’est pourquoi nous décrivons dans le chapitre suivant un ensemble de méthodologies de conception et de validation de modèles d’équipements matériels.

Figure 83 : Temps de simulation avec un code d’écriture dans un fichier

0 250 500 750 1000 0 250000 500000 750000 1000000 sans code code Fichier durée de simulation (en s)

Nombre