Serveur OPC Base de donnéesSupervision

Aide à la décision

MES

Observateur

Pupitres, capteurs, butées, verrines, etc… Modules de lecture/écriture

FipIO

Communications Ethernet Autres Communications Liaisons série, électriques, etc.

Figure 55 Implantation matérielle de la solution

Les principaux critères permettant d'apprécier la qualité de service sont les suivants : - Débit (en anglais bandwidth), parfois appelé bande passante par abus de langage : il

définit le volume maximal d'information (en bits) transmis par unité de temps ; - Gigue (en anglais jitter) : elle représente la fluctuation du signal numérique, dans le

temps ou en phase ;

- Latence, délai ou temps de réponse (en anglais delay) : elle caractérise le retard entre l'émission et la réception d'un paquet ;

- Perte de paquet (en anglais packet loss) : elle correspond à la non-délivrance d'un paquet de données, la plupart du temps due à un encombrement du réseau ;

- Déséquencement (en anglais desequencing) : il s'agit d'une modification de l'ordre d'arrivée des paquets.

Supervision Serveur OPC Serveur SQL Observateur Simulateur Automate 2 Automate 3 Automate 4 Automate 1 Réseau Ethernet (isolé dans un VLAN)

Le critère de latence nous intéresse particulièrement dans la comparaison des deux utilisations d’Ethernet [Koubâa et Song, 2002]. En effet, il est souvent primordial d’assurer une latence de l’ordre de la milliseconde entre deux automates dont les temps de cycle sont de cet ordre, ou entre deux commandes de robots se déplaçant à grande vitesse. Or, le trafic bureautique, si les deux réseaux sont communs, a tendance à charger les routeurs de manière très irrégulière. En effet, sur un réseau Ethernet, même commuté, il est nécessaire d’avoir des trames de diffusion (que ce soit en multicast ou en broadcast) qui créent un volume de trafic très important. De ce fait, les chemins de données évoluent sans cesse, ce qui ne permet pas de garantir de latence maximale compatible avec l’utilisation pour la commande de systèmes automatisés.

D’un autre côté, utiliser Ethernet rend possible l’ouverture des systèmes de production sur le monde de l’internet. Isoler physiquement le réseau de commande interdirait cette ouverture, ce qui est dommageable. Nous avons choisi d’isoler logiciellement notre application à l’intérieur d’un VLAN. Un VLAN (Virtual Local Area Network ou Virtual LAN, et en français Réseau Local Virtuel) permet la réalisation de sous-réseaux indépendants, isolés les uns des autres de manière logique (logicielle) et non physique, sans contrainte géographique. Cela permet une plus grande segmentation du réseau, basée sur des critères de ports, d’adresse MAC, etc. Les VLAN sont définis par les normes IEEE 802.1D, 802.1p, 802.1Q et 802.10.

Grâce à l’utilisation d’un VLAN englobant notre système de production, nous avons un trafic maitrisé entre les automates et les quelques ordinateurs servant à la commande du système. Toutefois, nous avons également la possibilité d’ouvrir notre système aux applications internet, telles que la commande ou la surveillance à distance de nos équipements. De plus, cette technologie permet l’ajout d’une communication spécifique entre les différents réseaux d’entreprise, par exemple entre les logiciels dédiés à l’horizon stratégique et le MES.

IV.7 Le module d’aide à la décision

Le déroulement d’une simulation en ligne dans notre application est décomposable en 10 étapes :

1. L’opérateur entre ou modifie le paramétrage d’un nouvel ordre de fabrication, dont fait partie le paramétrage de la durée de décision ;

2. À la sauvegarde de cet ordre dans la base de donnée, le MES détecte une modification dans la table des ordres ;

3. Le MES vérifie que la durée de prise de décision est compatible avec les durées de simulation. Dans le cas contraire, celui-ci bloque le processus et affiche un message d’erreur en attente d’une modification de l’opérateur ;

4. Le MES bloque la modification des ordres de fabrication de la table puis ordonne au simulateur une simulation démarrant à la date actuelle avec un horizon courant jusqu’à complétion de tous les ordres présents dans la table ;

5. Le simulateur demande l’état actuel de l’atelier à l’observateur ;

6. L’observateur stocke son état dans des fichiers de données et renvoie un acquittement au simulateur ;

8. Pendant la simulation, la date de fin de chaque ordre de fabrication est enregistrée dans une table de la base de données ;

9. À la fin de la simulation, la simulation envoie un acquittement au MES ;

10. Le MES affiche les données de la base de données dans la fenêtre de paramétrage des ordres et autorise de nouveau la modification de la table des ordres.

Les étapes 2 à 10 sont totalement automatisées et ne sont que les phases de calcul du scénario entré par l’opérateur. De ce fait, elles sont totalement invisibles pour l’utilisateur final, qui n’a que l’utilitaire de supervision du MES à manipuler. Cela permet de mettre la simulation en ligne à disposition de tous les acteurs de la production, spécialistes ou non de la simulation.

De plus, les essais que nous avons réalisés sur la chaine flexible permettent de réaliser ces étapes en environ 5 secondes, décomposables en :

1. Communication MES – Simulateur : durée négligeable ;

2. Récupération des données de l’état de l’observateur et des données de production sur la base de données : 1 seconde environ ;

3. Initialisation et simulation : 4 secondes environ ;

4. Communication des résultats au MES : durée négligeable.

Ces résultats nous permettent d’envisager une utilisation suffisamment ergonomique pour être d’ores et déjà utilisables. Pour une utilisation industrielle, le modèle de simulation peut de plus être optimisé, ce qui réduirait encore les temps de calcul.

IV.8 Conclusion

Ce chapitre nous a permis de présenter l’application de simulation en ligne que nous avons développée. Après avoir présenté la chaine flexible d’assemblage qui nous a servi de support, nous avons pu détailler les modélisations successives de chacun des modèles utilisés, puis leur intégration dans l’architecture de commande du système.

L’application que nous avons développée concerne l’aide au gestionnaire de production dans le lancement d’un nouvel ordre de production sur le système. Le module d’aide à la décision permet de calculer les dates de fin estimées de chaque ordre déjà en production et de celui que le gestionnaire veut tester. Ainsi, celui-ci peut étudier l’influence du paramétrage de cet ordre sur le comportement global du système.

Cette application nous a permis de valider l’applicabilité des concepts que nous avons développés dans les chapitres précédents, autant sur l’aspect technique que sur l’aspect d’ergonomie d’utilisation au vu des durées mises en jeu.