EXTENSION D’UNE ARCHITECTURE CANOPEN SUR SERVEUR OPC DA

SOMMAIRE

  1. INTRODUCTION
  2. CANopen
  3. etc…

1. INTRODUCTION

Durant ce projet, nous allons devoir compléter l’architecture d’un serveur OPC DA. Ce serveur OPC existant déjà, nous allons y ajouter des équipements CANopen que nous allons pouvoir superviser à distance. Pour cela, nous avons différentes tâches à effectuer pour pouvoir finaliser le projet.
Tout d’abord, il faut savoir que nous allons utiliser le logiciel Automation Studio qui est un logiciel de conception de circuits, de simulation et de documentation de projets. Nous utiliserons également le logiciel InTouch nous permettant de faire de la supervision industrielle et de commander notre système à distance.

2. CANopen

Le protocole CAN, initialement créé pour le marché de l’automobile, est un Bus qui priorise les messages sans altérer ou détruire la requête. Il intègre la 2ème couche du modèle OSI alors que la plupart des protocoles se limitent à la 1ère couche.
Ensuite, nous allons mettre en place le module CANopen sur notre système et le paramètrer. CANopen permet de garder un profil standard dans les systèmes de contrôle industriel. Il convient aux automates en temps réel car c’est une solution efficace destinée aux applications industrielles.
Sur ce module, nous allons y brancher quatre équipements de différents fabricants. Nous commencerons donc par un équipement d’un fabricant en le paramétrant pour le tester grâce au server OPC puis en y ajoutant une supervision. Nous répéterons cette opération avec 4 equipements (Entrée/Sortie) de 4 fabricants différents et un dernier équipement qui sera un variateur.

Représentation du modèle OSI pour les couches relatives à CANopen (couche 7). Les couches 1 et 2 étants relatives au bus CAN.
Le concept CANopen repose sur un dictionnaire d’objets renseigné par l’interface de communication et appliqué aux entrées/sorties de l’équipement.
Schéma de principe du serveur de communication multi-protocoles. Il échange des données avec le process via différents protocoles industriels (Ethernet et bus de terrain). Les clients, type supervision, peuvent visualiser et piloter les variables du serveur indépendamment des protocoles utilisés.
Concrètement, le serveur OPC multi-protocoles est un API B&R avec des coupleurs maîtres en CANopen, Profibus, ASI, IO-Link etc.
Voilà l’état du projet au départ. L’automate, via le réseau Powerlink, pilote un module d’extension déporté. Ce module dispose, à gauche, d’un coupleur CANopen Maître avec un 1er coupleur esclave (I/O B&R).
L’état du projet final fait apparaître 4 équipements supplémentaires
(WAGO, PROFACE, SCHNEIDER, ALTIVAR) en plus des I/O B&R