Im­plé­men­ter la tech­no­lo­gie TSN avec des com­po­sants stan­dards du mar­ché

Electronique S - - La Une -

Dans les ap­pli­ca­tions d’au­to­ma­ti­sa­tion in­dus­trielles, les ex­ten­sions de la norme IEEE 802.1Q pour la com­mu­ta­tion Ether­net, ré­per­to­riées sous le terme gé­né­rique Time Sen­si­tive Net­wor­king (TSN), per­mettent la mise en oeuvre de so­lu­tions d’au­to­ma­ti­sa­tion avec une ar­chi­tec­ture ré­seau ho­mo­gène de­puis les cap­teurs vers le cloud. Et, bien que ré­cente, la tech­no­lo­gie TSN peut d’ores et dé­jà être im­plé­men­tée avec des com­po­sants élec­tro­niques stan­dard dans de nom­breuses ap­pli­ca­tions.

Dans les ap­pli­ca­tions d’au­to­ma­ti­sa­tion in­dus­trielles, les so­lu­tions tra­di­tion­nelles uti­li­sant des normes de ré­seau pro­prié­taires au ni­veau du ter­rain pour ga­ran­tir un temps réel « dur » im­pliquent tou­jours une cer­taine dis­con­ti­nui­té dans l’ar­chi­tec­ture du ré­seau. Mais une tech­no­lo­gie ré­sout cette dis­con­ti­nui­té, en fa­ci­li­tant le flux d’in­for­ma­tions entre le ni­veau ter­rain et les ni­veaux su­pé­rieurs de la hié­rar­chie d’au­to­ma­ti­sa­tion. Les ex­ten­sions de la norme IEEE 802.1Q pour la com­mu­ta­tion Ether­net, ré­per­to­riées sous le terme gé­né­rique Time Sen­si­tive Net­wor­king (TSN), per­mettent en ef­fet des so­lu­tions d’au­to­ma­ti­sa­tion avec une ar­chi­tec­ture ré­seau ho­mo­gène de­puis les cap­teurs vers le cloud. En outre, avec cette tech­no­lo­gie, les uti­li­sa­teurs et les fa­bri­cants d’équipe- ments bé­né­fi­cient éga­le­ment d’un ma­té­riel uni­fié, of­frant flexi­bi­li­té et éco­no­mies. Un autre avan­tage consiste en un meilleur usage des équi­pe­ments et des câbles ins­tal­lés grâce à une uti­li­sa­tion com­mune pour une grande va­rié­té d’ap­pli­ca­tions, sans risque d’in­ter­fé­rence mu­tuelle. En rai­son des avan­tages ap­pa­rents men­tion­nés ci-des­sus, l’in­tro­duc­tion de la tech­no­lo­gie TSN dans le monde de l’au­to­ma­ti- sa­tion n’est plus re­mise en ques­tion au­jourd’hui. Les va­ria­tions de stra­té­gie dans ce sec­teur sont mi­nimes et se trouvent es­sen­tiel­le­ment dans le ti­ming et le sé­quen­ce­ment des étapes, tout au plus. Si bien qu’au­jourd’hui, des fa­bri­cants pro­posent dé­jà sur le mar­ché les pre­miers pro­duits com­pa­tibles TSN. Et ce n’est qu’un dé­but car d’autres sont en­ga­gés, et d’autres en­suite leur em­boî­te­ront pro­gres­si­ve­ment le pas. Une ques­tion clé lors de l’in­tro­duc­tion de nou­velles tech­no­lo­gies ré­side tou­te­fois dans la large dis­po­ni­bi­li­té du ma­té­riel ap­pro­prié. Les normes TSN sont en­core re­la­ti­ve­ment nou­velles et leur mise en oeuvre dans les com­po­sants se­mi-conduc­teurs dé­diés de­mande du temps. D’un autre cô­té, seule une pe­tite par­tie – mais es­sen­tielle – des normes TSN né­ces­site un sup­port ma­té­riel dé­dié. De nom­breuses fonc­tions liées à TSN, par exemple pour la ges­tion de ré­seau, sont pu­re­ment lo­gi­cielles et peuvent fa­ci­le­ment être mises en oeuvre sur n’im­porte quel ma­té­riel. Au­jourd’hui, les équi­pe­men­tiers ont deux op­tions prin­ci­pales à leur dis­po­si­tion pour im­plé­men­ter la fonc­tion­na­li­té TSN dans leurs équi­pe­ments. D’une part, les in­ter­faces ré­seau FPGA offrent une ap­proche flexible pour in­té­grer ra­pi­de­ment les der­nières fonc­tions dans les pro­duits. Mais ce­la a un coût lié à trois fac­teurs dis­tincts,

à sa­voir les coûts de pro­duits re­la­ti­ve­ment éle­vés, les ef­forts de dé­ve­lop­pe­ment pour la lo­gique FPGA in­cluant les tests et la cer­ti­fi­ca­tion, et éven­tuel­le­ment les coûts de li­cence IP. D’autre part, le mar­ché pro­pose au­jourd’hui des se­mi-conduc­teurs stan­dard qui four­nissent des fonc­tions TSN vé­ri­fiées à faible coût. Ce­ci est réa­li­sable parce qu’au lieu de réin­ven­ter la roue, les normes TSN, qui sont lar­ge­ment ba­sées sur des concepts éprou­vés, dé­ve­loppent et gé­né­ra­lisent ces concepts. En fonc­tion des exi­gences spé­ci­fiques de l’ap­pli­ca­tion, en uti­li­sant ces com­po­sants, il est dé­jà pos­sible – et c’est une pra­tique cou­rante au­jourd’hui – d’im­plé­men­ter la fonc­tion­na­li­té TSN dans des so­lu­tions d’au­to­ma­ti­sa­tion ba­sées sur des com­po­sants stan­dard dis­po­nibles sur le mar­ché.

Tech­no­lo­gie TSN pour sys­tème d’au­to­ma­ti­sa­tion

Les de­mandes sur les élé­ments de ré­seau, en par­ti­cu­lier sur les noeuds d’ex­tré­mi­té et les com­mu­ta­teurs, va­rient se­lon leur fonc­tion et leur confi­gu­ra­tion dans le ré­seau. L’in­ter­face ré­seau d’un au­to­mate pro­gram­mable in­dus­triel (API) ou d’un cal­cu­la­teur à la pé­ri­phé­rie du ré­seau doit être plus ef­fi­cace que celle d’un ap­pa­reil de ter­rain simple. De même, les com­mu­ta­teurs à ce ni­veau doivent éga­le­ment faire face à une charge ré­seau beau­coup plus éle­vée que leurs ho­mo­logues dans une ligne à l’ex­tré­mi­té in­fé­rieure du ni­veau ter­rain. Ce­la se re­flète dans les exi­gences mi­ni­males pour les com­po­sants correspondants, de sorte que, sur­tout dans le do­maine des com­po­sants de ter­rain simples, des so­lu­tions sim­pli­fiées pour des to­po­lo­gies en ligne ou en an­neau sont réa­li­sables avec seule­ment deux ports Ether­net ex­ternes. La fa­mille de sous-normes TSN pro­pose deux mé­thodes prin­ci­pales pour la trans­mis­sion chro­no­lo­gi­que­ment dé­ter­mi­niste: prio­ri­sa­tion et pré­emp­tion de trame (asyn­chrone) et trans­mis­sion contrô­lée par le temps dans des cré­neaux tem­po­rels ré­ser­vés (mé­thode TDMA, syn­chrone). Un mix des deux mé­thodes peut éga­le­ment être uti­li­sé. Ac­tuel­le­ment, dans le do­maine de l’au­to­ma­ti­sa­tion in­dus­trielle, l’ac­cent est mis sur la trans­mis­sion contrô­lée par le temps de don­nées en temps réel via TSN. Ce prin­cipe a dé­jà fait ses preuves dans des normes éta­blies telles que Pro­fi­net IRT, SERCOS III, EtherCAT ou Po­wer­link. La norme TSN IEEE802.1Qbv étend et gé­né­ra­lise les mé­ca­nismes pro­prié­taires exis­tants pour agran­dir leur champ d’ap­pli­ca­tion et per­mettre la co­exis­tence de dif­fé­rents sys­tèmes temps réel dans un do­maine ré­seau com­mun sans in­ter­ac­tion mu­tuelle. La trans­mis­sion tem­po­ri­sée se­lon Qbv évite les col­li­sions in­dé­si­rables entre dif­fé­rents flux de don­nées, lais­sant le com­mu­ta­teur sur un port com­mun. Si le com­po­sant en cours de dis­cus­sion est uni­que­ment un noeud fi­nal avec un seul port Ether­net, c’est-à-dire sans fonc­tion­na­li­té de com­mu­ta­tion in­té­grée pour la trans­mis­sion, un contrôle suf­fi­sam­ment pré­cis du temps de trans­mis­sion des trames Ether­net in­di­vi­duelles est suf­fi­sant pour la par-

ti­ci­pa­tion à la com­mu­ni­ca­tion TSN contrô­lée par le temps. Une syn­chro­ni­sa­tion tem­po­relle pré­cise de tous les com­po­sants du ré­seau par­ti­ci­pant avec une précision in­fé­rieure à la mi­cro­se­conde est une con­di­tion préa­lable né­ces­saire à l’uti­li­sa­tion ef­fi­cace de la trans­mis­sion tem­po­ri­sée. Les pro­cé­dures éta­blies en confor­mi­té avec IEEE 1588 et IEEE 802.1AS placent les mêmes exi­gences sur le ma­té­riel. Les com­po­sants correspondants doivent dis­po­ser d’une hor­loge PTP (Pre­ci­sion Time Pro­to­col, PTP est un pro­to­cole Ether­net de syn­chro­ni­sa­tion d’hor­loge) à par­tir du­quel les ho­ro­da­tages sont dé­ri­vés lors de l’en­voi et de la ré­cep­tion des mes­sages de syn­chro­ni­sa­tion tem­po­relle. La fré­quence et la phase de l’hor­loge PTP doivent être ajus­tables par syn­chro­ni­sa­tion tem­po­relle.

TSN dans les com­po­sants exis­tants

Cer­tains des com­po­sants se­mi-conduc­teurs ac­tuel­le­ment dis­po­nibles sur le mar­ché, tels que ceux de la fa­mille Re­ne­sas RZ/N1, offrent dé­jà des mé­ca­nismes tels que la syn­chro­ni­sa­tion tem­po­relle de haute précision et la trans­mis­sion contrô­lée en temps en uti­li­sant la mé­thode TDMA. TSN uti­li­se­ra le nou­veau pro­to­cole IEEE 802.1AS-Rev ba­sé sur IEEE 1588 et n’im­pose au­cune exi­gence sup­plé­men­taire au ni­veau ma­té­riel. Comme al­ter­na­tive au­jourd’hui, est dé­ployé soit son pré­dé­ces­seur, l’IEEE 802.1AS, soit l’IEEE 1588, qui était uti­li­sé jus­qu’ici. Les dif­fé­rences entre la mise en oeuvre des deux se trouvent ex­clu­si­ve­ment dans les couches lo­gi­cielles. La tech­nique TDMA a éga­le­ment dé­jà été im­plé­men­tée dans les puces dis­po­nibles en tant qu’ex­ten­sion de la spé­ci­fi­ca­tion Qav. Dans ce cas, les trames Ether­net sont clas­sées se­lon Qav afin de les af­fec­ter à des in­ter­valles de temps in­di­vi­duels dans un cycle de trans­mis­sion. Ce mé­ca­nisme est le pré­dé­ces­seur de la sous-norme TSN Qbv. Une puce avec un sup­port 1588/.1AS et Qav + TDMA est ap­pro­priée pour réa­li­ser une fonc­tion­na­li­té TSN Qbv sim­pli­fiée. Ce­la per­met d’ex­ploi­ter les avan­tages de la tech­no­lo­gie TSN au ni­veau du ter­rain dans les noeuds d’ex­tré­mi­té simples pour le câ­blage en étoile, ain­si que pour les to­po­lo­gies en ligne ou en an­neau et les formes mixtes. La fi­gure 1 montre la struc­ture de la fonc­tion TDMA dans les blocs RZ/N1. À l’ex­tré­mi­té su­pé­rieure, les trames Ether­net en­trantes sont re­layées vers leurs ports de des­ti­na­tion par le mo­teur de trans­fert. Là, chaque trame est clas­sée se­lon des cri­tères confi­gu­rables et pla­cée dans l’une des quatre files d’at­tente de sor­tie (Q1 à Q4). L’hor­loge gPTP (ge­ne­ra­li­zed Pre­ci­sion Time Pro­to­col) est syn­chro­ni­sée avec l’heure ré­seau du do­maine TSN. Toutes les tranches de temps du mé­ca­nisme TDMA en sont dé­ri­vées. Les in­ter­valles de temps avec une lon­gueur confi­gu­rable in­di­vi­duel­le­ment sont spé­ci­fiés de ma­nière cen­tra­li­sée pour tous les ports Ether­net du com­po­sant dans une liste de contrôle de porte ( Gate Control List) avec quatre en­trées. Contrô­lée via des masques de bit, des files d’at­tente de ports de sor­tie ar­bi­traires peuvent être ou­vertes dans chaque in­ter­valle de temps. Dans ce contexte, «ou­vert» si­gni­fie que les trames Ether­net, qui sont dans une file d’at­tente, peuvent at­teindre le MAC et donc le câble via un contrôle prio­ri­taire. Le contrôle de prio­ri­té sé­lec­tionne tou­jours la trame Ether­net de la file d’at­tente ou­verte la plus prio­ri­taire pour la trans­mis­sion. Ce­pen­dant, les trames Ether­net dans les files d’at­tente « fer­mées » ne sont pas trans­fé­rées dans l’in­ter­valle de temps cor­res­pon­dant. Les dif­fé­rences dans le ma­té­riel com­pa­tible Qbv ré­sident prin­ci­pa­le­ment dans le nombre de files d’at­tente et d’in­ter­valles de temps dif­fé­rents, c’est-à-dire la di­ver­si­fi­ca­tion dans la ges­tion des trames Ether­net in­di­vi­duelles. Le ta­bleau 1 en montre une com­pa­rai­son dé­taillée. Par exemple, les com­po­sants de la fa­mille Re­ne­sas RZ/ N1 sup­portent quatre files d’at­tente et quatre in­ter­valles de temps. À titre de com­pa­rai­son, la norme TSN Qbv dé­fi­nit huit files d’at­tente et laisse le nombre d’in­ter­valles de temps non dé­fi­ni. En de­hors de ce­la, bien qu’un com­mu­ta­teur com­pa­tible Qbv ait une hor­loge gPTP cen­trale, la liste de contrôle de portes est spé­ci­fique au port de sorte que chaque port du com­mu­ta­teur puisse avoir un pro­gramme in­di­vi­duel. Pour un dis­po­si­tif de ter­rain avec un seul port Ether­net et des dis­po­si­tifs de ter­rain dans une simple to­po­lo­gie en ligne ou en an­neau uti­li­sant le com­mu­ta­teur in­té­gré, les li­mi­ta­tions ci-des­sus sont sou­vent ac­cep­tables. Ce­la est dû au fait que seuls quelques flux en temps réel dif­fé­rents doivent être trans­mis, et le pro­gramme de trans­mis­sion pour tous les ports est iden­tique pour per­mettre un flux non obs­trué des trames Ether­net à tra­vers le com­po­sant, et donc à tra­vers la ligne ou l’an­neau. L’exemple d’ap­pli­ca­tion TSN sui­vant illustre ce point.

Exemple d’ap­pli­ca­tion TSN

L’exemple de confi­gu­ra­tion de la fi­gure 2 illustre com­ment une so­lu­tion d’au­to­ma­ti­sa­tion ba­sée sur TSN peut être construite à l’aide des fonc­tion­na­li­tés des com­po-

sants RZ/N1 dis­po­nibles. Un au­to­mate pro­gram­mable in­dus­triel (API) com­pa­tible TSN, exis­tant phy­si­que­ment dans l’ins­tal­la­tion ou vir­tuel­le­ment dans un cal­cu­la­teur à la pé­ri­phé­rie du ré­seau, com­mande un grand nombre de com­po­sants E/S (com­po­sants TEP n.m) or­ga­ni­sés en deux lignes. Comme al­ter­na­tive, une struc­ture en an­neau se­rait éga­le­ment pos­sible ici. Le tra­fic ré­seau est tem­po­ri­sé et syn­chro­ni­sé avec les cycles de fonc­tion­ne­ment de l’au­to­mate. Les cycles de fonc­tion­ne­ment de l’au­to­mate se com­posent de trois phases: lec­ture des va­leurs ef­fec­tives à par­tir des équi­pe­ments d’E/S, cal­cul de nou­velles va­leurs de sor­tie via le pro­gramme de l’au­to­mate et sor­tie des nou­velles va­leurs de sor­tie vers les équi­pe­ments ter­mi­naux. Au fil du temps, les phases 1 et 3 se che­vauchent. La ligne prin­ci­pale TSN consti­tuée des com­mu­ta­teurs TSN TSW 1 et TSW 2 doit gé­rer tout le tra­fic ré­seau entre l’au­to­mate et les sous-an­neaux et, si né­ces­saire, éga­le­ment comme in­di­qué par les com­mu­ta­teurs TSW x1 et TSW x2, le tra­fic croi­sé sup­plé­men­taire entre les com­po­sants ré­seau connec­tés au seg­ment en cours d’exa­men. Ce­la né­ces­site un sup­port com­plet des normes TSN Qbv et, si né­ces­saire, Qbu par les com­mu­ta­teurs TSW 1 et TSW 2 de la ligne prin­ci­pale. Les exi­gences dans les sous-lignes sont beau­coup moins im­por­tantes. Les com­po­sants TEP n.m doivent uni­que­ment ache­mi­ner le tra­fic ré­seau vers et de­puis les com­po­sants voi­sins. Leur rôle en tant que point d’ex­tré­mi­té TSN est li­mi­té à un seul flux en temps réel dans la di­rec­tion d’émis­sion et de ré­cep­tion pour la com­mu­ni­ca­tion avec l’au­to­mate pro­gram­mable et d’autres com­mu­ni­ca­tions non cri­tiques dans le temps, par exemple pour la syn­chro­ni­sa­tion de l’heure ou en tant que ser­veur OPC-UA. Le ta­bleau 2 de cet exemple montre les dif­fé­rentes classes et leur af­fec­ta­tion au ma­té­riel dis­po­nible des com­po­sants de la fa­mille RZ/N1 qui rem­plissent toutes les exi­gences de la fonc­tion TSN re­quise dans cette cons­tel­la­tion. Dans l’exemple, tous les com­po­sants ré­seau, com­mu­ta­teurs et noeuds fi­naux sont syn­chro­ni­sés entre eux via le pro­to­cole de syn­chro­ni­sa­tion tem­po­relle IEEE 802.1AS et uti­lisent la trans­mis­sion tem­po­ri­sée pour évi­ter les col­li­sions in­dé­si­rables. La com­mu­ni­ca­tion se dé­roule dans une trame à temps fixe qui se ré­pète cy­cli­que­ment. L’af­fec­ta­tion des classes aux in­ter­valles de temps de cette trame pour les équi­pe­ments des sous-lignes est éga­le­ment in­di­quée dans le ta­bleau 2. Le temps de cycle et la du­rée des in­ter­valles de temps in­di­vi­duels dé­pendent de l’ap­pli­ca­tion. L’in­ter­valle de temps T est tou3 jours vide, c’est-à-dire qu’au­cune file d’at­tente ne peut être envoyée pen­dant cette pé­riode et doit avoir la lon­gueur de la trame Ether­net la plus longue. Ce­ci ga­ran­tit que les ports de sor­tie au dé­but de la fe­nêtre temps réel T sont tou­jours 0 libres et ne sont pas oc­cu­pés par la trame pré­cé­dente, ce qui au­rait conduit à un re­tard in­dé­si­rable lors de l’en­voi de la trame en temps réel.

Sché­ma de com­mu­ni­ca­tion

Tous les points d’ex­tré­mi­té TEP n.m en­voient leurs va­leurs ef­fec­tives en tant que va­riables d’en­trée à l’au­to­mate au dé­but de chaque cycle ré­seau. L’au­to­mate en­voie pour sa part les nou­velles va­leurs de sor­tie cal­cu­lées dans le der­nier cycle aux ex­tré­mi­tés. À cet ef­fet, sur chaque ligne et sur la ligne prin­ci­pale, un in­ter­valle de temps T est 0 ré­ser­vé pen­dant le­quel seules les don­nées en temps réel sont trans­fé­rées entre les points d’ex­tré­mi­té TEP n.m et l’au­to­mate. Les col­li­sions avec d’autres tra­fics ré­seau sont im­pos­sibles, de sorte que le temps de trans­mis­sion maxi­mum vers et de­puis chaque point d’ex­tré­mi­té est ga­ran­ti. Les noeuds d’ex­tré­mi­té trans­mettent leurs va­leurs ef­fec­tives à leurs com­mu­ta­teurs de ré­seau prin­ci­pal su­pé­rieurs TSW 1 et TSW 2 dans les deux lignes si­mul­ta­né­ment. Ceux-ci col­lectent les don­nées et les en­voient à l’au­to­mate. Ici aus­si, les col­li­sions entre les trames des deux lignes sont ex­clues car les com­mu­ta­teurs de la ligne prin­ci­pale trans­mettent les don­nées de chaque ligne dans un cré­neau tem­po­rel sé­pa­ré. Ce­la né­ces­site des res­sources ap­pro­priées dans les com­mu­ta­teurs de la ligne prin­ci­pale. Les va­leurs de sor­tie sont trans­mises en deux étapes pour at­teindre l’ar­ri­vée la plus si­mul­ta­née pos­sible des va­leurs de sor­tie de l’au­to­mate à chaque noeud d’ex­tré­mi­té TEP n.m; d’abord, à la ligne 2, qui est éloi­gnée d’un com­mu­ta­teur, puis à la ligne 1. L’in­ter­valle de temps T dans les sous0 lignes doit être suf­fi­sam­ment long pour four­nir le temps né­ces­saire à la trans­mis- sion de toutes les va­riables de sor­tie. L’échange si­mul­ta­né de va­leurs de sor­tie ef­fec­tives et nou­velles s’exé­cute sans col­li­sion et ne né­ces­site au­cune me­sure sup­plé­men­taire car les don­nées cir­culent dans des di­rec­tions op­po­sées. Lorsque toutes les va­leurs ef­fec­tives ont at­teint l’au­to­mate dans leur fe­nêtre de trans­mis­sion dé­fi­nie et que les nou­velles va­leurs de sor­tie sont ar­ri­vées à tous les noeuds, l’au­to­mate com­mence à trai­ter son pro­gramme uti­li­sa­teur qui cal­cule les nou­velles va­leurs de sor­tie à par­tir des va­leurs ef­fec­tives. Les noeuds de sor­tie traitent leurs nou­veaux points de consigne de ma­nière syn­chrone en fonc­tion de l’heure syn­chro­ni­sée à l’échelle du ré­seau, de sorte que tous les com­po­sants changent leurs états de sor­tie si­mul­ta­né­ment. Une fois que l’au­to­mate a ter­mi­né ses cal­culs, le cycle de ré­seau sui­vant en­chaîne sans in­ter­rup­tion. Des don­nées sup­plé­men­taires peuvent être trans­fé­rées au-de­là des in­ter­valles de temps ré­ser­vés sur la ligne prin­ci­pale TSN et dans les lignes un et deux sans avoir à s’in­quié­ter de tout ef­fet sur le sys­tème temps réel en fonc­tion­ne­ment. Par exemple, des don­nées en temps réel RT x peuvent être en­cap­su­lées entre des seg­ments de ré­seau ad­ja­cents dans des in­ter­valles de temps in­di­vi­duels tant que le dé­bit de don­nées to­tal des élé­ments de ré­seau in­di­vi­duels four­nit une bande pas­sante ré­si­duelle suf­fi­sante. Des flux de don­nées im­por­tants sup­plé­men­taires sont uti­li­sés pour la syn­chro­ni­sa­tion tem­po­relle ou pour in­ter­ro­ger des ob­jets OPC-UA. TSN de­meure une norme ré­cente et la mise en place du sup­port ma­té­riel né­ces­saire est en cours. Mais même avec des com­po­sants stan­dard du com­merce tels que ceux de la fa­mille de pro­duits Re­ne­sas RZ/N1, qui sont ba­sés sur des normes pré­cé­dentes éten­dues, les avan­tages de la tech­no­lo­gie TSN peuvent dé­jà être ré­col­tés au­jourd’hui tant que les dif­fé­rences sont ac­cep­tables dans l’ap­pli­ca­tion en ques­tion.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.