Évaluation de performances par mesure expérimentale

Afin de pouvoir confronter nos résultats d’évaluation de performance obtenus par simulation, nous allons réaliser une mesure expériementale des performances sur l’architecture opérationnelle réelle à l’aide de la plateforme expérimentale PRISME. Nous expliciterons dans ce paragraphe les différentes phases qui nous ont permit d’obtenir ces mesures de performances.

5.3.4.1 Configuration de l’Architecture Opérationnelle

Dans un premier temps, il nous est nécessaire de construire et configurer l’architecture de la même manière que notre modèle de simulation, sinon toute comparaison serait vaine. Ensuite, il faut implanter dans les différents automates programmables industriels l’ensemble des tâches de notre Architecture Fonctionnelle. Pour cela nous avons défini pour l’ensemble des cinq automates :

- les codes des tâches des chaînes critiques ;

- les codes des tâches non-critiques réalisant des charges réseaux ; - les codes des tâches non-critiques réalisant des charges CPU

Le codage a dû s’effectuer par le biais de trois plateformes de programmation différentes : STEP7 microwin pour S7-200, PL7pro pour les TSX Premium et les TSX Micro et PL707 pour le TSX Nano. De plus, il a été nécessaire de réaliser des procédures de communication variées (Maître => Esclave, Esclave => Maître, Esclave => Esclave) sur les différents automates (TSX Premium, Micro et Nano).

5.3.4.2 Configuration de la plateforme expérimentale PRISME

Une fois que l’Architecture Opérationnelle est correctement assemblée, configurée et programmée, nous devons tout comme pour nos modèles de simulation lui ajouter des générateurs de jetons et des observateurs afin de pour pouvoir mesurer ses performances.

Nous utiliserons la plateforme expérimentale PRISME qui comprend deux générateurs de signaux logi-ques, un analyseur logique (comportant 32 entrées) ainsi qu’un calculateur industriel (comportant 16 entrées et 8 sorties logiques) sous environement Linux. L’ensemble étant relié par une interface à une plateforme comportant l’architecture à étudier (fig. 128).

Le calculateur assure la génération du scénario (A1, A2, O1, O2, O3, T1, T2). Nous avons dû pour cela concevoir un programme générateur de scénarii selon la stratégie d’occurrences aléatoires à distribution uniforme correspond à celle des générateurs de jetons de notre modèle de l’Architecture de Simulation. La difficulté de conception d’un tel programme a été de maîtriser le temps au dixième de milliseconde avec un OS non temps réel (GNU/Linux). Nous avons opté pour une solution où la maîtrise du temps porte sur la distribution d’une population et non pas sur chaque individu. Le programme générateur écrit en langage Python à été validé par l’analyseur de signaux logiques de la plateforme PRISME. L’analyseur logique permet d’observer à la fois les signaux du scénario d’excitation et les effets de ce scénario. Puisque que la mémoire de l’analyseur est remplie en environ une minute d’observations, il nous est nécessaire de décharger les données régulièrement ; nous utiliserons pour cela le calculateur industriel. Un script d’enchaînement automatique des commandes a été réalisé de sorte que tant que le nombre d’acquisition est insuffisant, les opérations suivantes sont répétées :

- lancer l’acquisition sur l’analyseur logique ; - lancer le scénario d’excitation ;

- décharger les données de l’analyseur logique ;

- pré-traiter et sauver les données sur le disque dur du calculateur. 5.3.4.3 Mise en oeuvre des expérimentations

L’analyseur de signaux logiques pose une contrainte technologique : sa capacité mémoire est remplie en environ 60 secondes de mesure. Cela se traduit par un temps moyen d’un cycle de mesure (acquisition, déchargement, traitement et sauvegarde) de 180 secondes.

Sachant que la durée moyenne entre deux occurences de l’alarme A1 est de 15 secondes, il y aura donc trois à quatre excitations IA1 observées pendant les 60 secondes de mesure. On considèrera le cas le plus défavorable c’est-à-dire 3 observations par cycle de mesure de 180 secondes.

Étant donné que notre objectif est d’atteindre les 16 000 occurences de l’alarme A1, on calcule la durée prévisionnelle qui est égale à 960 000 secondes, c’est à dire 11 jours 2 heures et 40 minutes.

Lors de la mise en service de l’architecture, il est apparu que l’un des API (le TSX37) subissait un stress de communication sensiblement trop important pour son coupleur de communication intégré à sa CPU. Cela a engendré des erreurs de communications qui nous ont obligées à réaliser un programme de détection et d’élimination automatique des mesures polluées.

Au final, la durée effective de la campagne de mesure aura été de 3 semaines. Durant ce laps de temps, auront été observées les excitations suivantes :

- 16 654 signaux d’alarme IA1, - 21 200 signaux d’alarme IA2, - 31 383 signaux d’ordre IO,

- 166 549 signaux transversaux IT1, - 113 945 signaux transversaux IT2.

5.3.4.4 Traitement et mise en forme des données mesurées

Les données brutes obtenues par le biais de l’analyseur sont des chronogrammes sous la forme de deux listes de valeurs :

- dates = [1.23, 1.75, 1.92, 2.09, 2.31, 2.62] - values = [2, 3, 1, 5, 4, 0]

Ces données brutes peuvent être représentées graphiquement comme l’indique la figure 129:

Afin, de déterminer les performances que l’on souhaite évaluer, il nous faut extraire les valeurs des temps de transmission à partir de ces histogrammes. Par exemple, pour l’alarme A1, il est nécessaire d’observer l’effet (bit 30 de l’analyseur logique) de la cause (bit 6 de l’analyseur logique) (fig. 130).

Il faut donc, pour tous les fronts montants du bit 6 (en rouge sur la figure 130), identifier le délai au bout duquel un front montant se produit sur le bit 30 (en bleu sur la figure 130). Un programme en langage Python permet d’extraire chaque délais sous la forme d’une liste : delai_A1 = [45.4, 68.5, …]. A partir de ces données, il est nécessaire, tout comme pour les données obtenues par simulation, de représenter les répartition des performances mesurées.

Figure 129 : Représentation graphique des mesures brutes

Figure 130 : Observation de A1 sur l’analyseur logique

___________________________ événements | | | | | (date) ^ v v v v v | _______________ bit0 |_____| |______________ <--+ |__________ | signaux bit1 | |_________________________ <--+-- binaires | ____________ | bit2 |________________| |______ <--+ ^ | | +---+----+---+----+---+---> temps (s) bits 1.23 1.75 1.92 2.09 2.31 2.62 <--- dates ^ | __________ _____ bit06 |_____| |__________| |__________ | __________ ____ bit30 |__________| |_________________| | +---+----+---+----+---+---+---+----> temps (ms) 2.7 8.3 53.7 58.3 100.7 120.2 170.2 180.7

Les mesures nous ont donc permis d’obtenir les répartitions suivantes :

Figure 131 : Répartitions de temps de réponses obtenus par mesure expérimentale

minimum = 49 ms moyenne = 98 ms maximum = 280 ms minimum = 62 ms moyenne = 123 ms maximum = 397 ms minimum = 52 ms moyenne = 99 ms maximum = 183 ms minimum = 65 ms moyenne = 110 ms maximum = 209 ms minimum = - 91 ms moyenne = + 11ms maximum = + 133 ms minimum = 112 ms moyenne = 211 ms maximum = 399 ms minimum = 127 ms moyenne = 218 ms maximum = 492 ms

Temps de transmission A1 Temps de transmission A2

Temps de transmission O1 Temps de transmission O3

Ecart de temps de transmission O1-O3