L'embarqué > Normes & spécifications > Architecture > "Faut-il remplacer EtherCAT par OPC UA au niveau des bus de terrain industriels ?"

"Faut-il remplacer EtherCAT par OPC UA au niveau des bus de terrain industriels ?"

Publié le 14 avril 2020 à 12:06 par François Gauthier        Architecture IntervalZero

L'Embarqué Tribune IntervalZero

[TRIBUNE de Yves de la Broise, INTERVALZERO] Avec les dernières publications officielles de la fondation OPC sur OPC UA et TSN, il est maintenant possible d’utiliser OPC UA/TSN à l’intérieur même des machines industrielles jusqu’au niveau du bus de terrain. De nombreux acteurs majeurs dans le monde de l’industrie encouragent même à utiliser cette technologie en remplacement des bus de terrain. Yves de la Broise, ingénieur en informatique industrielle chez IntervalZero, compare ici ce nouveau standard à EtherCAT, l’un des bus de terrain les plus populaires dans l’industrie.

Tandis qu’EtherCAT a été conçu comme un bus de terrain et ensuite étendu vers d’autres types d’applications avec EAP (EtherCAT Automation Protocol), OPC UA (OPC Unified Architecture), quant à lui, a été développé au niveau de la supervision SCADA (Supervisory Control And Data Acquisition ou système de contrôle et d'acquisition de données en temps réel). Comme tout protocole de communication au niveau supervision, OPC UA propose la sécurité de communication Ethernet, l’échange de données complexes et l’appel de fonctions à distance. Ce qui le rend idéal aussi bien pour des communications de type SCADA vers les machines ou SCADA vers le cloud, que pour des communications de machine à machine ou de machine vers les capteurs intelligents.

Quant à TSN (Time-Sensitive Networking), il ajoute des fonctionnalités de priorisation au protocole Ethernet, qui permettent à un bus de terrain de fonctionner au-dessus. Le plus important étant la synchronisation des horloges et le déterminisme des délais de transmission. Il est présenté comme une évolution majeure qui permet de faire aussi bien du contrôle que de la vision, du streaming et de la navigation Internet, et tout ceci sur un seul réseau. Mais il y a également des restrictions. TSN ne dispose que de 4 niveaux de priorité et un seul est assez déterministe pour le contrôle de données : il n’est donc pas possible d’avoir plusieurs bus de terrain traversant le même commutateur. Par ailleurs, le déterminisme est assuré par la réservation d’intervalles de temps, ce qui veut dire que lorsqu’une trame de haute priorité est attendue, le commutateur TSN va arrêter toutes transmissions en l’attendant. Le temps de transmission d’une trame étant de l’ordre de la microseconde, quand il y a plusieurs priorités, la réservation d’intervalles de temps est très consommatrice en bande passante.

OPC UA + TSN, la panacée ?

En associant OPC UA et TSN, il est possible de synchroniser de multiples contrôleurs et de les faire communiquer de façon sûre et en temps réel. Un exemple de cas d’utilisation est une application de système de contrôle distribué (DCS) dans laquelle un seul programme peut superviser de multiples contrôleurs. Un unique contrôleur peut également communiquer avec des centaines d’entrées/sorties et de variateurs. Mais, pour autant, OPC UA/TSN est-il le meilleur protocole pour ce type d’utilisation ?

Commençons par la topologie du réseau. OPC UA/TSN utilise une topologie de réseau en étoile, tandis qu'EtherCAT utilise une topologie en boucle. La topologie en étoile permet à l’utilisateur de déconnecter n’importe quel équipement (entrées/sorties, variateurs…) sans interrompre le réseau. Toutefois, cette topologie demande deux fois plus de câbles que la topologie en boucle et requiert des commutateurs. Par conséquent, la topologie en étoile est adaptée à des réseaux comprenant assez peu d’équipements connectés. Dès lors que le nombre d’équipements est supérieur à une vingtaine, la configuration, la maintenance et le coût d’une topologie en étoile peuvent devenir problématiques. Le seul cas dans lequel la topologie en étoile est intéressante est lorsqu’une machine est supposée continuer à fonctionner quand un ou plusieurs équipements sont déconnectés.

Cependant si la machine est supposée entrer en mode sécurité lorsqu’un équipement est déconnecté, alors la topologie en boucle est plus appropriée et moins chère. Une des caractéristiques les plus intéressantes d’EtherCAT est que les données de tous les équipements sont agrégées dans une seule trame. Pour les équipements avec peu de données, cela permet d’utiliser la bande passante du réseau et les ressources CPU de façon optimale.

En revanche, lorsque les équipements utilisent des données plus complexes avec des tailles variables, telles que des appels de fonctions à distance, chaque requête peut remplir une trame à elle seule. Dans ce cas, OPC UA est un meilleur choix. Si l’on regarde le problème de l’accès aux équipements, chacun des deux protocoles permet un accès complet aux équipements connectés du réseau. Avec OPC UA/TSN, le fait d’avoir les équipements directement connectés au contrôleur permet d’utiliser les outils d’accès. Avec EtherCAT, les technologies EoE (Ethernet over EtherCAT) et FoE (File over EtherCAT) permettent de configurer et même de mettre à jour les esclaves EtherCAT connectés au réseau.

La principale différence est qu’avec OPC UA, les équipements sont directement exposés, induisant des risques plus élevés en termes de sécurité. Alors qu’avec EtherCAT, le contrôleur possède une fonction ajoutée de passerelle qui lui permet de contrôler l’accès aux équipements. Ainsi, lorsque les équipements sont hiérarchisés comme un contrôleur avec des modules d’entrées/sorties, avoir une passerelle est un avantage. Par contre, si chaque équipement doit pouvoir fonctionner indépendamment, il n’est pas bon de créer une hiérarchie dans le traitement de données.

Un choix, fonction de deux grandes classes d’utilisation

En se basant sur les différences énoncées ci-dessus, on peut distinguer deux cas d’utilisation.

Dans le premier cas, plusieurs contrôleurs coopèrent et partagent du matériel. Par exemple, une machine avec un automate programmable (PLC, programmable logic controller), un contrôleur de vision et un contrôleur de robot qui gèrent un ensemble réduit d’équipements. Dans ce cas, OPC UA/TSN est intéressant. Il permet notamment d’ajouter ou de retirer des équipements du réseau à tout moment et de les mettre à jour indépendamment les uns des autres. Ils ont tous un accès direct aux ressources nécessaires.

Le second cas concerne un contrôleur de machine. Par exemple, une machine d’inspection avec un contrôleur, 40 entrées/sorties et 10 axes. Dans ce cas, EtherCAT est parfaitement approprié. Pour fonctionner correctement, une configuration OPC UA aurait besoin ici d’un réseau dédié car 40 trames par cycle au niveau du contrôle sont nécessaires. Par ailleurs, il faudra 5 commutateurs et 50 câbles en plus. Avec EtherCAT, un seul transfert de paquet est nécessaire et les données et l’accès aux esclaves sont sécurisés par le contrôleur.

Pour conclure, OPC UA est idéal pour la communication entre contrôleurs, il a été conçu pour cela. L’apport de TSN permet également de remplir les caractéristiques d’un bus de terrain, mais cela n’en fait pas pour autant la meilleure solution pour ce type de communication. Au niveau de la machine, OPC UA/TSN nécessitera plus de matériels (commutateur, câbles) et consommera plus de ressources (bande passante réseau, CPU et mémoire). EtherCAT est conçu et optimisé pour le contrôle de machine, et par conséquent reste toujours la meilleure solution techniquement et financièrement pour cette dernière utilisation.

Sur le même sujet