La présente invention concerne un système de communication dans un automate programmable permettant de réaliser, sur le bus de communication interne de l'automate programmable, des échanges conformes au protocole TCP/IP. L'invention concerne également un automate programmable susceptible de mettre en oeuvre un tel système de communication. Ce système peut s'appliquer à tout process automatisé et notamment au domaine des automatismes industriels, des automatismes du bâtiment ou du contrôle/commande des réseaux électriques de distribution.

Le protocole standard IP (Internet Protocol) définit un protocole d'interconnexion entre différents réseaux de communication, au niveau de la couche réseau. Le protocole standard TCP (Transport Control Protocol) définit, au niveau de la couche transport, un mécanisme de transport des données robuste et fiable garantissant un contrôle des données de bout en bout. Ces deux protocoles sont utilisés dans des réseaux globaux de type Internet, Intranet ou Extranet, qui seront regroupés dans le présent exposé sous le terme "réseau TCP/IP".

Un automate programmable modulaire pilotant un process à automatiser comporte au moins un module unité centrale dans lequel s'exécute un programme application pour le contrôle/commande du process. L'automate programmable peut également comporter, si besoin, un ou plusieurs modules métier dotés eux aussi d'une unité de traitement pour assurer des fonctions d'automatisme (pesage, régulation, positionnement, communication,...) ainsi que d'autres modules tels que des modules d'entrées/sorties (digitales ou analogiques). Dans la suite de l'exposé, le terme "module intelligent" représentera indifféremment un module unité centrale, un module métier ou tout module doté d'une unité de traitement propre. Les modules d'un automate programmable sont reliés entre eux par un bus de communication interne, qui est généralement un bus de type fond de panier. Les protocoles utilisés sur un bus de communication interne sont habituellement des protocoles propriétaires.

Dans un automate programmable, il est connu de disposer d'un module de communication, appelé ci-après module réseau, connecté au bus de communication interne de l'automate et relié à un réseau TCP/IP. Un tel module réseau peut alors servir de passerelle entre d'un côté le protocole TCP/IP utilisé sur le réseau TCP/IP et de l'autre côté un ou plusieurs protocoles implantés sur le bus de communication interne de l'automate. Un module intelligent de l'automate connecté au bus de communication interne, par exemple le module unité centrale, peut ainsi accéder au réseau TCP/IP au travers de la passerelle de ce module réseau.

Cependant, dans ces conditions, il n'est pas possible de maintenir les caractéristiques d'une communication selon le protocole TCP/IP de bout en bout entre deux entités communiquant entre elles. En effet, la passerelle que constitue un module réseau coupe le flux de données de TCP et n'assure pas non plus la transparence de IP. On perd ainsi les avantages en performance, en fiabilité et en transparence que procurent le protocole TCP/IP. Or, il serait avantageux de pouvoir bénéficier de ce protocole standard pour des communications à partir ou à destination de modules intelligents d'un automate programmable.

Le document EP0977412 décrit un procédé d'attribution d'adresses entre des unités d'un système de conduite industriel. Chaque unité est constituée d'un ordinateur et peut se voir attribuer une adresse IP individuelle pour communiquer sur un réseau local externe, selon les protocoles IP, TCP ou UDP. Notre demande concerne au contraire un système de communication entre modules intelligents à l'intérieur d'un automate programmable modulaire assimilable à une seule unité programmable d'exploitation.

Le document US5710708 concerne un système de contrôle pour une pluralité de machines de filature. Le système comprend une architecture de communication à plusieurs niveaux. Un même protocole de communication, tel que le protocole TCP/IP, peut être utilisé dans les différents niveaux de l'architecture. Néanmoins, ce document ne décrit pas que, pour échanger des informations conformes au protocole TCP/IP sur le bus de communication interne, un module intelligent d'un automate programmable comporte une adresse IP propre et une pile TCP/IP exécutable par l'unité de traitement du module intelligent.

Le but de l'invention est donc de proposer à des modules intelligents connectés au bus de communication interne d'un automate programmable un accès direct au protocole TCP/IP pour effectuer des échanges entre eux et des échanges sur un réseau TCP/IP, sans avoir recours à une passerelle au niveau de la couche application qui peut se révéler coûteuse. De plus, grâce au protocole TCP/IP, le module unité centrale ou des modules métier d'un automate programmable pourront directement utiliser les protocoles et les architectures du WEB comme par exemple les standards UDP, HTTP, XML, WAP, FTP, SMTP, SNMP, DHCP, DNS, etc...

Pour cela, l'invention décrit un système de communication dans un automate programmable modulaire qui comprend plusieurs modules intelligents dotés d'une unité de traitement propre et qui comprend un bus de communication interne permettant de faire communiquer les modules de l'automate programmable entre eux. Le système de communication se caractérise par le fait que, pour communiquer conformément au protocole de communication TCP/IP sur le bus de communication interne, un module intelligent de l'automate programmable comporte une adresse IP propre et une pile TCP/IP exécutable par l'unité de traitement du module intelligent, et par le fait que le bus de communication interne comporte plusieurs canaux de communication séparés permettant de faire circuler simultanément des trames conformes au protocole TCP/IP avec des trames conformes à d'autres protocoles.

De plus, un automate programmable modulaire peut comporter au moins un module réseau, raccordé à un réseau TCP/IP externe, permettant à un coupleur intelligent de l'automate programmable de réaliser directement sur le réseau TCP/IP des échanges d'informations conformes au protocole de communication TCP/IP, via le bus de communication interne.

D'autres caractéristiques vont apparaître dans la description détaillée qui suit en se référant à un mode de réalisation donné à titre d'exemple et représenté par les dessins annexés sur lesquels:

• la figure 1 représente un exemple d'architecture de base d'un automate programmable doté d'un système de communication conforme à l'invention et comprenant un module unité centrale, un module réseau, un module métier et un module d'entrées/sorties,
• les figures 2 et 3 détaillent respectivement un premier mode de fonctionnement A et un second mode de fonctionnement B du système de communication.

Dans la figure 1, un automate programmable 50 modulaire, chargé de piloter un process à automatiser, est constitué d'un module unité centrale 20 (CPU), d'un module réseau 10, d'un module métier 30, d'un module entrées/sorties 40 et d'un bus de communication interne 5 reliant les différents modules de l'automate programmable 50 entre eux. Le nombre et le type de modules acceptés dans un automate 50 dépend de la taille et de la puissance de cet automate.

Le module unité centrale 20 comporte une unité de traitement 21 chargée d'exécuter un programme application pour piloter le process. Le module unité centrale 20 contrôle généralement les autres modules de l'automate programmable 50. Un module métier 30 comporte une unité de traitement propre 31, telle qu'un microcontrôleur ou un microprocesseur, pour effectuer une ou plusieurs fonctions d'automatisme dédiées, comme par exemple du comptage, de la communication, de la régulation, du positionnement, de la commande d'axe, etc. Un module d'entrée/sorties 40 est chargé d'acquérir des entrées venant du process et d'envoyer des sorties vers le process; il peut dans certains cas disposer lui aussi d'une unité de traitement 41 simplifiée. Les différents modules 10,20,30,40 de l'automate 50 peuvent échanger grâce à un bus de communication interne 5 qui est généralement le bus fond de panier de l'automate.

Le module réseau 10 possède une unité de traitement propre 11 et est connecté à un réseau TCP/IP externe 9 grâce à un driver d'accès 19 pour la couche liaison et à un adaptateur au médium du réseau TCP/IP 9 (non schématisé en figure 1) pour la couche physique. De façon préférentielle, le réseau TCP/IP 9 s'appuie sur le standard Ethernet pour les couches physique et liaison, de sorte que le driver d'accès 19 gère notamment un adressage MAC (Media Access Control) du coupleur réseau 10, conforme à la couche liaison MAC préconisée dans la norme IEEE802.3 ou dans la norme RFC894. Comme indiqué en début de l'exposé, le réseau TCP/IP 9 utilise le protocole TCP/IP au niveau des couches réseau et transport. Dans l'exemple de la figure 1, le module unité centrale 20 et le module métier 30 sont des modules intelligents susceptibles de communiquer sur le réseau TCP/IP 9.

Le bus de communication interne 5 doit disposer de la possibilité de faire circuler des trames correspondant à des flux de communication différents : en plus d'un flux IP de communication lié aux trames du protocole TCP/IP, il existe en effet sur le bus de communication 5 un flux IO de données des entrées/sorties de l'automate et éventuellement d'autres flux de données liés par exemple à une messagerie propriétaire. En conséquence, ces flux sont acheminés dans le bus de communication 5 sur des canaux de communication distincts qui doivent travailler au niveau de la couche liaison et être capable de véhiculer n'importe quelle trame. Sur la figure 1, sont représentés un canal de communication 6 pour le flux IP et un canal de communication 7 pour le flux IO d'entrées/sorties.

Pour se raccorder au bus de communication 5, les modules 10,20,30,40 comportent des drivers d'accès au bus qui gèrent la couche physique et la couche liaison du bus de communication et qui doivent être spécifiques à chaque canal de communication. Pour le canal de communication 7 correspondant au flux IO, les modules 10,20,30,40 possèdent un driver d'accès 17,27,37,47. Pour le canal de communication 6 correspondant au flux IP, les modules 10,20,30 possèdent un driver d'accès 16,26,36. Le module d'entrées/sorties 40 n'ayant pas d'accès au réseau TCP/IP 9, il ne dispose pas de driver d'accès au flux IP.

Le système de communication permet à des modules intelligents 20,30 de communiquer par le protocole TCP/IP soit entre eux, soit directement sur un réseau TCP/IP 9 raccordé à un module réseau 10. Pour cela, les modules intelligents 20,30 comportent chacun une pile TCP/IP 22,32 (stack TCP/IP) exécutable par l'unité de traitement 21,31 du module intelligent 20,30. Cette pile TCP/IP 22,32 est reliée au driver d'accès 26,36 du flux IP et gère les couches réseau et transport du protocole TCP/IP. Chaque module intelligent 20,30 doit également posséder son adresse IP propre.

A l'intérieur d'un automate programmable 50, une communication directe par TCP/IP entre modules intelligents peut être intéressante par exemple lorsqu'un des modules est un coupleur IHM (Interface Homme-Machine) qui se présente sous la forme d'un navigateur HTTP et qui peut de façon native échanger des informations selon le protocole TCP/IP. Il pourra alors communiquer avec des modules intelligents de l'automate sans avoir besoin de développer d'autres protocoles.

Deux modes de fonctionnement du système de communication vont maintenant être détaillés, en référence aux figures 2 et 3 :

• Dans un premier mode de fonctionnement, appelé fonctionnement A et détaillé en figure 2, le bus de communication 5 n'est qu'un prolongement du réseau TCP/IP 9 sur lequel le module réseau 10 est connecté. Dans ce cas, celui-ci ne sert qu'à router les trames IP émises ou destinées à un module intelligent 20,30. Le module réseau 10 n'a alors pas besoin de comporter sa propre pile TCP/IP, sauf s'il se comporte lui-même comme un module intelligent capable de posséder des applications WEB.
  Pour qu'un module intelligent 20,30 de l'automate accède directement au réseau TCP/IP 9 d'un module réseau 10, il faut que :
  • la pile TCP/IP 22,32 du module intelligent 20,30 soit capable d'émettre et de recevoir des trames ayant une encapsulation conforme à la couche liaison (couche MAC) du réseau TCP/IP 9,
  • chaque module intelligent 20,30 possède une table de routage IP pour router les trames émises par lui vers le (ou les) module(s) réseau(x) 10,10' de l'automate 50,
  • le module réseau 10 possède des moyens de filtrage et de redirection 13 des trames IP en provenance du réseau TCP/IP 9 en fonction de l'adresse IP 24,34 des modules intelligents 20,30, permettant de n'envoyer vers ces modules 20,30 que les trames comportant leur adresse IP. Ce filtrage est possible grâce à une table de mémorisation de l'adresse IP des modules intelligents 20,30 de l'automate 50 susceptibles d'accéder au réseau TCP/IP 9, cette table de mémorisation étant stockée dans le module réseau 10.
• Dans un deuxième mode de fonctionnement, appelé fonctionnement B et détaillé en figure 3, le bus de communication 5 est vu comme un sous-réseau IP à part entière du réseau TCP/IP 9 sur lequel le module réseau 10 est connecté. Dans ce cas, le module réseau 10 comporte deux attachements IP matérialisés par une première adresse IP 15 correspondant au réseau TCP/IP 9 et par une deuxième adresse IP 14 correspondant au bus de communication 5 de l'automate 50. Le module réseau 10 possède aussi obligatoirement sa propre pile TCP/IP 12 exécutable dans le module réseau 10 permettant de faire le routage des trames entre les deux attachements IP.
  En fonction de l'adresse du sous-réseau IP sur le bus de communication 5, on peut choisir le niveau de visibilité d'un module sur le réseau TCP/IP 9. Si on veut que le module soit vu par l'Internet sans mise à jour de routeur externe, il faut que le bus de communication 5 ait un adressage comportant un même numéro de sous-réseau IP que le réseau TCP/IP 9 du module réseau 10, comme le montre la figure 3. En plus, celui-ci doit agir comme un proxy serveur pour un proxy client se trouvant sur le bus de communication 5. Par rapport au mode de fonctionnement A, c'est le coupleur qui répond à une requête de reconnaissance d'adresse MAC (requête ARP sur Ethernet).

Comme indiqué en figure 2, un même automate programmable peut comporter plusieurs modules réseau 10,10' chacun connecté à un réseau TCP/IP 9,9' différent possédant chacun un numéro IP de réseau 8,8'. Dans ce cas, les flux IP générés par chaque réseau TCP/IP 9,9' sont acheminés par des canaux séparés 6,6' sur le bus de communication 5. Pour pouvoir se connecter à ces différents réseaux Internet arrivant sur l'automate 50, un module intelligent 20 doit alors posséder une adresse IP spécifique 24,24' respectivement pour chaque réseau TCP/IP 9,9'.

Compte tenu du fait que, grâce à l'invention, un module intelligent 20,30 peut être directement connecté sur l'Internet, les aspects de sécurité sont importants. Un premier niveau de sécurité est normalement assuré par un coupe-feu Intranet quand l'automate 50 est raccordé à un réseau de type Intranet 9. Néanmoins, si l'on souhaite mieux contrôler l'accès aux modules intelligents, il existe plusieurs possibilités : on peut rajouter dans le module réseau 10 un filtrage supplémentaire des trames IP, on peut faire un contrôle des connexions rentrantes au-dessus de la couche TCP et on peut aussi renoncer au comportement proxy serveur du module réseau 10 pour éviter qu'un module intelligent 20,30 soit vu automatiquement par l'extérieur sans configuration de routeur externe, dans les fonctionnements A et B. Par ailleurs, ces deux fonctionnements A et B sont compatibles avec la norme RFC925 et ils évitent la mise à jour de tables de routage dans un réseau existant.

Le système de communication décrit dans la présente invention peut être utilisé par un programme application d'un automate programmable pour communiquer des données de synchronisation, de contrôle, de commande ou toute autre information nécessitant la qualité des services offerts par les protocoles de la famille TCP/IP. Par ailleurs, une connexion aisée au monde de l'Internet et du WEB est un avantage majeur par rapport aux protocoles propriétaires. A l'intérieur d'un tel automate programmable, il est ainsi possible de développer un module intelligent (de type PC par exemple) équipé d'un système d'exploitation et d'un navigateur Internet du commerce afin de réaliser le dialogue opérateur homme machine. Utiliser le protocole TCP/IP dans un bus de communication automate est aussi une voie privilégiée pour normaliser les échanges de donnée internes à un automate programmable, cette normalisation facilitant une interopérabilité dans un environnement hétérogène.

De même, il est possible de véhiculer des données auxquelles les automates programmables ne sont pas habituellement utilisés comme le son ou la vidéo, ces informations pouvant être exploitées par l'application elle-même (un module de capture vidéo relié à un module de traitement vidéo) ou pouvant servir à des applications externes et aux services liés à l'automatisme (par exemple télémaintenance d'une installation d'automatisme).

Les données échangées peuvent également être du code programme. Ces programmes peuvent être applicatifs pour modifier le comportement d'un module, lui ajouter des fonctionnalités, mettre à jour une version logicielle, corriger une anomalie, l'espionner lors des phases de développement et permettre des services plus précis en télémaintenance. Ce mécanisme permet d'offrir ainsi au monde de l'automatisme les bases d'une architecture distribuée de traitement.