Bus de terrain - Supervision

07/01/2013
Publication 3EI 3EI 2010-60
OAI : oai:www.see.asso.fr:1044:2010-60:3320
DOI :

Résumé

Bus de terrain - Supervision

Métriques

2371
63
1.82 Mo
 application/pdf
bitcache://38a38fdf30eebfc5e218ef25c6923ae070d84515

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/1044:2010-60/3320</identifier><creators><creator><creatorName>J. Deprez</creatorName></creator><creator><creatorName>J. Maillefert</creatorName></creator><creator><creatorName>A. Juton</creatorName></creator><creator><creatorName>Jean-Louis Bianchi</creatorName></creator></creators><titles>
            <title>Bus de terrain - Supervision</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2013</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Mon 7 Jan 2013</date>
	    <date dateType="Updated">Mon 25 Jul 2016</date>
            <date dateType="Submitted">Mon 10 Dec 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">38a38fdf30eebfc5e218ef25c6923ae070d84515</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>18661</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

Bus de terrain et de supervision J. DEPREZ, IUT CACHAN J.L. BIANCHI, LYCEE VERSAILLES J. MAILLEFERT, IUT CACHAN A. JUTON, IUT CACHAN 1. Introduction L'enseignement des réseaux informatiques ne peut plus être abordé en 2010 suivant la même démarche pédagogique que celle qui était utilisée il y a une dizaine d'année. Ceci, bien sûr, du fait de l'évolution des technologies de communication mais aussi de la relation naturelle que les étudiants entretiennent avec ces technologies qui font partie intégrante de leur environnement. A titre d'exemple, les notions d'adresse IP, de routeur, de DHCP, sont faciles à expliquer aux étudiants habitués à se connecter à la "machin-box" de leur domicile ou au réseau WiFi de leur université. Mais cette relation, souvent basée sur une utilisation "plug & play" des équipements informatiques grand public, qui est dans l'ensemble remarquablement efficace, induit paradoxalement une déstabilisation et une grande naïveté devant les problèmes rencontrés lors de la mise en œuvres des réseaux locaux industriels. L'évolution technique des réseaux et des équipements entre lesquels ils assurent le dialogue estompe également la classique vision pyramidale du modèle CIM (Computer Integrated Manufacturing). La segmentation, confortable, des réseaux qui découlait de ce modèle (réseaux de terrain, d'atelier, d'entreprise) perd sa légitimité. L'actionneur et le capteur de base des années 90 laissent place à des composants intelligents qui résolvent au niveau de la cellule de production des calculs et des traitements qu'il était naguère nécessaire de déporter au niveau de l'atelier ou de l'usine. Ainsi, un variateur de vitesse est à même d'assurer localement la gestion de profils de position, couple ou vitesse. Ses attentes du monde extérieur seront limitées aux éventuelles modifications de paramètres de ces profils. Par contre, il mémorisera et rendra disponible à ce monde extérieur des informations directement exploitables par la supervision de fabrication, la gestion des stocks ou la maintenance préventive. De même les capteurs peuvent embarquer un calculateur qui assurera localement les procédures de diagnostic ou les algorithmes de traitement du signal. Enfin, certains protocoles jusqu'ici cantonnés à la supervision d'atelier ou d'entreprise sont maintenant capables de satisfaire les exigences du terrain, essentiellement grâce à l'augmentation de débit qui palie les faiblesses du protocole (Ethernet par exemple). Le choix du réseau ne s'est pas toujours fait dans le passé en liaison avec les standards communément éprouvés et validés par le milieu professionnel. L'enthousiasme des universitaires pour le séduisant protocole FIP dans les années 90 était sans rapport avec son impact industriel. Par ailleurs, certains réseaux propriétaires ne se justifiaient que par la prédominance de certains types d'automates dans les établissements d'enseignement. 1.1. La définition d'une application Entre la volonté de l'enseignant de donner à l'étudiant des notions sur les équipements qu'il va rencontrer dans sa vie professionnelle - et la pression des employeurs potentiels qui jugent naturel que l'étudiant soit familiarisé avec les technologies qu'ils utilisent - et la disponibilité d'un équipement de travaux pratiques, plusieurs phases sont nécessaires :  Le choix des réseaux à mettre en œuvre au milieu de la multitude de solutions présentes sur le marché. Comme en entreprise, ce choix sera souvent tributaire du matériel existant déjà dans le laboratoire, l'interopérabilité restant du domaine de l'hypothèse. On tentera d'illustrer plusieurs familles de protocoles.  La définition, la réalisation ou l'adaptation d'une application suffisamment simple et fiable pour que l'étudiant puisse appréhender facilement le processus mis en œuvre, mais suffisamment complexe pour que l'implantation de réseaux Résumé : Après une analyse de l’évolution des réseaux locaux industriels, l’article propose une présentation d’un protocole orienté terrain (Canopen) et d’un protocole orienté supervision utilisant Ethernet (MODBUS TCP). A partir d’une application industrielle, une approche pédagogique conduite à l’IUT de Cachan(GEII) décrit un support d’étude et son exploitation pédagogique. locaux y trouve une justification. L'étudiant est difficilement convaincu par une application qui consiste à manipuler des interrupteurs pour allumer des LEDs.  La préparation logicielle de l'application, permettant à l'étudiant d'aborder, éventuellement en plusieurs séances, les notions de configuration, paramétrage, exploitation, analyse du réseau. Bien que les logiciels utilisés soient de plus en plus conviviaux, ils sont avant tout destinés à des professionnels qui, par métier, par analogie, savent décoder des notices que les étudiants, pendant le temps nécessairement limité passé au laboratoire, sont incapables d'exploiter à l'état brut. 1.1.1. Critères de performance Trois critères de performance sont décisifs quant au choix du réseau : déterminisme, rapidité, fiabilité. Un réseau est dit déterministe, si, pour une configuration matérielle donnée, on peut déterminer le temps maximal que prendra un message pour atteindre son destinataire. Ce critère peut être crucial dans les applications de contrôle temps réel. Le débit, exprimé en bit/s caractérise la capacité du réseau à transmettre des informations dans un temps limité. Pour les réseaux industriels il varie de quelques 10 kbit/s à quelques 100 Mbit/s. Le débit dépend du médium sur lequel circule l'information et de l'étendue du réseau. Ce critère sera primordial lors de l'échange de données volumineuses (images, fichiers de configuration par exemple). Le taux d'erreur quantifie la probabilité de réception d'un bit erroné, sans détection ni correction d'erreur. Il dépend de la robustesse électrique du réseau (immunité au bruit) et du protocole de gestion des erreurs. Les objectifs des réseaux de contrôle-commande sont de permettre :  la communication entre les organes de commandes (API) et la partie opérative (capteurs, actionneurs, pré-actionneurs)  la synchronisation et la communication entre organes de commande (intelligence répartie)  l'utilisation d'entrées-sorties déportées  les échanges avec les interfaces homme-machine (écrans tactiles) Ils permettent d'autre part :  de réduire les coûts de câblage (matériel et main d'œuvre)  de faciliter l'évolution et la maintenance de l'application  d’ajouter aux messages de processus, des messages liés à l’identification, à la surveillance et à la maintenance des équipements. Ils sont caractérisés par un débit relativement faible (messages courts), des exigences de temps réel (déterminisme, criticité des échanges) et une grande robustesse (faible taux d'erreur). Les équipements connectés proviennent souvent du même équipementier. Les réseaux de supervision (SCADA : Supervisory Control And Data Acquisition) ont pour but :  de permettre le téléchargement des paramètres, voire des programmes, nécessaires au fonctionnement des différentes parties du système  d'acheminer des informations de compte-rendu relatives à l'état des différentes parties du système  d'assurer le rafraîchissement périodique des informations nécessaire à l'appréhension globale du fonctionnement de l'application  de concentrer ces informations (base de données) en vue de leur exploitation par les logiciels de gestion de production (MES: Manufacturing Execution System) ou de gestion d'entreprise (ERP: Enterprise Resources Planning) Ils sont caractérisés par un débit relativement élevé (nombreux messages), peu d'exigence temps réel (il s'agit de compte rendus d'interventions, pas des interventions elles-mêmes). Les équipements connectés sont souvent hétérogènes. 1.1.2. Protocoles de communications Les protocoles d'acheminement des données se résument à deux grandes familles :  Échanges adressés de données : chaque nœud comporte une adresse. Les trames qui acheminent les données comportent deux adresses: l'adresse de l'émetteur de l'information et l'adresse du destinataire de l'information (exemple : Ethernet)  Échanges par diffusion de données: les trames qui acheminent les données comportent un identificateur propre à chaque donnée. Chaque nœud peut être consommateur et/ou producteur de données (exemple : CAN) Les protocoles d'accès au réseau peuvent, eux aussi, se résumer à trois familles :  Accès multiples au médium : chaque nœud est libre de transmettre une trame sur le réseau, après avoir testé la disponibilité du médium (CSMA: Carrier Sens Multiple Access). En cas d'accès simultané, la collision est détectée et entraîne le retrait :  de tous les émetteurs (CSMA-CD : Collision Detection) puis ré-émission dans des conditions prévues par le protocole (exemple Ethernet)  de tous les émetteurs sauf celui qui émet la donnée la plus prioritaire (CSMA-CA : Collision Avoidance) (exemple CAN)  Échanges maître – esclaves : un des nœuds (le maître) est à l'initiative de tous les échanges sur le réseau.  Partage du temps de parole sur le bus (time sharing). 1.2. Un exemple industriel : une centrale Hydroélectrique Alstom Pour illustrer ce propos, voici un exemple industriel d'une installation utilisant bus de terrain et bus de supervision, développée en partie par un apprenti de Polytech Paris Sud. Le système de contrôle-commande des petites centrales hydrauliques (<30 MW) commercialisées par Alstom Hydro est proposé au choix autour d'automates B&R X20 avec un réseau de terrain propriétaire et un réseau de supervision moderne Ethernet PowerLink, ou d'automates Schneider Modicon M340 appréciés notamment sur le marché américain. Ces derniers utilisent un réseau Modbus TCP pour la supervision et un réseau CANopen pour le terrain. Les deux automates sont capables de dialoguer en Modbus série ou Modbus TCP (client) avec les équipements périphériques (analyseurs de réseaux, distribution électrique, PC industriel de régulation de la turbine). La supervision globale est accessible depuis un ou plusieurs PC, en local ou à distance, les petites centrales fonctionnant souvent sans présence permanente. Cela justifie si c'était encore nécessaire l'intérêt d'un bus de supervision basé sur Ethernet TCP IP. Des afficheurs de supervision permettent au technicien d'avoir accès à une supervision locale dans certains locaux techniques, au plus près des parties commandes. 1.3. Un exemple pédagogique : l'ascenseur pédagogique de l'IUT La Bièvre à Cachan n'ayant pas un débit suffisant pour installer une centrale hydraulique, nous avons conçu un système automatisé reprenant cette architecture de manière plus compacte. Ce système devait de plus être transportable dans les salons. Pour cette raison, nous avons choisi de réaliser un classique ascenseur. Le processus électromécanique étudié (monte-charge) est simple à comprendre, il comporte Les équipements et l’organisation réseau de la centrale Hydroélectrique Alstom un pré-actionneur intelligent (variateur), des capteurs fixes et embarqués. L'axe vertical est un axe linéaire Elcom entraîné par un moteur asynchrone de 60 W. L'architecture de la partie commande est la suivante : La partie commande est articulée autour d'un automate Schneider Modicon M340. L'automate, moderne, accepte les 5 langages de programmation IEC et communique nativement en Modbus, Modbus TCP et CANopen. Le PC de supervision utilise le logiciel PCVue de Arc Informatique, choisi pour sa qualité et pour le nombre de licences vendues en Europe. Un écran de supervision aussi communique avec l'automate via le réseau Ethernet Modbus TCP. Modbus TCP a été retenu car il est de loin le plus simple des réseaux fonctionnant sur Ethernet TCP IP. Cette simplicité lui vaut d'être très répandu dans l'industrie, en particulier dans les appareils « peu intelligents » dialoguant sur Ethernet (analyseur de réseau, équipements météo, etc...). Modbus TCP est ouvert, les spécifications sont disponibles, l'outil gratuit de capture et d'analyse du réseau Ethernet Wireshark décode les trames Modbus TCP. Le réseau Ethernet Modbus TCP véhicule ici les informations destinées à la supervision : position interpolée de la cabine, courant dans le moteur. PCVue est client modbus TCP. L'automate communique avec le variateur Altivar 31 et les deux modules d'entrées/sorties déportées Advantys OTB via le bus CANopen. CANopen est un des 3 bus de supervision les plus représentés au niveau de l'automatisme de l'industrie « manufacturière » (qui se différencie de l'automatisme de l'industrie « de process » concernant les processus continus) : CANopen, DeviceNet et Profibus. Dans l'article sur les variateurs de vitesse de la revue Mesures de novembre 2008, on peut voir que parmi les fabricants de variateurs, 90% proposent au moins un variateur communiquant en Profibus, 71% en CANopen et 67% en DeviceNet. On trouve ensuite Modbus série (57%), puis LonWorks (33%, orienté gestion technique de bâtiment) et Interbus (23%). Fin 2008, chacun des protocoles basés sur Ethernet (EtherCat, Ethernet PowerLink, Ethernet/IP, ProfiNet, Modbus TCP, Sercos III) était disponible chez moins de 20% des fabricants de variateurs. Le protocole CANopen utilise le bus CAN, bien connu à l'IUT. CAN et CANopen sont deux protocoles ouverts dont les spécifications sont accessibles facilement et pour lesquels des outils de diagnostic bon marché sont disponibles. Les équipements et réseaux de l’application ascenseur IUT Le réseau CANopen véhicule les informations liées au process : capteurs inductifs des étages, sens de rotation et vitesse du moteur, courant dans le moteur, appels de l'ascenseur, commandes de la cabine. L'article présentera CANopen d'abord puis Modbus TCP ensuite avant de revenir sur l'exploitation de l'application pour une illustration pédagogique du thème. 2. CANopen, un bus de terrain orienté automatisme industriel Cette partie a pour ambition de présenter les notions clés de CANopen, sans entrer dans les détails qui pourraient perdre le lecteur. L'ensemble des spécifications de CANopen est disponible gratuitement sur le site de l'association CAN in Automation (http://www.can-cia.org) après enregistrement. La lecture de ces spécifications reste abordable pour une personne familière des notions réseaux habituelles. CANopen est né en 1993 de la volonté d'un groupe de fabricants d'équipements d'automatismes de normaliser les échanges sur le bus CAN pour simplifier le développement d'applications et permettre l'interopérabilité des équipements, ceci pour permettre aux fabricants d'automates de proposer des solutions réseaux intégrant des équipements complémentaires à leur offre (variateurs, vannes, codeurs...). Le premier objectif fut la création d'un module d'entrées/sorties déportées. 2.1. CANopen, couche applicative du bus CAN CANopen comme DeviceNet, sont des couches applicatives utilisant le protocole CAN comme couche physique et couche de liaison. L'étude de CANopen est très similaire à celle de DeviceNet. Pour expliquer ce qu'est la couche applicative, reprenons l'objectif initial de CANopen : créer des entrées/sorties déportées s'utilisant de manière transparente, comme des entrées/sorties locales. Sur le schéma ci-dessous sont présentés sur la gauche un automate avec des entrées/sorties locales et sur la droite l'association d'un automate et d'un module d'entrées/sorties déportées reliés en CANopen. La couche applicative est une tâche (donc un élément logiciel) tournant en parallèle avec le programme de l'application dans l'automate. Elle est aussi active dans le module d'entrées/sorties déportées. Elle utilise les contrôleurs CAN (éléments matériels) des deux équipements pour faire en sorte que à tout moment les valeurs des entrées issues de la partie opérative se retrouvent dans le registre image de ces entrées dans l'automate et que les valeurs des sorties modifiées par l'automate dans le registre image des E/S déportées soient transcrites au niveau de la partie opérative. 2.2. Le bus CAN en quelques mots Difficile de présenter le bus CAN en quelques lignes, celui-ci n'étant pas le centre de notre propos. Le bus CAN (Controller Area Network), a été conçu pour l'automobile en 1986 par la société Bosch. Temps de conception oblige, la première voiture équipée d'un bus CAN sortit en 1991 mais déjà, le bus CAN commençait à trouver sa place dans l'automatisme industriel. Les promoteurs du bus CAN mettaient en avant sa robustesse (très bonne détection des erreurs par de multiples procédés) et son déterminisme (il n'y a pas de collisions, donc on peut calculer le temps maximal qui va s'écouler entre la demande d'émission d'un message par un nœud et sa réception par un autre). 2.2.1. L'arbitrage Le principe d'un bus est la possibilité pour plusieurs équipements (appelés nœuds) d'envoyer des messages sur le câble du bus, messages pouvant être reçus par les autres nœuds. Un seul potentiel électrique étant possible à un instant t sur le bus, il est nécessaire de gérer la prise de parole sur le bus pour qu'un seul équipement ne parle à la fois. On parle d'arbitrage. Le bus CAN repose sur l'utilisation d'un niveau dominant (le 0) et d'un niveau récessif (le 1) et sur le fait qu'un bit doit être reçu par tous avant l'émission du suivant. Comme habituellement sur un bus, les nœuds (équipements reliés au bus) écoutent le bus avant d'émettre et pendant qu'ils émettent. Lorsque le bus est libre, à la fin d'un message précédent par exemple, deux nœuds peuvent commencer à émettre en même temps (les nœuds A et B sur la figure ci-dessous). Lorsque A et B émettent le même niveau, sur le bus apparaît le niveau indiqué. Dès que le niveau est différent (5ème bit ici), le 0 domine et apparaît sur le bus. Le nœud émettant un 1 à ce moment voit que le niveau sur le bus n'est pas celui de la trame qu'il envoie. Il passe alors en écoute. Il ressaiera d'émettre plus tard. La parole est laissée à celui qui parle le plus fort. Cette manière de gérer l'accès au bus fait qu’aucun bit ne passant sur le bus n'est inutile. Cet arbitrage limite par contre le débit, le bit devant être reçu par tous les nœuds avant l'émission du suivant. Pour un bus de 40m, on est limité à 1Mbits/s, débit qui ne fait plus rêver aujourd'hui. 2.2.2. La trame CAN Les premiers bits permettent de gérer la priorité des messages. C'est pourquoi, après un premier 0 indiquant la prise de parole sur le bus (Start Of Frame), les 11 premiers bits sont utilisés pour l'identifiant du message. Voici la description d'une trame de données CAN 2.0A. Cela sera suffisant pour illustrer notre propos sur CANopen. Les chiffres au milieu des champs indiquent la taille des champs.  SOF : Start Of Frame, un bit dominant indiquant la « prise de parole » sur le bus.  Identifiant : 11 bits, il est porteur de la priorité du message.  RTR : dominant pour une trame de données.  DLC : Longueur du champ de données, de 0 à 8 octets.  Champ de données : message (température, position, on/off).  Séquence CRC : calcul de vérification.  L’ACK est remplacé par un bit dominant par tout nœud qui a reçu correctement la trame.  EOF : séquence de 7 bits récessifs  Inter-trame : au moins 3 bits récessifs Pour que la priorité soit gérée avant le champ de contrôle DLC, un même identifiant ne peut être émis que par un nœud. Par contre un nœud peut émettre des messages avec des identifiants différents : des messages prioritaires avec des identifiants de valeur faible et des messages non prioritaires avec des identifiants de valeur élevée. 2.2.3. Émission en mode producteur- consommateur Le bus CAN gère la priorité lorsque plusieurs nœuds souhaitent émettre en même temps. Chaque nœud peut ainsi tenter d'émettre lorsqu'il le souhaite. Un message émis est reçu par tous les nœuds du bus (qu'ils utilisent ou non le message). On parle de mode producteur / consommateur. Les nœuds étant successivement producteurs (émetteurs de données) et consommateurs (récepteurs de données). La télévision hertzienne ou la radio FM sont des exemples de communication en mode producteur/consommateur. 2.3. Les fonctions de la couche applicative CANopen Le bus CAN n'est-il pas suffisant pour échanger des messages entre deux équipements ? On pourrait effectivement échanger des informations via le bus CAN, sans passer par une couche applicative logicielle. Cependant, il faudrait programmer les échanges de l'automate mais aussi ceux du module d'entrées/sorties déportées. Voici quelques autres raisons d'utiliser une couche applicative CANopen normalisée :  Celle-ci gère pour le programmeur de l'application la répartition des identifiants. De 211 11 11 SOF Start of frame Bit dominant Identifiant 0 - 646 115 7  3 Champ de contrôle Longueur du champs de données CRC EOF End of frame Champ des données Inter-trame 11 RTR dominant Fin de CRC Bit récessif ACK slot Bit récessif ACK delimiter Bit récessif identifiants différents à répartir, on passe à un niveau de priorité parmi 4 à choisir.  La normalisation des échanges rend possible l'utilisation d'un module d'entrées/sorties déportées de n'importe quel fabricant, il se comportera comme des entrées/sorties locales.  La supervision du bus est assurée, un mot système de l’automate reflète l'état du bus.  Etc... La figure suivante indique les rôles des 4 éléments clés dans la modification de la valeur d'une sortie déportée : le programme de l'application, le registre image des sorties déportées, la couche CANopen et le contrôleur CAN. CANopen respectant parfaitement les spécifications du bus CAN, le contrôleur CAN est un contrôleur standard. Seul l'identifiant du message, le nombre de données et les données sont des champs que l'application peut remplir via la couche applicative logicielle. Les autres champs sont liés au protocole et remplis matériellement. 2.4. Structure d'un réseau CANopen La couche applicative CANopen introduit par- dessus le protocole CAN (protocole basé sur des échanges type producteur/consommateur, sans différenciation des nœuds) la présence d'un maître et d'esclaves. La communication au niveau CANopen a toujours lieu entre le maître et les esclaves, jamais directement entre esclaves. Chaque esclave CANopen possède un numéro de nœud, de 1 à 126. L'attribution se fait par des roues codeuses pour les nœuds CANopen simples. Il faut aussi indiquer à l'esclave le débit retenu (de 10 kbits/s à 1Mbits/s). L'automate est le maître, c'est le seul élément que le programmeur doit configurer. Cette configuration consiste à indiquer les échanges souhaités entre le maître et les esclaves. Les messages sont nommés objets de communication, les identifiants sont renommés COB-ID (Communication OBject Identifier). Voyons quels sont les messages susceptibles d'être échangés. 2.5. Trois types de messages 2.5.1. PDO : Process Data Object C'est le message le plus simple, il est chargé de transporter les données liées au process (les valeurs des capteurs, les instructions envoyées aux actionneurs). C'est un message CAN brut, sans protocole supplémentaire : Les TPDOs (Transmit Process Data Object) sont envoyés au maître par l'esclave. Les RPDOs (Receive Process Data Object) sont envoyés par le maître vers un esclave déterminé. L'esclave peut émettre un message TPDO lors d'un changement d'état d'une valeur échangée (mode asynchrone) avec ou sans limite d'occupation du bus (inhibit time) ou de manière périodique (mode synchrone). La couche applicative CANopen se contente de donner l'identifiant 11 bits au message en fonction d'un niveau de priorité de 1 à 4 concaténé avec le numéro de nœud de l'esclave. Type de message et priorité Préfixe de l'identifiant Numéro de nœud Identifiant du message COB-ID TPDO1 '0011 de 1 à 127 '0011 000 0001' (0x181) à '0011 111 1111' (0x1FF) RPDO1 '0100 '0100 000 0001' (0x201) à '0100 111 1111' (0x27F) TPDO2 '0101 '0101 000 0001' (0x281) à '0101 111 1111' (0x2FF) RPDO2 '0110 Etc... TPDO3 '0111 RPDO3 '1000 TPDO4 '1001 RPDO4 '1010 Voici l'exemple d'un TPDO2 envoyé par le nœud 2 de notre application et capturé par un CANanalyseur. Au-dessus est présenté le résultat du décodage CANopen et au-dessous le résultat du décodage CAN. Les données peuvent comporter de 1 à 8 octets. Les contenus et les priorités des messages sont configurés via le logiciel de programmation/configuration du maître. 2.5.2. SDO : Service Data Object Pour envoyer cette configuration depuis le maître vers l'esclave, CANopen utilise un autre type de messages nommé SDO (Service Data Objects). Ces messages ont un niveau de priorité fixé moindre que les PDOs. L'identifiant est créé par CANopen en concaténant le type du SDO (TSDO pour esclave vers maître et RSDO pour maître vers esclave) avec le numéro du nœud. Type de message et priorité Préfixe de l'identifiant Numéro de nœud Identifiant du message COB-ID TSDO1 '1011 de 1 à 127 '1011 000 0001' (0x581) à '1011 111 1111' (0x5FF) RSDO1 '1100 '1100 000 0001' (0x601) à '1100 111 1111' (0x67F) Pour indiquer le registre de l'esclave visé par le message de configuration, la première partie du champ de données est consacrée à l'adresse de ce registre (index et sous-index). La suite est consacrée aux données de configuration. Les échanges se font en mode client-serveur. L'esclave est « serveur SDO » et le maître client. Il envoie des requêtes de modifications que l'esclave exécute et acquitte. Voici un exemple capturé par le CANanalyseur sur notre application. Il s'agit de la modification du Heartbeat time (cf paragraphe suivant), valeur située dans le registre 0x1017, sous-index 0. On passe la valeur à 5000 ms (5000 = 0x1388). En haut, on trouve le résultat du décodage CANopen et dessous le résultat du décodage CAN. On voit bien l'échange de type client serveur avec d'abord le RSDO, requête envoyée par le maître et juste après la réponse de l'esclave via un TSDO. 2.5.3. Démarrage, Arrêt, Supervision du bus Des messages nommés NMT (Network Management) permettent de faire passer le bus du mode arrêté (pas d'échange) au mode PRE- OPERATIONNEL (configuration par le maître des esclaves via les SDOs) puis au mode OPERATIONNEL (échanges des données liées au process via les PDOs). De plus, pour vérifier le bon fonctionnement de chaque nœud, un protocole nommé Heartbeat ou Nodeguarding demande à chaque nœud d'envoyer périodiquement un message peu prioritaire ('1111 suivi du numéro du nœud) indiquant son bon fonctionnement. Le maître permet de configurer la période de ce « battement de coeur », pour chaque esclave. Enfin, pour les PDOs synchrones, un message nommé SYNC envoyé par le maître déclenche l'envoi des PDOs synchrones. Le tableau ci-dessous résume l'ensemble des messages normalisés en CANopen. Error Control correspond aux messages Hertbeat ou Nodeguarding. La zone 680h à 6FFh est disponible pour des messages spécifiques non normalisés. Nous n'aborderons pas ici les messages Time Stamp et Emergency Object. Pour conclure ce paragraphe, nous pourrions reprendre une séquence classique : 1 – Message NMT « passage en mode PRE- OPERATIONNEL » 2 – Echanges des SDOs sous la conduite du maître pour envoyer la configuration de chaque nœud (configuration effectuée dans le logiciel de programmation de l'automate maître) vers les esclaves. 3 – Message NMT « passage en mode OPERATIONNEL » 4 – Echanges de PDOs liés au process (informations issues des capteurs, commandes des actionneurs) A partir de cet instant, tout se passe dans le programme comme si les entrées/sorties étaient locales, avec un temps de réponse du réseau tout de même lié au débit et aux nombres d'entrées/sorties à rafraichir (à 250 kbits/s, un message PDO dure 200 µs). Le travail du programmeur consiste essentiellement à configurer CANopen du point de vue matériel (numérotation des nœuds, choix d'un débit) et logiciel (répartition des données sur les 4 niveaux de priorité possibles, choix du type d'envoi des PDOs). La configuration logicielle du réseau CANopen se fait via le logiciel de programmation de l'automate. Comment cela se passe-t-il quand le périphérique CANopen relié à l'automate est inconnu du logiciel (parce que plus récent que le logiciel par exemple) ? La réponse est dans le paragraphe suivant... 2.6. Le dictionnaire d'objets Quand un électronicien souhaite établir la communication entre un microcontrôleur et un nouveau composant électronique, il ouvre la feuille des spécifications (datasheet) de ce dernier pour connaître la nature des informations à envoyer/recevoir pour un fonctionnement correct du nouveau composant. De la même manière, les spécifications des périphériques CANopen sont décrites dans un fichier normalisé nommé Electronic Datasheet (EDS). Ce fichier, fourni par le fabricant du périphérique CANopen, est un fichier texte normalisé qui sera compris par le logiciel de configuration du réseau (qui est aussi le logiciel de programmation de l'automate). Il contient les noms et adresses (index et sous-index) de l'ensemble des registres du périphérique. La liste de tous ces « objets » (registres) est appelée dictionnaire d'objets. Voici ci-dessous un extrait de la documentation (adressée au programmeur) d'un module d'entrées/sorties déportées et, juste en dessous, l'extrait du fichier EDS correspondant. [1017] ParameterName=Producer Heartbeat Time ObjectType=0x7 DataType=0x0006 AccessType=rw DefaultValue=0x0 PDOMapping=0 La description des spécifications des équipements dans un fichier est un concept qui a eu un grand succès dans les bus de terrain. Des tentatives ont même lieu pour normaliser les fichiers de description de tous les bus de l'automatisme en un seul standard nommé FDI (Field Device Integration). 2.7. Les profils CANopen La normalisation de CANopen a conduit à imposer les index, les unités et les valeurs possibles pour les objets liés au fonctionnement du bus (Heartbeat time, mode de transmission des PDOs, etc...). La normalisation visait à l'origine à permettre l'utilisation d'un module d'entrées/sorties déportées sans avoir à tenir compte du fabricant. Cela a conduit à normaliser un profil « module d'entrées/sorties déportées » où les éléments essentiels de ces modules (les entrées tout ou rien, les sorties tout ou rien, les entrées analogiques, etc...) sont des objets ayant les mêmes index, unités et configurations par défaut. C'est le profil CiA 401. Pour laisser la place à l'innovation tout de même, en marge du profil « officiel », une place est laissée pour des objets spécifiques (par exemple, le module utilisé à l'IUT possède des entrées compteurs rapides et des sorties PWM). Lorsque plusieurs fabricants proposent des objets spécifiques similaires orientés vers le même type d'application, il est possible de définir un nouveau profil. Le premier nouveau profil à être apparu est le profil variateur de vitesse CiA 402 (avec des objets vitesse, courant, etc...) Depuis, de nombreux profils sont apparus témoignant des champs d'application des périphériques CANopen :  CiA 406 : codeurs rotatifs et linéaires  CiA 417 : ascenseur  CiA 412 : appareils médicaux  CiA 445 : lecteur RfiD  CiA 437 : systèmes photovoltaïques  CiA 433 : éclairage intérieur de train  CiA 420 : machines excavatrices de charbon. Les profils très spécifiques permettent de proposer des périphériques avec une configuration par défaut adaptée à l'application. Le programmeur n'a alors quasiment pas à entrer dans la configuration CANopen. 3. Modbus TCP, un bus de supervision : Le champ d’application de Canopen, bus orienté terrain et déterministe, est le dialogue entre la partie commande et les capteurs et actionneurs. La supervision quant à elle met en relation les automates avec des machines embarquant un logiciel de supervision (SCADA) tels que PC, écrans tactiles, terminaux graphiques, les informations échangées concernent le suivi du processus, son paramétrage à partir d’une I.H.M. Les s échanges sont en général plus lents (du dixième de seconde à la seconde) mais ces informations sont amenées à franchir des passerelles vers d’autres réseaux et surtout vers l’INTERNET où elles pourront être consultées à distance sous forme de pages WEB. De ce point de vue se dégage un standard de communication particulièrement adapté : ETHERNET TCP/IP. La généralisation de son utilisation répond notamment aux contraintes de coût et garantit sa pérennité ainsi que son évolution à de nouvelles fonctionnalités. De manière générale, le support ETHERNET tend à se généraliser également au niveau des réseaux industriels, Selon des études récentes, MODBUS/TCP est le protocole ETHERNET industriel le plus utilisé dans le monde. La structure simple du protocole MODBUS et sa forte documentation font une bonne part de son succès dans les applications de supervisions. 3.1. Evolution de Modbus vers Modbus TCP : MODBUS TCP est la variante encapsulée dans TCP/IP du protocole des liaisons séries MODBUS, standard des communications d’automatismes déposé par MODICON depuis 1979. 3.1.1. La trame d’application MODBUS : Revenons sur le protocole originel MODBUS qui utilise une communication de type Maitre/Esclave qui a évolué en Client/Serveur sur MODBUS TCP/IP : Dans une communication MODBUS série de type Maître/esclave, seul un maître peut initier un échange en envoyant une question ou requête (Query), les composants esclaves répondent au maître en envoyant une réponse contenant les données demandées ou en réalisant une action demandée par le maître. Notons qu’un maître MODBUS peut adresser un esclave particulier ou tous les esclaves par l’envoi d’un message diffusé (Broadcast) mais un esclave ne répond que quand il est individuellement adressé par une requête qu’a initiée un maître. On peut définir la structure de la trame MODBUS originelle, constituée : Dans le cas d’une requête du maître :  de l’adresse esclave, d’un code fonction définissant la nature du service demandé par le maître, d’un champ de données propre à la nature de la fonction demandée et enfin d’un champ de contrôle d’erreur. Dans le cas d’une réponse de l’esclave :  du champ de confirmation de la réalisation du service demandé, du champ des données éventuelles en réponse, et d’un champ de contrôle d’erreur. La trame MODBUS série On définit dans la trame MODBUS une Unité de Données de Protocole (P.D.U.), elle définit le type de fonction MODBUS et les données véhiculées, elle est indépendante des couches de communication sous jacentes. La trame contient deux champs additionnels (adresse et erreur) qui constituent l’entête et le contrôle d’erreur propres à MODBUS RTU qui est le protocole utilisant les liaisons séries (RS232, 422, 485). L’ensemble constitue l’unité de données d’application ou A.D.U. Dans le cas de MODBUS TCP/IP, une entête spécifique notée « MBAP Header » est utilisée pour identifier l’A.D.U. MODBUS/TCP. Cet entête possède des spécificités qui permettent de différencier l’ADU MODBUS TCP/IP de l’ADU MODBUS RTU. ADU Code fonction DonnéesAdresse Erreur MODBUS TCP/IP utilise le protocole TCP/IP et le réseau physique ETHERNET pour acheminer les données des messages du protocole d’application MODBUS entre machines compatibles, dans une trame TCP : Les commandes MODBUS et les données elles mêmes sont encapsulées dans un conteneur sans être modifiées, par contre, le contrôle d’erreur originel n’est pas utilisé puisque le contrôle d’intégrité des messages sera assuré par l’utilisation du standard ETHERNET TCP/IP. L’adresse esclave habituellement utilisée avec MODBUS série sera remplacée par le routage propre à ETHERNET TCP/IP. Le tableau suivant décrit les champs : CHAMP LONGUEUR DESCRIPTION IDENTIFIANT de TRANSACTION 2 octets Permet d’établir une association requête/réponse lors d’une transaction client/serveur. Si plusieurs requêtes sont émises cette ID permettra d’associer la réponse correspondante à la requête. IDENTIFIANT de PROTOCOLE 2octets Toujours 0 pour les services MODBUS. LONGUEUR DU CHAMP 2 octets Contient le nombre d’octets du champ restant, incluant l’octet d’identification d’unité, l’octet du code fonction et les octets de données. IDENTIFIANT d’UNITE 1 octet Numéro d’unité pour les équipements joints au travers d’une passerelle ou un pont. 3.1.2. La connexion client/serveur avec MODBUS : MODBUS TCP, comme cela a été évoqué ci- dessus, utilise une connexion de type CLIENT/SERVEUR. L’unité de données d’application (A.D.U.) décrite plus haut, est construite par le client qui initie une transaction (requête) vers un serveur : Le serveur MODBUS/TCP : Le rôle du serveur est de fournir un accès à des objets concernant l’application ainsi qu’à des services, aux clients connectés. Deux types d’accès sont possibles :  Des accès simples permettant d’obtenir ou définir l’état d’objets tels que bits ou registres de la mémoire interne de l’équipement, par exemple un automate équipé du service de messagerie MODBUS TCP.  Des accès avancés permettant le déclenchement de services d’applications spécifiques, par exemple changer le mode de fonctionnement d’un automate (Run ou Program). Ces services, caractérisés par un code fonction MODBUS permettent à un ou plusieurs clients connectés de venir lire ou écrire des données dans la structure mémoire (bits et registres) de l’A.P.I.serveur par exemple. Elles sont donc partagées au niveau du serveur MODBUS/TCP par le processus automatisé de l’application automate et le service de messagerie MODBUS/TCP embarqué dans celui-ci. L’architecture interne d’un composant serveur MODBUS comme un A.P.I. par exemple, se compose de quatre modules principaux : MODBUS TCP/IP A.D.U. Evolution de la trame de base MODBUS vers l’A.D.U. MODBUS/TCP Trame MODBUS série originelle : Code fonction et données (inchangés) : Code fonction Données P.D.U Length field Unit IDTransaction ID Protocol ID MODBUS Application Protocol (MBAP) Header, 7 octets Adresse Code fonction Données Erreur 2 octets 2 octets 2 octets 1 octet 1 octet Variable Code fonction Données Le serveur MODBUS ouvre une écoute en attente d’une requête sur le port TCP 502 réservé aux applications MODBUS, il peut traiter simultanément plusieurs requêtes, de 1 à 16 selon les paramètres de conception du serveur, mais il faut noter que le nombre de transactions traitées simultanément dégrade les temps de réponse du serveur aux requêtes clients. Lors de la réception d’une requête d’un client, le serveur analyse l’entête MBAP de l’ADU MODBUS/TCP, si celle-ci est conforme, la transaction peut s’établir. Elle est initialisée avec une identification de connexion établie par le module TCP Management et avec les informations suivantes de l’A.D.U.:  L’ID de Transaction initialisée par le client contenu dans le MBAP est recopié par le serveur et incrémenté d’une unité à chaque transaction, établissant ainsi une association requête/réponse.  L’ID d’unité qui permet de joindre une unité MODBUS en communication au travers de ponts, de routeurs ou de passerelles utilisant une adresse IP unique pour supporter plusieurs terminaux MODBUS indépendants sur un réseau série par exemple. Dans le cas d’un équipement serveur MODBUS/TCP, l’ID unité vaut 1. Dans l’exemple ci contre on trouve un ensemble de clients/serveurs sur MODBUS TCP/IP, une passerelle TCP/IP vers MODBUS série permettant l’accès à deux équipements serveurs (API 3 et 4) sur MODBUS série. Chacun de ces serveurs sera identifié par son ID Unit (1octet) à partir de la trame MODBUS TCP/IP. MODBUS TCP/IP PC de supervision Ecran tactile API1 (TCP/IP) API2 (TCP/IP) API3 et 4 sur MODBUS RTU Permet un accès aux objets de l’application utilisateur (bits, registres..) selon la PDU de requête. Accepte ou non le service, construit la réponse. Applications utilisateur TCP Management PILE TCP/IP Gestion des services MODBUS Services Bits Gère les communications TCP en ouvrant une écoute sur le port 502, accepte ou non, établit et clôt les communications. Interface pour la réception et la transmission des données au format ETHERNET TCP/IP. Gère les paramètres IP. Application utilisateur : par exemple gestion d’un processus automatisé dans le cas d’un API. L’application utilise des objets (bits, registres…). RESEAU ETHERNET TCP/IP Modèle simplifié d’un serveur MODBUS/TCP Registres Quand la requête a été analysée, le serveur MODBUS/TCP peut fournir deux types de réponses :  une réponse positive, avec une PDU précédée d’un MBAP établi à partir des informations du MBAP de la requête (ID transaction, ID unité, ID de protocole), il renseigne le champ de longueur indiquant la longueur de la PDU plus ID unité et place les données du service demandé avec son code fonction dans la PDU.  Une réponse d’exception contenant un code d’exception dans le cas où la requête client a été rejetée. Une transaction client/serveur sans erreur : le serveur répond en utilisant le même code fonction que celui contenu dans la requête du client. Si une erreur est détectée par le serveur un code d’exception est renvoyé. Dans tous les cas, il est important de noter que toutes ces actions sont transparentes pour le programmeur de l’application. Le client MODBUS/TCP : La structure interne d’un client MODBUS est proche de celle du serveur du point de vue des modules de gestion des connexions, du routage et des applications MODBUS. Typiquement, un client MODBUS pourra être un PC de supervision par exemple. Le module client MODBUS/TCP construit une requête à partir des informations de l’application, par exemple un logiciel de supervision. L’interface client MODBUS permet la construction de requêtes pour accéder aux services MODBUS d’un serveur. La gestion d’une transaction MODBUS par un client comprend :  Initialisation de la transaction MODBUS, à partir des informations de l’application (supervision par exemple),  Encodage de la requête (entête MBAP et PDU),  Construction de la trame TCP/IP avec émission de la requête sur un port client TCP supérieur à 1024 :  Attente de la réponse du serveur.  A réception de la réponse, l’identification de transaction (ID Transaction) permet au client de trouver la requête correspondante. Si celui-ci ne correspond à aucune requête connue émise par le client, la réponse est tout simplement ignorée.  Analyse de la réponse, vérification de la conformité du code fonction qui doit être le même dans la réponse serveur que dans la requête client, vérification de la PDU.  Confirmation de réponse positive ou négative (code fonction erroné) à l’application. 3.1.3. Le transport de la trame MODBUS sur ETHERNET TCP/IP : MODBUS/TCP utilise le protocole TCP/IP et le media ETHERNET pour communiquer ; si on se réfère au modèle OSI de représentation normalisée des réseaux en couches, MODBUS TCP/IP utilise les 4 couches basses du modèle communes à tous les composants ETHERNET TCP/IP, l’application MODBUS couvrant les couches hautes 5,6 et 7. Le client construit une requête (A.D.U. MODBUS/TCP) au niveau de la couche application, puis transmet ces données aux couches inférieures qui ajoutent leurs propres entêtes et parfois terminaisons protocolaires. Les données ainsi encapsulées forment des paquets TCP/IP et atteignent la couche physique où ils sont électroniquement transmis vers leur serveur de destination joint avec son adresse IP. A réception par le serveur, les paquets sont décodés au niveau de chaque couche correspondante pour finalement atteindre la couche application MODBUS des données à traiter par le serveur. Encapsulation de l’A.D.U. MODBUS/TCP dans la trame ETHERNET TCP/IP Remarque : comme cela a été évoqué, le protocole ETHERNET TCP/IP n’est à l’origine pas destiné aux réseaux industriels dans la mesure où il n’est pas déterministe. Cela tient au protocole CSMA/CD d’arbitrage utilisé par Ethernet pour déterminer l’accès au réseau. Dans le cas habituel d’utilisation de switches, un retard important dans l’acheminement des messages apparaît lors de la congestion d’un switch (débit entrant supérieur au débit sortant maximum possible). 3.1.4. Analyse de trames MODBUS TCP/IP : L’observation de trames MODBUS/TCP sur un réseau ETHERNET TCP/IP permet d’illustrer les échanges client/serveur MODBUS entre un A.P.I. serveur et un PC client par exemple. Cela nécessite l’utilisation d’un outil logiciel d’exploration de réseau qui va permettre la capture des trames et leur analyse, tel que Wireshark. Précisons que cet outil est en téléchargement libre. Voici un enregistrement effectué par Wireshark, il concerne les échanges entre un client (PC de supervision) et un automate MODICON serveur MODBUS : La trame 3 émise par le PC dont l’adresse IP est 192.168.70.85 à destination de l’A.P.I. serveur dont l’IP est 192.168.70.85. Le protocole identifié est MODBUS/TCP, elle constitue une requête (Query), l’identifiant de cette transaction est 5055, l’identifiant d’unité est 1, le code fonction MODBUS est 3, il s’agit d’une lecture de plusieurs registres de l’A.P.I. La trame 4 est la réponse émise par le serveur qui devient source à destination du PC client, elle contient le même identifiant de transaction (5055) ce qui permettra au client d’associer cette réponse à sa requête (ID de transaction identique), le code fonction 3 est confirmé. On constate qu’à chaque transaction (question/réponse) l’ID de transaction est incrémenté d’une unité. La trame 3 sélectionnée peut être analysée en détail du point de vue des différentes couches du réseau : A.D.U. MODBUS Adresse MAC de la machine source Adresse MAC de la machine destination Type de la machine source (PC Dell) Type de la machine destination: API TELEMECANIQUE Port TCP utilisé par le client Pour sa requête : 3452 Port TCP utilisé par le serveur :502 (Application MODBUS) Fonction MODBUS 3.2. Le protocole d’application MODBUS : 3.2.1. Le mapping MODBUS : Modbus permet au moyen du code fonction contenu dans la P.D.U. décrite plus haut, l’accès à la structure mémoire de la machine serveur. Il est ainsi possible pour le client connecté de venir lire ou écrire des bits ou registres de cette mémoire et ainsi d’avoir accès à des données de l’application du serveur (processus automatisé par un A.P.I. ou paramètres d’un variateur, etc..). Cela suppose pour le serveur l’organisation des données accessibles selon un modèle MODBUS qu’on peut décliner en quatre tables : Tables de données Type d’objets Type d’accès Commentaires Entrées discrètes (discretes input) Bit Lecture seule Données délivrées par le système d’entrées/sorties Bobines (Coils) Bit Lecture/Ecriture Données partagées avec l’application Registres d’entrée (input registers) Mot 16 bits Lecture seule Données délivrées par le système d’entrées/sorties Registres internes (holding registers) Mot 16 bits Lecture/Ecriture Données partagées avec l’application Toutes les données (bits et registres) véhiculées par MODBUS correspondent à des points physiques de la mémoire de l’application, toutefois il est important de ne pas confondre l’adresse physique en mémoire avec la référence de donnée propre à MODBUS. Les adresses de données contenues dans la PDU MODBUS sont des entiers non signés débutant à la référence 0. Le « Mapping MODBUS » définit comment MODBUS associe l’adresse d’une donnée passée par la PDU avec la donnée elle-même le tableau ci-dessous propose l’exemple d’accès à la mémoire par le service MODBUS pour l’A.P.I. TWIDO de Schneider ; dans le cas de cet A.P.I. le modèle de données MODBUS est réduit à deux tables : Modèle de données MODBUS pour l’API TWIDO Services MODBUS Adresses physiques mémoires API Références MODBUS des éléments adressés Code fonction MODBUS Lecture/Ecriture de bits Bits de %M0 à %M255 Bits de 1 à 256 01 pour la lecture 05 pour l’écriture Lecture/Ecriture de registres Registres de %MW0 à %MW255 Registres de 1 à 256 03 pour la lecture 06 pour l’écriture Dans ce cas, le modèle d’adressage peut se représenter : 1 Coils (Bits) 256 1 Registres 256 Lecture/Ecriture Bit 0 Lecture/Ecriture Registre 0 %M0%M15 %M255 Adresses PDU MODBUSModèle données MODBUSMémoire application TWIDO %MW0 %MW255 3.2.2. Les codes fonctions MODBUS : Les codes fonctions Modbus définissent le type de service requis, ils se classent en trois catégories : les codes fonctions dits publics qui sont définis par le standard Modbus, les codes fonctions utilisateurs qui sont au choix de l’utilisateur, les codes réservés aux fabricants : On trouvera la totalité des codes fonctions MODBUS et de la description du service associé à chaque code sur le site : http://www.modbus.org En ce qui concerne les applications les plus courantes, notamment l’application support décrite ici, les codes fonctions utilisés sont : lecture/écriture de bits (coils), lecture/écriture de registres, le tableau suivant présente les codes fonctions Modbus correspondants : Service MODBUS Code fonction Adresse début (PDU) Mouvement de données Lecture de bits (coils) 01 De 0x0000 à 0xFFFF Lecture de 1 à 2000 bits Ecriture d’un bit (single coil) 05 De 0x0000 à 0xFFFF La donnée 0x0000 met le bit à 0 ; La donnée 0xFF00 met le bit à 1 Lecture de registres (16 bits) 03 De 0x0000 à 0xFFFF Lecture de 1 à 125 registres Ecriture d’un registre (16 bits) 06 De 0x0000 à 0xFFFF Ecriture de donnée de 0x0000 à 0xFFFF Lecture de registres d’entrée (16 bits) 04 De 0x0000 à 0xFFFF Lecture de 1 à 125 registres d’entrées 4. Bus de terrain et de supervision sur l'ascenseur IUT Après les développements théoriques liés au bus de terrain CANopen et au bus de supervision Modbus TCP utilisés à l'IUT de Cachan, voici une présentation de leur mise en œuvre et des résultats obtenus sur l'application « ascenseur ». Commençons par un schéma orienté réseau du système : 4.1. Mise en oeuvre de CANopen Le logiciel utilisé pour la programmation de l'automate Schneider Modicon M340 et la configuration de CANopen est Unity Pro. Tous les périphériques CANopen utilisés sont de marque Schneider, ce qui facilite leur intégration. La première étape consiste à indiquer la constitution du réseau CANopen, à définir le débit : Ensuite, pour chaque esclave, le programmeur peut utiliser la configuration par défaut du profil ou indiquer les messages de process (PDOs) qu'il veut utiliser et le type d'envoi. La figure ci-dessous présente la configuration des entrées du module d'entrées/sorties 1 (boutons de la cabine) : envoi synchrone cyclique des valeurs des boutons (entrées 0 à 7) en réponse à un message SYNC (message de synchronisation des envois de PDOs synchrones envoyé par le maître) sur deux. L’application ascenseur de l’IUT Pour notre application très simple, les configurations par défaut des périphériques seraient parfaites. Cependant, pour illustrer le fonctionnement de CANopen, la configuration suivante a été retenue.  Maître (automate) : réseau à 250 kbits/s, message SYNC avec une période de 1s.  Module d'entrées/sorties cabine, nœud 1 (profil entrées/sorties déportées) : envoi synchrone sur PDO2 (donc moins prioritaire) des valeurs des boutons de la cabine, tous les 2 messages SYNC (soit toutes les 2s). Heartbeat à 5 s  Module d'entrées/sorties bâti, nœud 2 (profil entrées/sorties déportées) : envoi asynchrone, sur changement d'état, des valeurs des capteurs de position de la cabine et des boutons d'appel de l'ascenseur. La durée minimale entre deux envois du PDO est de 2 secondes. Heartbeat à 5 s.  Variateur, nœud 3 (profil variateur) : configuration par défaut des PDOs, réception des consignes marche/arrêt, avant/arrière et vitesse ; envoi de la valeur du courant dans le moteur, Heartbeat à 5 s. Remarque : Le variateur utilise une configuration par défaut avec des échanges de PDOs hors des plages normalisées. Les PDOs, appelés PDO6, utilisent les identifiants laissés libres pour des applications spécifiques. Ils ne sont donc pas reconnus dans les décodages CANopen. Cette configuration « pédagogique » n'est évidemment pas judicieuse pour un bon fonctionnement, l'envoi des valeurs des boutons poussoirs de la cabine toutes les 2s est largement trop lent vis à vis de la durée de vie de l'entrée. Il faut appuyer longtemps. Lors des montées rapides de l'ascenseur, la durée minimale de 2s entre deux envois des valeurs des capteurs de position conduit à un dépassement important des capteurs par la cabine. Un module CANanalyseur de capture CANopen est ajouté sur le réseau. Voici le récit des échanges sur CANopen : 4.1.1. Mode PRE-OPERATIONNEL : la configuration par les SDOs Voici les relevés de captures issus de la période de configuration. La signification des registres correspondant aux index modifiés par les SDOs est donnée dans la datasheet du périphérique (soit la datasheet électronique, peu lisible, soit la datasheet pdf plus accessible au programmeur). Quelques SDOs ciblés permettent d'illustrer la configuration par message de services. 4.1.2. Mode opérationnel : échanges de PDOs Remarque : les boutons poussoirs utilisés dans la cabine (PDO2 du nœud 1) et sur le bâti (PDO1 du nœud 2) sont des boutons normalement fermés. Les échanges avec le variateur utilisant des identifiants non normalisés, ils ne sont pas visibles sur les captures CANopen. Les captures CAN (non présentées ici) montrent bien leur passage. Le Heartbeat du maître, à 200ms par défaut (modifiable ?) a été filtré pour ne pas encombrer les captures. Les configurations choisis permettent d'illustrer :  les envois de messages de process PDOs  la supervision du réseau par Heartbeat (messages NodeGuarding)  les modes d'envoi synchrones et asynchrones sur changement d'état  l'effet du inhibit time  les problèmes de durée de vie des entrées : un appui de moins de 2 sec d'un bouton de la cabine peut ne pas être pris en compte.  les problèmes de temps réel : le retard dans l'envoi de l'état du capteur de position du à l'inhibit time du PDO1 entraîne de fort dépassement de la cabine. 4.2. Mise en œuvre de la supervision via Modbus TCP. La supervision très simple de cette application a été développée sur PCvue. Elle comporte une image de la cabine se déplaçant verticalement. Cette position de la cabine est calculée dans l'automate à partir des informations issues des capteurs inductifs de position et de la vitesse du moteur. La supervision affiche aussi l'état des 4 capteurs de position de la cabine et le courant dans le moteur, pour détecter d'éventuelles surcharges. L’I.H.M. de supervision PCVUE Le schéma ci-dessous indique les échanges (tous de l'automate vers le PC) ayant lieu sur le réseau Modbus TCP. On effectue sous PCVue, client Modbus TCP, la configuration de la communication Modbus TCP : définition de l'adresse IP des serveurs Modbus TCP (ici l'automate), définition de la période des requêtes, définition des trames (code fonction, nombre de mots ou bits, adresse du premier mot ou bit). Ensuite, on associe les mots ou bits Modbus TCP avec les variables PCVue, comme dans la figure ci- dessous pour les mots. Une fois la configuration réseau effectuée, on lance la communication, on lance l'application et le logiciel de capture et d'analyse de trame Wireshark nous permet alors d'observer les échanges ayant lieu sur le réseau : L'objectif pour cette année est de rendre cette partie opérative « supervisable » depuis l'extérieur de l'IUT, de façon à mettre en évidence l'intérêt des bus de supervision sur Ethernet : Les paquets IP peuvent circuler sur le réseau Internet. L'automate possède un serveur Web embarqué qui permet de superviser de manière simple le système à partir d'un navigateur internet. Il est prévu de rendre aussi accessible ce serveur Web embarqué depuis l'extérieur. Le remplacement des équipements Schneider par des équipements CANopen hétérogènes est aussi à l'étude pour souligner l'interopérabilité de CANopen. 5. Le point de vue pédagogique Nous enseignons ce module sur les bus industriels à des étudiants de 2ème année de DUT Génie Electrique, et de 2ème année de Cycle Ingénieur. Les exercices et les examens sont ajustés en fonction du niveau de formation. L’organisation pédagogique suit le schéma suivant :  Thème N°1 : le réseau Ethernet et TCP/IP  Thème N°2 : le réseau CAN  Thème N°3 : le réseau CAN OPEN  Thème N°4 : MODBUS et la supervision Pour chaque thème nous proposons un cours/TD de 3h/4h ainsi qu’un TP de 4h. Selon les cursus, ce module peut s’achever par un projet de quelques jours. Pour les Travaux Pratiques, nous utilisons du matériel et/ou logiciel standard du marché ou bien nos propres maquettes pédagogiques. Voici la description du matériel pour un groupe de 6 binômes. Chaque binôme dispose d’un PC, non pris en compte dans le tableau. 5.1. Manipulation Ethernet Le TP consiste à configurer l’adresse IP de son PC, analyser des trames, comprendre le rôle d’un switch et d’un routeur, configurer le routeur, découvrir les protocoles ARP, DHCP, IP, TCP. Thème Description Coût Ethernet Un PC ordinaire servant de serveur + un switch + un routeur + logiciel d’analyse de trames WireShark (gratuit) + logiciel Apache (gratuit). 60€ x 1 (hors PC) CAN Maquette pédagogique à base de microcontrôleurs PIC. 50€ x 6 CAN Programmateur de microcontrôleur PIC + logiciel de développement MPLAB (gratuit) 100€ x 1 CAN Facultatif : analyseur logique capable d’interpréter la trame CAN, un oscilloscope standard suffit ! 5000€ pièce CAN OPEN Maquette pédagogique à base d’automate programmable TWIDO SCHNEIDER et de l’outil de développement TWIDO SUITE. 1000€ x 6 MODBUS Supervision Logiciel PC Vue – version de démonstration (gratuite). Le nombre de variables est limité à 25 (suffisant pour nos applications). La version complète coûte environ 1000€ par licence 5.2. Manipulation CAN Chaque binôme de TP dispose d’un kit de test. Le kit est équipé de 3 cartes munies chacune d’un microcontrôleur. Les cartes communiquent via un bus CAN et sont munies d’interrupteurs et de LEDs. Différents protocoles de communication sont étudiés (les cartes sont fournies déjà programmées). Un logiciel « espion », sur bus série RS232 a été développé. Les étudiants analysent les trames à l’oscilloscope ou à l’analyseur logique. 5.3. Manipulation CAN OPEN Chaque maquette est constituée d’un API, d’un coupleur CANOPEN, d’un boitier d’entrées/sorties déportées communiquant avec l’API par un bus CANOPEN, d’un boîtier « espion » de trames connecté au bus série du PC. 3 interrupteurs et 3 LEDs matérialisent une charge opérative connectée au boîtier d’E/S déportées. Le TP consiste à configurer le bus CANOPEN, analyser des trames, écrire une application très simple pour provoquer des échanges sur le bus, modifier la configuration du bus. 5.4. Manipulation supervision Le TP consiste à lancer une application déjà écrite pour l’API TWIDO et à analyser les trames MODBUS avec WireShark. Si le PC est placé derrière un routeur, la reconfiguration du routeur est étudiée. Une autre séance de prise en main du logiciel PCVUE peut être proposée. 6. Conclusion : CANopen est né en 93 et Modbus TCP hérite d’un protocole apparu en 1979, préhistoire de la communication informatique. L’enseignement de ces deux bus n’est-il pas un peu poussiéreux ? Comme l’explique les introductions aux parties 2 et 3, CANopen est très bien implanté comme bus de terrain et Modbus TCP encore le plus répandu des bus industriels sur Ethernet TCP/IP. Ces deux bus, comme leurs concurrents, répondent à 95% des besoins industriels, voir plus et sont maîtrisés par les fabricants Nœud 0 Nœud 1 Nœud 2 Valeur du bouton poussoir Identifiant 0x10 Valeur du bouton poussoir Identifiant 0x10 Valeur du potentiomètre Identifiant 0x02 Valeur du potentiomètre Identifiant 0x02 Liaison série RS232 Envoi de l’ensemble des messages reçus sur le bus CAN vers le PC CANbus 10kbits/s Led 2 à 4 affichage du mode Led 1 ? Potentiomètre Valeur de 0 à 15 envoyée sur le bus Bouton poussoir Choix du protocole Leds Affichage de la donnée reçue via le message CAN d’indentifiant 0x02 Bouton poussoir Valeur 0 ou 1 envoyée sur le bus Led 4 S’allume quand le nœud 0 reçoit une trame Led 1 Affichage de la donnée reçue via le message CAN d’indentifiant 0x10 LogicielSpy Windows Affiche l’identifiant et la donnée Points de test Bus CAN PC1 PC2 PC3 PC4 PC5 PC6 SWITCH ROUTEUR PC serveur DHCP serveur FTP HTTP bus CAN 250kbit/s Liaison RS232 ou ETHERNET Boîtier E/S déportées Boîtier espion CAN Analyseur Logiciel TWIDO Suite Automate TWIDO Liaison RS232 Charge opérative Coupleur CAN Logiciel CAN Analyseur Réseau CAN/CANOPEN ETHERNET – MODBUS/TCP ROUTEUR Boîtier E/S déportées Logiciel PC Vue Application de supervision Automate TWIDO Charge opérative Coupleur CAN et leurs clients. C’est pourquoi ils sont encore loin de la route du cimetière des bus en voie d’extinction, où les y attendent FIP et VAN entre autres. De plus, ces bus éprouvés et documentés restent accessibles à des étudiants de DUT ou BTS et les outils de développement / capture accessibles au budget de leur établissement. Ils permettent d’aborder théoriquement et de mettre en œuvre les grands concepts des réseaux de terrain et supervision. Le monde du contrôle/commande industriel est moins friand d’innovation que les fabricants de matériel ne le souhaiteraient. CANopen, DeviceNet, Profibus, Modbus TCP n’évoluent plus beaucoup mais font recette. Les équipes de développement réseau des fabricants déploient leur énergie désormais sur les bus de terrain basés sur Ethernet et sur les protocoles pour capteurs sans fil. Pour Ethernet en bus de terrain, les arguments avancés reposent sur l’unicité du bus de la supervision au capteur (une seule formation, un type de câblage), la facilité du diagnostic et de la configuration par page Web, le débit jusqu’à 1 Gbits/s, la possibilité d’utiliser la fibre optique ou le sans fil (dérivé du Wifi) et le temps de réponse du bus jusqu’à quelques dizaines de microsecondes pour les meilleurs. Plusieurs réseaux de terrain basés sur Ethernet sont apparus, plus ou moins temps réel, plus ou moins ouverts. Chaque fabricant défend celui qu’il participe à développer. Rockwell, Schneider Electric et Omron défendent Ethernet IP ; BeckHoff soutient Ethercat ; B&R met en avant le protocole OpenSource Ethernet PowerLink, Bosch Rexroth développe Sercos III et enfin GE Fanuc et Phoenix Contact accompagne Siemens dans le développement et la promotion de ProfiNet. A côté de leurs spécificités temps réels, ces bus font tous une place aux messages Ethernet TCP/IP standards pour faciliter le lien avec l’administration (logiciel MES et ERP). (cf article Ethernet Industriel, des stratégies en mouvement, Revue Jautomatise de novembre 2008) L’autre catalogue qu’aiment sortir les commerciaux des fabricants d’équipements d’automatisme est celui des systèmes de communication sans fil. Basés sur des protocoles informatiques (WIFI, WiMax, Zigbee) ou des protocoles spécifiques (ISA 100, Wireless Hart), ces systèmes séduisants pour les installations étendues tardent à s’imposer. (cf article Les protocoles sans fil cherchent à s’imposer de la revue Mesures de septembre 2008) Bus Ethernet « temps réel » ou bus sans fil, la bataille des protocoles fait rage, rythmée par les stratégies commerciales plus que par les performances techniques, tant ces bus performants répondent aux besoins actuels des industriels. Rendez-vous dans la revue 3EI numéro 160 pour faire le point.