Préparation de la simulation

Un système de commande en «fonctionnement» est couplé à un système contrôlé et de plus avec son process il n’est pas «isolé» mais est soumis à des stimuli extérieurs tels que des lancements de produc-tion, des demandes de suivi, … Afin d’avoir une simulation réaliste du comportement du modèle précé-demment obtenu, il est donc nécessaire de le compléter avec un modèle du système contrôlé ainsi qu’un

Figure 37 : Exemple de routage d’une information

Figure 38 : Définition des routages d’informations dans la page de déclarations globales

KMVE KMVG2 KMVG1 AV pu pi tr e AP3 AP1 AP2 maître esclave esclave

T2

T1

T3

T2

T1

function dest (x, so) {case so of 1 => (case x of KMVG1 => 0 | KMVG2 => 0) | 2 => (case x of KMVE => 0) | 3 => (case x of AVG => 1 | AVE => 2);

modèle des interactions avec l’extérieur. Nous appellerons «environnement de simulation» ces modèles complémentaires.

De plus, il nous faut évaluer les performances de type temps de réponse de notre modèle. Or le logiciel que nous avons choisi n’est pas un logiciel exécutant un langage de simulation mais un joueur de réseau de Petri. Cela implique que la gestion de l’échéancier, la mise en file ou le tirage de variables aléatoires sont gérés par Design/CPN mais que l’observation des performances nécessite de compléter le modèle avec des observateurs.

L’Architecture Opérationnelle ainsi enrichie d’un environnement de simulation et d’observateurs sera appelée par la suite Architecture de Simulation.

2.3.6.1 Modélisation de l’environnement de simulation

L’environnement de simulation se compose du modèle du système à contrôler et du modèles des stimuli extérieurs.

De nombreux travaux de recherche portent sur la modélisation de la Partie Opérative (PO) comme ceux de José Machado [MACHADO & al 2003], Véronique Carré Ménétrier [PHILIPPOT & al 2004] ou David Gouyon [GOUYON & al 2004]. Mais les performances que nous souhaitons évaluer portent sur le contrôle-commande et non sur le système dans son intégralité. Ainsi, les délais mesurés correspon-dent à des informations qui ne parcourent que l’Architecture Opérationnelle et non la PO.

Figure 39 : Modèles des Architectures Opérationnelles

Figure 40 : Routages des informations

a - Configuration 3 API b - Configuration 2 API + 1 terminal

a - Configuration 3 API b - Configuration 2 API + 1 terminal

function dest (x, so) {case so of 1 => (case x of KMVG1 => 0| KMVG2 => 0) | 2 => (case x of KMVE => 0) | 3 => (case x of AVG => 1| AVE => 2);

function dest (x, so) {case so of

1 => (case x of AVG => 1 | AVE => 2 | KMVG1 => 0| KMVG2 => 0) | 2 => (case x of KMVE => 0);

Toutefois, la charge de l’Architecture Opérationnelle est elle fortement dépendante des interactions qu’elle aura avec la PO. La finesse du modèle de cette dernière correspondra donc à la finesse de la charge que l’on voudra associer aux différents équipements du contrôle-commande. Si l’équipement matériel est parcouru par une des informations relatives aux performances étudiées, il est nécessaire d’avoir une description réaliste de la charge de cet équipement (l’Annexe C propose une approche de modélisation d’éléments de la Partie Opérative). Dans le cas contraire, une description synthétique suf-fit amplement (délais constants ou tirés à partir d’une loi de répartition (fig. 41)).

Dans la suite du document, nous modéliserons de manière synthétique le comportement de la PO afin de nous concentrer la modélisation de l’architecture de contrôle-commande.

En ce qui concerne les stimuli, seuls les informations observées pour les performances ou les informa-tions participant à la charge des équipements matériels doivent être modélisés (par exemple, un réseau peut avoir un comportement différent si on étudie le temps de transmission d’un événement seul ou d’un événement parmi un ensemble d’informations transitant par ce media).

Le principe de fonctionnement du modèle d’un générateur d’événement stimulus, consiste à placer régulièrement des jetons événement dans une place d’entrée du modèle de l’Architecture Opération-nelle. Ce générateur peut être périodique, aléatoire (la période de génération des jetons est choisie à l’aide d’une fonction de génération de nombres aléatoires) ou selon une progression mathématique (suite arithmétique, géométrique, …). Mais la structure de ce générateur reste globalement identique (fig. 42).

Figure 41 : Exemple de modèle de Partie Opérative

Figure 42 : Exemple de générateur d’événements Débuter Production P.O. Δt Lancer Production Emettre Message Fin_Prod

Message Fin de Production

1‘(Fin_Prod, 0, 1) VII VII IN_EXT IN_API P.O. @+Δt 1‘(Debut_Prod, 1, 0) Debut_Prod 1‘(x, 0, 1) x VRG VII RESS_GEN IN_API T1 @+DGenAV DP x 1‘Debuter_Production

DGenAV : période de génération cible matérielle du générateur d’événement

2.3.6.2 Modélisation des observateurs

Une fois les modèles des générateurs d’événements et du processus ajouté au modèle de l’Architecture Opérationnelle, la simulation peut être réalisée dans un contexte cohérent avec le futur fonctionnement du contrôle-commande. Mais pour juger des performances de l’architecture, il est nécessaire d’être capable d’observer l’évolution des paramètres devant être évalués durant cette simulation.

Le logiciel de simulation propose des fichiers traces (log files) de la succession des évolutions du modèle simulé. Cette fonctionnalité ne discernant pas les événements pertinents des événements non pertinents, elle génère des fichiers de taille démesurés (plusieurs Giga-octets) et pénalise le temps de simulation. Dans un soucis d’améliorer les performances de simulation, il est préférable de particulari-ser l’obparticulari-servation du modèle simulé.

Étant donné que les performances que nous étudions dans ce chapitre sont temporelles, nous devrons donc mesurer des temps de réaction ou des temps de transmissions d’informations. Nous utiliserons pour cela des observateurs en deux parties :

- la partie observant le début d’une transmission à évaluer pour en mémoriser la date ; - la partie observant les effets d’une transmission pour en calculer la durée de transmission.

Nous utiliserons une possibilité du logiciel Design CPN, qui permet d’associer à une transition un code ML (de l’anglais Meta Langage, c’est un langage de programmation généraliste fonctionnel). Ce code est exécuté à chaque tirage de la transition associée. Les codes observateurs permettent d’écrire des données dans des fichiers, il n’y a donc pas surcharge de la mémoire avec les données observées au cours de la simulation. Le code observateur doit donc permettre de mesurer le temps Δt entre un

événe-ment Ev et sa réaction Re.

Dans le cas de notre exemple, il nous faut mesurer les délais entre la demande d’arrêt et les actions effectives sur les vannes correspondant pour vérifier si ces délais sont conformes par rapport au cahier des charges. Il est possible de faire une unique simulation avec tous les observateurs ou de faire diverses simulations avec à chaque fois une performance à observer. Sachant que la simulation est la partie qui est la plus consommatrice de temps, nous choisirons de placer les observateurs de toutes les performan-ces à évaluer sur un même modèle pour faire une unique simulation.

On doit déterminer les informations qu’il faut observer dans le modèle pour étudier les performances attendues. L’événement à observer étant l’apparition de l’information AV, les réactions attendues sont les sorties KMVG1, KMVG2 et KMVE. Sachant que KMVG1 et KMVG2 sont deux sorties d’un même automate programmable et qu’elles sont émises par une même tâche, le décalage temporel entre les deux sera négligeable (une simulation pourrait le mettre en évidence), donc nous n’observerons qu’une seule des deux (KMVG1).

L’observateur d’événements ne fera que noter la date d’occurrence de l’événement et les observateurs des réactions noteront les dates des réactions correspondantes. Le dernier arrivé écrira dans le fichier les trois données : date de début, date de fin gaz et date de fin électricité. Pour savoir lequel est le dernier arrivé, on utilisera la variable booléenne PremierArrive.

On a donc trois observateurs : le premier (début de mesure) doit être placé pour permettre la détection de l’apparition de l’événement AV, il doit donc être placé dans la transition du générateur de jetons AV (fig. 43).

Les deux observateurs de réactions se placent dans les transitions correspondant aux cartes de sorties des Automates programmables (fig. 44).

Le code de l’observation de la réaction KMVE est similaire à celui de la figure 44, sauf qu’il faut rem-placer le code indiqué en italique (KMVG1 par KMVE et TfinGaz par TfinElec).

Nous disposons ainsi d’une technique d’observation des événements pertinents qui maintien un bon niveau de performance à la simulation tout en produisant un fichier trace très simple à exploiter.

2.3.7 Simulation et présentation des résultats obtenus