Intégration dans l’architecture de commande

Nous allons désormais aborder l’intégration physique de notre module d’aide à la décision dans l’architecture de commande du système. Nous avons vu au chapitre précédent que celui-ci se situait au même niveau CIM que le MES, c’est-à-dire au niveau de l’exécution. Nous allons détailler ici les solutions techniques qui ont été mises en place pour assurer les communications entre les différents éléments de l’architecture.

La Figure 41 présente un diagramme de séquence UML représentant les communications entre les éléments de l’architecture de commande nécessaires à une simulation en ligne. Sur ce diagramme sont représentés chronologiquement les différents messages échangés par les acteurs de cette simulation. Le MES initie la simulation en en référant au simulateur. Celui-ci demande à l’observateur de lui fournir son état, tout en interrogeant la base de données du MES pour obtenir les données de production actuelles du système. Lorsque l’observateur acquitte la création des fichiers contenant son état, le simulateur peut aller les consulter. Lorsqu’il a toutes les informations à disposition, le simulateur peut débuter les réplications qu’il a à effectuer. Lorsque toutes les simulations sont terminées, le simulateur communique les résultats au MES.

Figure 41 Diagramme de séquence UML représentant les communications entre les éléments de l’architecture de commande nécessaires à une simulation en ligne

IV.3.1 Le simulateur

Le simulateur en tant que tel est finalement partie intégrante du MES, comme peut l’être la base de donnée par exemple. De ce fait, il est préférable d’utiliser les moyens de communication déjà existants au sein du MES. Le simulateur doit être capable de communiquer à trois niveaux au sein de l’architecture :

- Une communication avec la base de données, qui se fera entièrement par requêtes SQL ;

- Une communication par fichiers communs avec l’observateur, détaillée dans le prochain paragraphe ;

- Une communication avec les autres composantes de l’architecture sous forme de questions/réponses/acquittement pour permettre de déclencher simplement les calculs et autres routines.

Pour cette dernière communication, nous avons majoritairement utilisé les Sockets Windows, globalement acceptées par la plupart des logiciels du commerce (MES et simulation). La Socket Windows, ou plus couramment appelé Winsock, est une interface d’application procurant des fonctions d'accès aux protocoles réseaux, permettant donc l'utilisation du protocole TCP/IP sur une interface Windows. Winsock 2.0 fournit deux interfaces de programmation. La première, qui est celle qui nous intéresse, est appelé API

sd Lancer_Simulation

: MES : Simulateur : Observateur

Demander_simulation() Communiquer_Résultats() Demander_état() Acquitter_état_disponible() Créer () : Fichiers d’état Interrogation_BdD() Obtention_informations() Demander_état() Récursion Obtention_état ()

(Application Programming Interface) par opposition à l’interface SPI (Service Provider Interface). Elle se situe en couche 5 du modèle OSI (Figure 42) et utilise donc un protocole de couche 3 et 4 pour véhiculer ses informations à travers un réseau.

Figure 42 Le modèle OSI dans une configuration à deux hôtes du même sous-réseau

IV.3.2 L’observateur

L’observateur a deux caractéristiques : être synchronisé avec le système réel et communiquer son état à l’application de simulation. Il aura donc deux communications à établir.

Pour la communication avec le simulateur, nous proposons une communication double : une socket TCP/IP permet de transmettre la demande du simulateur, et l’acquittement de l’observateur, alors qu’une communication par fichiers communs permettra de faire transiter les données sur l’état, qui représentent une masse plus importante. Nous avons choisi ici de ne traiter que de simples fichiers type texte du fait de son universalité (la majorité des logiciels savent lire et écrire dans des fichiers type texte) et de la structure simple des données à transmettre. Si la masse de données se complexifie et qu’un traitement plus approfondi de ces données est nécessaire, il pourrait être préférable d’utiliser des structures type XML ou un transit via la base de données du MES.

Pour la communication avec le système réel, nous proposons d’utiliser le standard OPC. La norme OPC, qui signifie OLE for Process Control, est une norme industrielle qui fournit une interface commune de communication permettant à des logiciels indépendants de partager et d’échanger des données. Cette norme est supportée par une fondation,

Application Présentation Session Transport Réseau Liaison de données Physique 7 6 5 4 3 2 1 Hôte A Application Présentation Session Transport Réseau Liaison de données Physique Hôte B Routeurs Routeurs Frontière de sous-réseau Protocole de transport Protocole de session Protocole de présentation Protocole d’application

soutenue par de nombreux grands acteurs industriels2. L’objectif d’OPC est de créer une véritable interopérabilité entre différents équipements industriels issus de plusieurs fournisseurs différents sur un réseau Windows [Santos et al., 2005].

La communication sous OPC est réalisée avec une architecture type client/serveur, notre serveur utilisant les communications Microsoft DCOM. Le serveur OPC est la source des données et n’importe quelle application basée sur OPC peut y accéder pour lire/écrire toute variable fournie par le serveur (Figure 43). Ceci constitue une solution simple, ouverte et efficace au classique problème de compatibilité entre drivers propriétaires, puisque presque tous les principaux constructeurs mondiaux de systèmes de commande, d’instrumentation et de systèmes de supervision incluent OPC dans leurs produits.

Figure 43 OPC facilite la communication entre les équipements bas niveau, les bases de données et les applications dédiées [Zamarreño et al., 2000]

Plusieurs outils existent permettant de programmer un client OPC. La plupart sont basés sur l’utilisation de bibliothèques de liens dynamiques (dll pour Dynamic Link Library) programmées en C++, généralement fournies avec le serveur. Nous avons choisi comme serveur OPC Factory Server, logiciel propriétaire de Schneider Electric nous permettant une configuration très rapide de la communication avec les automates de la même marque.

L’observateur a été réalisé à partir de deux logiciels différents. L’un d’entre eux, Arena, permet une intégration immédiate d’un client OPC via son interface Visual Basic for Applications (VBA). Les dll sont directement intégrées et la programmation par évènement est très bien adaptée à notre problème.

Le second logiciel, Quest, a une interface de communication basée sur la lecture/écriture dans des fichiers ou par socket TCP/IP. Il n’est donc pas possible de directement intégrer les évènements OPC à la programmation. La solution que nous avons

élaborée a été de construire un logiciel intermédiaire en Visual Basic (VB) communiquant classiquement avec le serveur OPC et fournissant les informations au simulateur via des sockets TCP/IP.

Que ce soit avec un logiciel ou avec l’autre, notre client est donc toujours programmé en VB (ou VBA), seule l’interface entre cet intermédiaire et l’observateur diffère un peu selon que le langage est directement intégré au logiciel ou non (Figure 44).

Figure 44 Différences d’intégration des contenus OPC pour deux observateurs réalisés sous Arena et sous Quest

IV.3.3 Performance de la remontée d’informations depuis l’atelier

Nous avons cherché à savoir quelles étaient les performances temporelles que nous pouvions attendre d’une telle architecture de remontée d’informations basée autour d’un