DES PRO­TO­COLES DE COM­MU­NI­CA­TION POUR L’USINE DU FU­TUR

RÉ­SEAUX

Mesures - - Front Page - An­toine Cap­pelle

Les ré­seaux de com­mu­ni­ca­tion in­dus­triels s’étendent de plus en plus et trans­forment l’in­dus­trie, au point que l’on parle de nou­velle ré­vo­lu­tion in­dus­trielle. Qu’on l’ap­pelle «Usine du fu­tur» ou «In­dus­trie 4.0», l’in­ter­con­nexion est le maître mot de cette ten­dance. Mais les com­mu­ni­ca­tions de ter­rain ne suf­fisent plus. Les don­nées col­lec­tées par les dif­fé­rents sys­tèmes sont pré­cieuses, et les trans­mettre vers les ni­veaux su­pé­rieurs du ré­seau peut ap­por­ter des avan­tages en termes de su­per­vi­sion, de main­te­nance, voire de ges­tion des stocks. « Les ma­chines ne doivent plus seule­ment être in­ter­con­nec­tées au ni­veau de la pro­duc­tion, mais aus­si ca­pables de re­mon­ter des in­for­ma­tions vers les sys­tèmes de type MES [ Ma­nu­fac­tu­ring Exe­cu­tion Sys­tem ou ges­tion des pro­ces­sus in­dus­triels, NDLR] ou ERP [En­ter­prise Re­source Plan­ning ou pro­gi­ciel de ges­tion in­té­gré, NDLR] », com­mente Gre­go­ry­tha­mi, res­pon­sable du ré­seau de dis­tri­bu­tion de HMS. « Il faut ou­vrir les in­for­ma­tions vers les sys­tèmes in­for­ma­tiques, pour don­ner de la vi­si­bi­li­té en termes de qua­li­té de pro­duc­tion, d’in­di­ca­teurs d’avan­ce­ment », plaide Jé­rôme Pon­cha­ral, ar­chi­tecte so­lu­tion au­to­ma­tismes et lo­gi­ciels chez Ro­ck­well Au­to­ma­tion. Cette dé­marche peut ou­vrir de nou­velles op­por­tu­ni­tés, comme par exemple la per­son­na­li­sa­tion d’une com­mande: « si un client veut ache­ter un mo­dèle de voi­ture avec des spé­ci­fi­ca­tions par­ti­cu­lières, comme des ré­tro­vi­seurs rouges, alors il fau­dra faire en sorte que les bonnes pièces ar­rivent au bon mo­ment au pied de la ma­chine », conti­nue Gre­go­ry­tha­mi (HMS). L’in­for­ma­tion pro­vien­dra par exemple du sys­tème ERP.

Connec­ter des sys­tèmes hé­té­ro­gènes

L’in­ter­con­nexion ne s’ar­rête plus aux murs de l’usine : elle s’étend à tra­vers la pla­nète. Les sites in­dus­triels sont en ef­fet re­liés entre eux, et de plus en plus d’ap­pli­ca­tions se font dé­sor­mais en ligne –sur le cloud. Mais les usines sont en­core lar­ge­ment équi­pées de ma­té­riels hé­té­ro­gènes, conçus par des fa­bri­cants dif­fé­rents et n’ayant pas été op­ti­mi­sés pour ce genre de com­mu­ni­ca­tions. Les dif­fé­rents sys­tèmes ne parlent donc pas tou­jours le même lan­gage. De plus, le monde de l’in­for­ma­tique fonc­tionne bien dif­fé­rem­ment de ce­lui de l’in­dus­trie et n’a pas les mêmes prio­ri­tés.alors quels stan­dards de com­mu­ni­ca­tion adop­ter? « Cette ten­dance a connu une pro­gres­sion conti­nue de­puis des an­nées, rap­pelle Jé­rôme

Pour rendre l’usine du fu­tur tou­jours plus connec­tée, les in­dus­triels de­vront être ca­pables de faire com­mu­ni­quer des sys­tèmes très hé­té­ro­gènes. Ce­la pose la ques­tion des pro­to­coles de com­mu­ni­ca­tion. Peut-on in­té­grer des sys­tèmes an­ciens dans un ré­seau ou­vert sur Ether­net? Quels pro­to­coles s’im­po­se­ront à l’ave­nir? Pour évi­ter les écueils, il faut avant tout bien ré­flé­chir à sa stra­té­gie.

Pon­cha­ral (Ro­ck­well Au­to­ma­tion). Il y avait au­pa­ra­vant une seg­men­ta­tion na­tu­relle entre l’in­for­ma­tique, la ro­bo­tique ou le pro­cess. Chaque sys­tème avait sa tech­no­lo­gie propre, et au­jourd’hui tout fu­sionne en un sys­tème plus plat, qui pose de nou­veaux dé­fis. Cette fu­sion des in­fra­struc­tures né­ces­site une nou­velle ap­proche plus glo­bale. Il faut ap­por­ter flexi­bi­li­té et agi­li­té aux sys­tèmes in­dus­triels ». Ce­la met en jeu plu­sieurs pro­blé­ma­tiques. D’abord, la pé­ren­ni­té du ma­té­riel : « l’élec­tro­nique em­bar­quée dis­pose de ca­pa­ci­tés de cal­cul plus ou moins éle­vées », ex­plique Jé­rôme Pon­cha­ral. Ce­la dé­ter­mine la ca­pa­ci­té de l’équi­pe­ment à trai­ter plus ou moins d’in­for­ma­tions, plus ou moins ra­pi­de­ment. Et ce­la peut li­mi­ter l’adop­tion de tech­no­lo­gies ré­centes. Ce­la est en lien di­rect avec la ques­tion lo­gi­cielle: « les pro­to­coles de com­mu­ni­ca­tion sont du lo gi­ciel, rap­pelle Jé­rôme Pon­cha­ral. C’est l’étage qui per­met de com­mu­ni­quer entre dis­po­si­tifs. Or cer­tains pro­to­coles ont été conçus de fa­çon re­la­ti­ve­ment fi­gée et li­mi­tée, tan­dis que d’autres sont conçus de fa­çon plus in­for­ma­tique et sont par es­sence évo­lu­tifs et ex­ten­sibles ». Les bus de ter­rain, de type Mod­bus ou Pro­fi­bus, cèdent pe­tit à pe­tit leur place. « Ils ne sont plus uti­li­sés sur les nou­velles ins- tal­la­tions », ob­serve Sté­phane Po­tier, in­gé­nieur ex­pert des ré­seaux in­dus­triels chez B&rau­to­ma­tion (grou­peabb). Ils sont pe­tit à pe­tit rem­pla­cés par des stan­dards ba­sés sur Ether­net, comme Pro­fi­net, Po­wer­link ou Ether­net/ip. « Ces der­niers per­mettent d’ac­cé­der à toutes les tech­no­lo­gies web, comme les ser­veurs em­bar­qués. Ils donnent ac­cès à des firm­wares pour des mises à jour ra­pides et ef­fi­caces », dé­crit

Sté­phane Po­tier. L’ether­net in­dus­triel per­met aus­si de ras­sem­bler des tâches di­verses, qui étaient par­fois réa­li­sées à l’aide de pro­to­coles dif­fé­rents : « il est pos­sible de n’avoir qu’un seul câble pour tout faire dans la ma­chine, ex­plique Sté­phane Po­tier. Avant, on trou­vait sou­vent des pro­to­coles mai­son pour la va­ria­tion de vi­tesse, par exemple. Les ar­chi­tec­tures pro­prié­taires étaient mé­lan­gées avec les bus de ter­rain ». Ether­net fa­ci­lite éga­le­ment l’in­ter­fa­çage avec un ré­seau in­for­ma­tique. Mais ce­la n’est pas sans risques : « quel que soit le pro­to­cole Ether­net uti­li­sé, il faut s’as­su­rer de la maî­trise du ré­seau, au risque de voir l’ins­tal­la­tion in­dus­trielle per­tur­bée, pré­vient Franck Noya­ret, chef pro­duit ré­seau in­dus­triel et iden­ti­fi­ca­tion chez Sie­mens. Si l’in­for­ma­tique peut se per­mettre des ar­rêts de quelques se­condes, en pro­duc­tion, ce­la n’est pas sans consé­quences. Le ré­seau est le même, mais les be­soins sont dif­fé­rents. » Il faut donc les iso­ler et ne per­mettre la com­mu­ni­ca­tion qu’à tra­vers une seule «porte» sé­cu­ri­sée. « Il est tout à fait pos­sible de faire co­ha­bi­ter des pro­to­coles ou­verts sur le monde Ether­net à tra­vers des ré­seaux lo­caux vir­tuels (VLAN) », conti­nue Franck Noya­ret. « Ether­net n’est qu’un sup­port, rap­pelle An­to­nio Dos San­tos, res­pon­sable pro­duits en­traî­ne­ments élec­triques chez Bosch Rex­roth. Il existe au­jourd’hui une multitude de pro­to­coles ba­sés sur Ether­net : on ne peut pas dire qu’il y ait un consen­sus sur ceux qui se­raient à pri­vi­lé­gier. Chaque cha­pelle met en avant ses ar­gu­ments. » Les prin­ci­paux fa­bri­cants d’au­to­ma­tismes ont en ef­fet choi­si de tra­vailler avec un pro­to­cole don­né. Ro­ck­well Au­to­ma­tion uti­lise Ether­net/ip : « c’est un pro­to­cole orien­té in­dus­trie, qui ré­pond aux be­soins de contrôle com­mande. Il convient au contrôle d’axes, à la ré­gu­la­tion. Il per­met de mettre en place la sû­re­té de fonc­tion­ne­ment et de s’in­ter­fa­cer avec le monde de la conduite de pro­cess », dé­crit Jé­rôme Pon­cha­ral.

Sie­mens uti­lise le pro­to­cole Pro­fi­net : « Les com­po­sants d’in­fra­struc­ture sont in­té­grés dans ce pro­to­cole, ex­plique Franck Noya­ret. Les cartes d’en­trées/sor­ties ne sont pas sé­pa­rées des au­to­mates. Il est pos­sible d’avoir un diag­nos­tic sur chaque com­po­sant. Tous nos com­mu­ta­teurs sont vus comme des cartes et peuvent re­mon­ter des in­for­ma­tions à l’au­to­mate en cas de pro­blème. » Ces deux pro­to­coles sont les plus uti­li­sés sur Ether­net. Ils de­vraient comp­ter cette an­née pour 11 % cha­cun de parts de mar­ché, se­lon une es­ti­ma­tion de HMS ( voir fi­gure page 35). Mais com­ment rendre in­ter­opé­rables tous les élé­ments de l’usine du fu­tur? « Ce n’est pas pro­blé­ma­tique, es­time Jé­rôme Pon­cha­ral (Ro­ck­wel­lau­to­ma­tion). Il est pos­sible d’uti­li­ser des pas­se­relles pour faire la conver­sion. » Ces dis­po­si­tifs per­mettent en ef­fet de trans­po­ser des in­for­ma­tions d’un pro­to­cole à un autre. « Mais nous al­lons de plus en plus vers la com­mu­ni­ca­tion di­recte, conti­nue-t-il. Le pro­to­cole CIP, qui est à l’ori­gine d’ether­net/ip, est ca­pable de com­prendre Mod­bus. C’est un pro­to­cole suf­fi­sam­ment ou­vert. Ce­pen­dant, la puis­sance de cal­cul peut être une vraie contrainte et em­pê­cher un sys­tème d’ac­cep­ter de nou­veaux lo­gi­ciels, no­tam­ment des firm­wares avec les fonc­tion­na­li­tés re­quises ».

Ci­bler les in­for­ma­tions à re­mon­ter

« Il peut ar­ri­ver que l’on change du ma­té­riel lors­qu’il fonc­tionne sur un bus trop an­cien, mais c’est une dé­marche plu­tôt rare », ob­ser ve Sté­phane Po­tier (B&R Au­to­ma­tion). Le ma­té­riel in­dus­triel a une du­rée de vie éle­vée, et son rem­pla­ce­ment re­pré­sente un coût im­por­tant. On peut ain­si trou­ver des parcs de ma­chines très hé­té­ro­gènes, avec des de­grés de tech­ni­ci­té dif­fé­rents. Sou­vent, il faut donc gé­rer l’in­té­gra­tion du parc exis­tant, dans une dé­marche de mo­der­ni­sa­tion. Gé­né­ra­le­ment, les nou­veaux au­to­mates sont ca­pables de gé­rer les an­ciens pro­to­coles. Cette fonc­tion peut être in­té­grée ou s’ob­te­nir via des cartes op­tion­nelles. Ce­la évite le re­cours aux pas­se­relles. La ques­tion se pose éga­le­ment dans le cas des cap­teurs: peut-on faire re­mon­ter leurs don­nées sans les chan­ger? Le pro­to­cole Io-link ( voir Me­sures n° 864) de­vrait pour ce­la trou­ver sa place dans l’usine du fu­tur. Sou­te­nu par de nom­breux fa­bri­cants, dont Sie­mens, Sick ou en­core Pep­perl+fuchs, il per­met de com­mu­ni­quer avec les cap­teurs et ac­tion­neurs, en uti­li­sant le rac­cor­de­ment à 3 fils dé­jà éta­bli. Pour ce type d’ap­pli­ca­tion, « les pro­to­coles sont une par­tie du pro­blème, ad­met An­to­nio Dos San­tos (Bosch Rex­roth). Mais la vraie pro­blé­ma­tique, quels que soient les pro­to­coles ou la vé­tus­té de la ma­chine, c’est de sa­voir ce que l’on veut re­mon­ter comme in­for­ma­tion. La vé­tus­té est par­fois un faux pro­blème. » L’usine connec­tée passe donc par un bon ca­hier des charges, qui dé­ter­mine quelles don­nées sont im­por­tantes, et pour quelle uti­li­sa­tion. Veut-on faire de la main­te­nance, de l’amé­lio­ra­tion de la per­for­mance ou une ana­lyse par­ti­cu­lière? « Nous avons ap­pli­qué cette ap­proche à nos propres usines, et no­tam­ment sur le site de Ro­dez, qui est de ce point de vue le plus avan­cé, ra­conte An­to­nio Dos San­tos. Une fois que l’ob­jec­tif est dé­fi­ni, nous de­vons com­po­ser avec les ma­chines exis­tantes, an­ciennes et nou­velles. Les sup­ports d’in­for­ma­tion comme les don­nées sont hé­té­ro­gènes. » Les cap­teurs Tout-ouRien (TOR) et les cap­teurs fi­laires, comme les sondes de tem­pé­ra­ture ou les ac­cé­lé­ro­mètres, peuvent cô­toyer des au­to­mates connec­tés sur Pro­fi­bus, ou des sys­tèmes in­tel­li­gents com­mu­ni­quant en Wi-fi ou ex­ploi­tant la tech­no­lo­gie RFID avec des pro­to­coles par­ti­cu­liers. Pour ré­pondre à cette pro­blé­ma­tique, Bosch-rex­roth a dé­ve­lop­pé l’iot Ga­te­way, un sys­tème per­met­tant de mettre en forme l’en­semble des don­nées ré­col­tées afin de les mettre à dis­po­si­tion des ni­veaux su­pé­rieurs. « C’est une agré­ga­tion d’ap­pli­ca­tions, ba­sées sur une pla­te­forme Ja­va vir­tuelle, qui s’ins­talle sur un contrô­leur et s’adapte aux dif­fé­rents types de cap­teurs connec­tés », pré­cise An­to­nio Dos San­tos. Ce sys­tème per­met donc de com­po­ser avec le contexte exis­tant, sans le per­tur­ber ni ajou­ter de couches lo­gi­cielles aux au­to­mates. On passe ain­si du ter­rain au ni­veau de la ges­tion de pro­duc­tion, sans trans­for­mer les pro­to­coles de com­mu­ni­ca­tion. « Ce­la oblige à struc­tu­rer la dé­marche, en se de­man­dant quelles in­for­ma­tions sont pro­duites par une ma­chine, et quelle est leur lo­ca­li­sa­tion, ar­gu­mente An­to­nio Dos San­tos. En­fin, ce­la fa­ci­lite l’in­té­gra­tion de ma­chines an­ciennes. » Mais quelles que soient les so­lu­tions exis­tantes pour gé­rer un parc hé­té­ro­gène, « il est im­por­tant de sen­si­bi­li­ser les fa­bri­cants de ma­chines afin qu’ils pré­dis­posent leurs pro­duits à ce type d’in­té­gra­tion, es­time-t-il. Plus le client au­ra conscience de la no­tion de qua­li­té d’in­for­ma­tion à re­mon­ter,

plus le fa­bri­cant les met­tra à dis­po­si­tion. Ce­la passe par le dia­logue ». Les ac­teurs du monde in­dus­triel sont gé­né­ra­le­ment bien conscients des en­jeux de l’in­ter­opé­ra­bi­li­té. Ain­si, ABB, Bosch Rex­roth, B&R Au­to­ma­tion, Ge­ne­ral Elec­tric, Ku­ka ou en­core Sch­nei­der Elec­tric ont dé­ci­dé de s’as­so­cier pour pro­mou­voir la tech­no­lo­gie OPC UA comme so­lu­tion de com­mu­ni­ca­tion uni­fiée entre les contrô­leurs in­dus­triels et vers le cloud. « Les au­to­mates vont par­ler di­rec­te­ment avec un SCADA », illustre Ste­phane Po­tier (B&R Au­to­ma­tion). « OPC UA, his­to­ri­que­ment, est l’ou­til des in­for­ma­ti­ciens pour dia­lo­guer avec le contrôle com­mande, rap­pelle Jé­rôme Pon­cha­ral (Ro­ck­well Au­to­ma­tion). On le trouve sur des ser­veurs in­for­ma­tiques, qui com­mu­niquent avec des sys­tèmes au­to­ma­ti­sés. » Mais cette tech­no­lo­gie est « plus qu’un pro­to­cole de com­mu­ni­ca­tion, ex­plique Mi­chel Con­de­mine, di­rec­teur gé­né­ral de 4CE In­dus­try et re­pré­sen­tant tech­nique D’OPC en France. La ré­duire à ce­la se­rait pas­ser à cô­té de 80 % de ses fonc­tion­na­li­tés. OPC UA ap­porte éga­le­ment des mo­dèles d’in­for­ma­tion, c’est-à-dire des fa­çons d’or­ga­ni­ser des don­nées par rap­port à dif­fé­rents mé­tiers. Les deux grandes mo­ti­va­tions, pour les uti­li­sa­teurs, sont de gé­rer l’hé­té­ro­gé­néi­té de leurs sys­tèmes et la cy­ber­sé­cu­ri­té ». OPC UA est ba­sé sur des stan­dards ou­verts. « C’est un ra­fraî­chis­se­ment tech­no­lo­gique, es­time Jé­rôme Pon­cha­ral (Ro­ck­well Au­to­ma­tion). C’est un monde plus open source, en com­pa­rai­son de ce que l’on connaît par exemple avec Mi­cro­soft. Ce­la per­met­tra un re­nou­veau mé­tho­do­lo­gique en termes de dé­ve­lop­pe­ment, avec des ou­tils à jour. » Les en­tre­prises in­ves­ties dans la pro­mo­tion de cette tech­no­lo­gie sou- haitent QU’OPC UA soit sup­por­té par les fu­tures gé­né­ra­tions de sys­tèmes in­dus­triels, pour une meilleure in­ter­opé­ra­bi­li­té. Mais tous les ac­teurs du mi­lieu n’ont pas la même vi­sion de la place que pour­rait prendre cette tech­no­lo­gie. « Cer­tains im­plé­mentent OPC UA sur des contrô­leurs, ob­serve Jé­rôme Pon­cha­ral. Chez Ro­ck­well Au­to­ma­tion, nous avons plu­tôt choi­si de l’uti­li­ser comme une so­lu­tion in­for­ma­tique, pour l’ar­chi­vage, la com­mu­ni­ca­tion avec les lo­gi­ciels MES ou ERP. » OPC UA ne consti­tue­ra donc pas un pro­to­cole uni­ver­sel dans les pro­chaines an­nées, mais il a une place im­por­tante à prendre. « Et pour ce­la, la for­ma­tion est im­por­tante, in­siste Sté­phane Po­tier (B&R Au­to­ma­tion). Il faut trou­ver les bons pro­fils pour abor­der la ques­tion de bout en bout, com­prendre les ré­seaux, les don­nées pro­duites par les cap­teurs, aus­si bien que le cloud. Conce­voir un ré­seau né­ces­si­te­ra des com­pé­tences très vastes, aus­si bien en Big Da­ta qu’en mé­ca­tro­nique, en pas­sant par la sé­cu­ri­té : c’est un vrai dé­fi ! » « Je pense qu’à l’ave­nir, de nou­velles tech­no­lo­gies vien­dront ap­por­ter tou­jours plus de per­for­mances au ré­seau, pour gé­rer tou­jours plus d’in­for­ma­tions. C’est une évo­lu­tion in­con­tour­nable, pré­voit Jé­rôme Pon­cha­ral (Ro­ck­well Au­to­ma­tion). À l’usage, beau­coup de choses vont chan­ger. Nous n’avons en­core que grat­té la sur­face de ce que la mo­bi­li­té pour­rait ap­por­ter, ain­si que le par­tage et la col­la­bo­ra­tion. Les évo­lu­tions tech­niques ne sont pas des ré­vo­lu­tions, elles prennent du temps. » Les choix de pro­to­coles de com­mu­ni­ca­tion doivent donc ac­com­pa­gner cette marche vers l’ou­ver­ture et l’in­ter­con­nexion.

La col­lecte de don­nées par un maxi­mum de cap­teurs et de ma­chines per­met de suivre en temps réel l’état d’une pro­duc­tion, ou de mettre en place un sys­tème de main­te­nance pré­ven­tive.

L’usine du fu­tur se­ra tou­jours plus connec­tée, avec des sys­tèmes in­for­ma­tiques in­ternes, mais aus­si avec l’ex­té­rieur. Ce­la né­ces­site l’usage de pro­to­coles de com­mu­ni­ca­tion les plus uni­ver­sels pos­sibles.

Le pro­to­cole Io-link, conçu pour com­mu­ni­quer avec les cap­teurs et les ac­tion­neurs, est sou­te­nu par de nom­breux fa­bri­cants d’équi­pe­ments.

L’ef­fi­ca­ci­té des com­mu­ni­ca­tions sans fil dé­pend du choix d’un pro­to­cole adap­té, mais aus­si de la bonne ins­tal­la­tion des an­tennes. Des ap­pa­reils de tests per­mettent de vé­ri­fier leur ef­fi­ca­ci­té.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.