Les pas­se­relles de com­mu­ni­ca­tion in­dus­trielles

Les ré­seaux in­dus­triels font par­fois co­ha­bi­ter des équi­pe­ments an­ciens avec des sys­tèmes plus ré­cents, ou des ma­chines is­sues de dif­fé­rents fa­bri­cants. Dans de nom­breux cas de fi­gure, ces équi­pe­ments ne parlent pas la même langue. Pour faire com­mu­ni­quer e

Mesures - - Front Page -

Dans les ré­seaux in­dus­triels, les bus perdent du ter­rain. Les pro­to­coles ba­sés sur Ether­net ont pris leur place sur les nou­veaux équi­pe­ments. Mais les sys­tèmes in­dus­triels ont une du­rée de vie im­por­tante: des ma­chines uti­li­sant des pro­to­coles plus an­ciens sont donc tou­jours ins­tal­lées, et cette si­tua­tion de­vrait du­rer en­core des an­nées. Même sur Ether­net, les pro­to­coles sont nom­breux, et le lan­gage uni­ver­sel est en­core loin. C’est donc aux pas­se­relles qu’il re­vient d’as­su­rer la tra­duc­tion des com­mu­ni­ca­tions. Des pas­se­relles dé­diées à la simple ges­tion d’un bâ­ti­ment à celles em­ployées dans un process cri­tique sou­mis à des normes strictes, le prix peut va­rier d’une cen­taine à plu­sieurs di­zaines de mil­liers d’eu­ros: le mar­ché est vaste.

Des sys­tèmes hé­té­ro­gènes

Une pas­se­relle est un sys­tème per­met­tant de conver­tir un mes­sage d’un pro­to­cole à l’autre. « On les re­trouve dans le bâ­ti­ment aus­si bien que dans le process », pré­cise Gré­go­ry­tha­mi, res­pon­sable du ré­seau de dis­tri­bu­tion de HMS. La com- mu­ni­ca­tion est une par­tie in­té­grante de la vie d’une ma­chine ou d’une usine, et il est né­ces­saire de faire com­mu­ni­quer entre eux des sys­tèmes hé­té­ro­gènes. » La pas­se­relle va pour ce­la se ser­vir d’une table d’échanges entre les deux pro­to­coles : « On lit les don­nées d’un cô­té, et on les met à dis­po­si­tion de l’autre, ré­sume Ré­my Gue­dot, gé­rant de la so­cié­té RG2I, qui dis­tri­bue no­tam­ment des pas­se­relles in­dus­trielles. Par­fois, on a be­soin au pas­sage de conver­tir des don­nées, faire des cal­culs, ou uti­li­ser des fonc­tions lo- giques. Il existe pour ce­la des pas­se­relles pro­gram­mables, mais ce­la ne se fait pas sur tous les pro­to­coles. »Tous les fa­bri­cants ne pro­posent pas ce type de fonc­tions: « Nous n’avons pas vo­ca­tion à mo­di­fier l’in­for­ma­tion qui passe sur une pas­se­relle, ex­plique Gré­go­ry Tha­mi (HMS). Nos sys­tèmes ef­fec­tuent une simple conver­sion, le plus ra­pi­de­ment pos­sible, sans rien ajou­ter, ni trai­ter les don­nées. » Ces be­soins peuvent se re­trou­ver dans toutes sortes d’ap­pli­ca­tions in­dus-

trielles, aus­si bien pour l’ins­tru­men­ta­tion que pour le process. « Cer­taines ma­chines ont des ins­tru­ments dé­ve­lop­pés sur une base RS (de type sé­rie). Nous avons en­core de la de­mande pour des cartes d’en­trées/sor­ties ba­sées sur ces pro­to­coles, ob­serve Ro­nan Bre­mont, chef de pro­duit au­to­ma­tion chez Phoe­nix Con­tact. Les scan­ners de codes-barres, par exemple, ont long­temps été dé­ve­lop­pés ain­si, avant de pas­ser sur Ether­net. » « Lorsque l’on ré­amé­nage de vieilles ins­tal­la­tions, avec de vieux au­to­mates, il faut gé­rer des pro­to­coles da­tant par­fois de 20 ou 30 ans, conti­nue Ré­my Gue­dot (RG2I). Les pro­to­coles de type CAN ou De­vi­ce­net, par exemple, cor­res­pon­dant à des ap­pli­ca­tions de ter­rain, peuvent être uti­li­sés sur une ma­chine. Mais lorsque l’on veut re­mon­ter des in­for­ma­tions, on se re­trouve au­jourd’hui très vite avec des pro­to­coles ba­sés sur Ether­net. Pro­fi­net et Mod­bustcp sont les deux grands stan­dards de ce type au­jourd’hui ». « Plus l’in­dus­trie s’au­to­ma­tise, plus on a de nou­veaux pro­to­coles », in­dique Pierre-yves Mo­rel, res­pon­sable grands comptes chez HMS. Les pro­to­coles uti­li­sés dé­pendent no­tam­ment du sec­teur d’ac­ti­vi­té, mais aus­si des ré­seaux com­mer­ciaux. Se­lon les zones géo­gra­phiques, cer­tains fa­bri­cants d’équi­pe­ments sont plus ou moins bien im­plan­tés. Bac­net, Lon­works, M-bus ou en­core KNX sont ain­si pré­sents dans le sec­teur du bâ­ti­ment, pour la ges­tion de la cli­ma­ti­sa­tion, des in­ter­rup­teurs ou des au­to­ma­tismes. « Ce do­maine voit fleu­rir des pro­to­coles in­com­pa­tibles entre eux », note Pierre-yves Mo­rel. À l’in­verse, d’autres pro­to­coles dé­clinent ou dis­pa­raissent, comme FIP, Ba­ti­bus, ou en­core DF-1. Ce­la ar­rive quand le prin­ci­pal four­nis­seur veut se mettre à jour, et passe ses ma­chines sur un sys­tème Ether­net pour ob­te­nir une meilleure per­for­mance. Les dif­fé­rents pro­to­coles ont leur spé­cia­li­té. Cô­té in­dus­trie, par exemple, Hart est plu­tôt dé­dié aux cap­teurs. OPC Uni­fied Ar­chi­tec­ture (UA), dont la de­mande est émer­gente, a pour vo­ca­tion à faire re­mon­ter des in­for­ma­tions du ter­rain vers les ni­veaux su­pé­rieurs. « Cer­tains pro­to­coles vont vite, mais pas loin, com­mente Ré­my Gue­dot (RG2I). On les uti­lise en lo­cal, sur une ma­chine par exemple, sur quelques mètres. D’autres sont plus lents, mais vont plus loin. » Les pro­to­coles fer­més sont de moins en moins uti­li­sés: « Les in­ter­fa­cer entre eux coû­tait très cher en pas­se­relles, rap­pelle Ré­my Gue­dot. Au­jourd’hui, les clients en ont as­sez d’être liés

avec un construc­teur lors­qu’ils doivent chan­ger des élé­ments du ré­seau. Il faut être sur des stan­dards ! » Par­mi les pro­to­coles an­ciens tou­jours pré­sents au­jourd’hui, ceux sur base RS sont en­core cou­rants: « Ils re­groupent les pro­to­coles CAN, Ca­no­pen, De­vi­ce­net ou Pro­fi­bus DP, rap­pelle Ro­nan Bre­mont (Phoe­nix Con­tact). Les grosses so­cié­tés pou­vaient dé­ve­lop­per leur propre pro­to­cole à par­tir de RS- 485 ou de RS-232. » Le plus ré­pan­du de ces pro­to­coles est Pro­fi­bus, sui­vi par Mod­bus: « Ce der­nier exis­tait dé­jà il y a 35 ans, et l’on m’a tou­jours dit que c’était fi­ni, s’amuse Ré­my Gue­dot (RG2I). Mais ce pro­to­cole est fa­cile à uti­li­ser et à pa­ra­mé­trer. De nom­breux pro­duits sont com­pa­tibles, et cer­tains su­per­vi­seurs ont ce pro­to­cole en stan­dard. Ce n’est pas le plus per­for­mant, mais il s’est im­po­sé mon­dia­le­ment par sa ro­bus­tesse, sa sim­pli­ci­té et son ou­ver­ture. »« Tout le monde pou­vait dé­ve­lop­per sur Mod­bus, et c’est un pro­to­cole très uti­li­sé éga­le­ment en ins­tru­men­ta­tion, com­plète Ro­nan Bre­mont (Phoe­nix Con­tact). Il per­met de com­mu­ni­quer des in­for­ma­tions plus com­plètes que le tout Tout-ou-rien (TOR) ou l’ana­lo­gique, ce qui est utile pour la me­sure. »Au­jourd’hui, « Mod­bus est sou­vent le point com­mun entre les dif­fé­rents équi­pe­ments d’une ins­tal­la­tion, conti­nue Ré­my Gue­dot (RG2I). Il per­met de re­mettre à plat des don­nées qui peuvent être com­pli­quées à ma­ni­pu­ler lorsque l’on change de pro­to­cole, comme les hor­loges. En­fin, à par­tir d’une su­per­vi­sion clas­sique, Mod­bus TCP est la so­lu­tion la plus fa­cile pour ho­mo­gé­néi­ser ses don­nées ». Dans l’in­dus­trie, les ré­seaux Ether­net prennent de plus en plus de place. « Il

est fa­cile de bâ­tir une in­fra­struc­ture ré­seau avec Ether­net, pour­suit Ré­my Gue­dot. On ajoute des com­mu­ta­teurs, des conver­tis­seurs de mé­dia, et l’on peut fa­ci­le­ment re­lier une ins­tal­la­tion à une autre si­tuée à l’autre bout de la pla­nète. De plus, il y a tou­jours des nou­veau­tés. » Par­mi les pro­to­coles Ether­net, « Mod­bus TCP est l’un des pre­miers. Il est très uti­li­sé en France car na­tif sur les au­to­mates de Sch­nei­der Elec­tric, rap­pelle Ro­nan Bre­mont (Phoe­nix Con­tact). Très fa­cile d’uti­li­sa­tion, il montre tou­te­fois ses li­mites face à l’aug­men­ta­tion du vo­lume et de la com­plexi­té des don­nées ». Bien dé­fi­nir les pro­to­coles en jeu sur le ré­seau est la pre­mière étape dans le choix d’une pas­se­relle. La sui­vante est de spé­ci­fier le­quel se­ra le maître, et le­quel se­ra l’es­clave. Se­lon le fa­bri­cant, le vo­ca­bu­laire peut chan­ger : cer­tains parlent plu­tôt de « scan­ner » que de maître. La ques­tion est de sa­voir quel sys­tème gère les échanges. « Sou­vent, les uti­li­sa­teurs ne savent pas y ré­pondre », note Ré­my Gue­dot (RG2I). La quan­ti­té de don­nées à faire tran­si­ter est un autre pa­ra­mètre im­por­tant. Les bus de ter­rain ne per­mettent pas de trans­por­ter au­tant de don­nées que l’ether­net, et la quan­ti­té que peut trai­ter une pas­se­relle est li­mi­tée. Mais il est pos­sible de dou­bler la pas­se­relle en cas de be­soins dé­pas­sant la ca­pa­ci­té du mo­dèle. Le temps de ré­ponse peut éga­le­ment être li­mi­tant : Mod­bus TCP n’est pas dé­ter­mi­niste, son temps de ré­ponse peut être su­pé­rieur à 100 mil­li­se­condes. Les ma­chines do­tées de nom­breux mo­teurs, comme pour de la dé­coupe ou de l’em­bal­lage, né­ces­sitent de bas­cu­ler vers d’autres pro­to­coles. « Le rem­plis­sage de bou­teilles, par exemple, né­ces­site une ca­dence très im­por­tante, illustre Ro­nan Bre­mont (Phoe­nix Con­tact). C’est une ap­pli­ca­tion im­pen­sable en Mod­bus. » D’autres stan­dards sont mieux adap­tés, comme Ether­net/ip ou Pro­fi­net. Lors­qu’il s’agit de temps réel, c’est du cô­té d’ether­cat qu’il faut se pen­cher. « Ce stan­dard est lié à l’avè­ne­ment de so­cié­tés comme Beck­hoff, pré­cise Ch­ris­tophe Szy­ma­niak, chef de pro­duits chez ifm elec­tro­nic. Ex­trê­me­ment ra­pide, il monte en puis­sance, car les be­soins sont de plus en plus im­por­tants ».

La crois­sance d’ether­net

Se­lon les don­nées de HMS, l’ether­net in­dus­triel re­pré­sen­tait en 2016 une part de mar­ché de 46%, avec une crois­sance an­nuelle de 22%. « Mais, en pa­ral­lèle, les bus de ter­rain conti­nuent à croître eux aus­si », note Gré­go­ry Tha­mi (HMS). Avec 4% de crois­sance an­nuelle et 48% de parts de mar­ché, ils res­tent de­vant l’ether­net. Les 6 % res­tants sont dé­vo­lus au sans-fil (crois­sance an­nuelle de 32%). « L’ether­net n’est pas tou­jours in­té­res­sant, com­mente Gré­go­ry Tha­mi. Les bus de ter­rain, plus lents, sont par­fois plus fiables. L’in­dus­trie de process, comme la chi­mie, uti­lise en­core beau­coup de liai­sons sé­rie. Pas­ser en Ether­net né­ces­si­te­rait des in­fra­struc­tures dif­fé­rentes. Les der­niers pro­ces­seurs des fa­bri­cants d’au­to­ma­tismes ont Ether­net en na­tif. Il faut par­fois leur ajou­ter des cartes pour bus de ter­rain, ou des pas­se­relles. » Comme pour les bus de ter­rain, les grands fa­bri­cants d’au­to­ma­tismes ont cha­cun fait le choix de sou­te­nir un pro­to­cole ba­sé sur Ether­net. Ro­ck­well Au­to­ma­tion uti­lise Ether­net/ip, qui re­pré­sen­tait en 2016 11% de parts de mar­ché. Pro­fi­net, dé­fen­du par Sie­mens, a la même im­por­tance. On trouve en­suite Ether­cat à 7%. Viennent en­suite Mod­bus TCP et Po­wer­link, cha­cun à 4%. « Pour les plus pe­tits ré­seaux, il y a moins de têtes de file », note Pierre-yves Mo­rel (HMS), qui pré­voit à l’ave­nir « un ef­fet de tas­se­ment, mais pas un pro­to­cole unique. » « Chaque pro­to­cole a ses propres spé­ci­fi­ci­tés,

il est donc dif­fi­cile d’avoir une pas­se­relle gé­né­rique », es­time Ro­nan Bre­mont (Phoe­nix Con­tact). L’éten­due du choix re­flète la di­ver­si­té des pro­to­coles uti­li­sés par l’in­dus­trie. Le nombre de com­bi­nai­sons pos­sibles est très vaste. « Nous pro­po­sons plus de 400 com­bi­nai­sons dif­fé­rentes », pré­cise Gré­go­ry­tha­mi (HMS). Mais même une telle gamme ne couvre pas tous les pro­to­coles : « Nous ne pou­vons pas tout avoir. Cer­tains sont sur des mar­chés trop ci­blés. Avant de lan­cer une nou­velle so­lu­tion, ce qui re­pré­sente des in­ves­tis­se­ments lourds, nous fai­sons une étude de mar­ché, pour voir si ce­la vaut le coup d’un point de vue éco­no­mique », ajoute-t-il. Quand ce n’est pas le cas, l’en­tre­prise, qui compte 30 % de son ef­fec­tif en re­cherche et dé­ve­lop­pe­ment, peut par­fois pro­po­ser à ses clients de par­ti­ci­per aux frais de dé­ve­lop­pe­ment d’une so­lu­tion spé­ci­fique. Mais la plus grande par­tie du mar­ché des pas­se­relles est dé­diée à la conver­sion de pro­to­coles en base RS vers l’ether­net. « L’exemple de conver­sion le plus clas­sique est de trans­for­mer un si­gnal en Mod­bus RTU vers Mod­bus TCP, ba­sé sur Ether­net. Ce type de pas­se­relle est ac­tuel­le­ment le plus ven­du », ob­serve Ro­nan Bre­mont (Phoe­nix Con­tact). Moxa, qui fa­brique éga­le­ment des pas­se­relles, fait le même constat. En ef­fet, si le parc exis­tant de ma­chines uti­li­sant le pro­to­cole Mod­bus RTU est en­core im­por­tant, les PC et les au­to­mates, eux, sont de moins en moins do­tés de ports RS. L’adap­ta­tion d’an- ciennes ins­tal­la­tions né­ces­site donc l’em­ploi de pas­se­relles. L’un des fac­teurs li­mi­tants pour l’usage des pas­se­relles reste tou­te­fois le temps de conver­sion d’un pro­to­cole à l’autre. « Pour cer­taines ap­pli­ca­tions, le contrôle de mou­ve­ment en par­ti­cu­lier, il faut des temps de ré­ac­tion ex­trê­me­ment courts », pré­cise Pierre-yves Mo­rel (HMS). « Mais il est rare que, sur un ré­seau in­dus­triel, le couple entre l’élec­tro­nique et la mé­ca­nique soit cas­sé, tem­père Gré­go­ry­tha­mi (HMS). Le choix du ma­té­riel se fait sur l’en­semble de la chaîne, de la com­mande au mo­teur, et au co­deur. Il n’y a nor­ma­le­ment pas be­soin de pas­se­relle à cet en­droit. » En ef­fet, le rôle d’une pas­se­relle est plu­tôt de syn­chro­ni­ser ces ma­chines à un

Cer­tains mo­dèles de pas­se­relles in­dus­trielles sont au­jourd’hui conçus pour l’in­ter­net des ob­jets (IOT), et pro­posent des fonc­tions d’ana­lyses de don­nées.

Cer­taines pas­se­relles as­so­cient des ports phy­siques et des in­ter­faces sans fil.

Chaque pro­to­cole de com­mu­ni­ca­tion a ses ca­rac­té­ris­tiques propres. Cer­tains sont adap­tés aux ap­pli­ca­tions en temps réel, d’autres offrent l’avan­tage de la sim­pli­ci­té…

La crois­sance des bus de ter­rain ra­len­tit, au pro­fit des pro­to­coles ba­sés sur Ether­net, qui fa­ci­litent le lien avec les ré­seaux in­for­ma­tiques clas­siques.

Les ser­veurs em­bar­qués sont dé­sor­mais une ca­rac­té­ris­tique cou­rante des pas­se­relles. Ils per­mettent no­tam­ment de fa­ci­li­ter la confi­gu­ra­tion. Phoe­nix Con­tact

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.