Úl­ti­mas ten­den­cias en Con­tro­la­do­res de Au­to­ma­ti­za­ción Pro­gra­ma­bles

PACS

Automática e Instrumentación - - SU­MA­RIO -

Úl­ti­mas ten­den­cias en Con­tro­la­do­res de Au­to­ma­ti­za­ción Pro­gra­ma­bles El con­trol in­dus­trial, con la adop­ción de los Con­tro­la­do­res de Au­to­ma­ti­za­ción Pro­gra­ma­bles co­mo co­ra­zón y ce­re­bro de la má­qui­na, to­mo la de­ci­sión de con­cen­trar to­da la in­te­li­gen­cia en un so­lo equi­po. Se in­ten­ta, co­mo pre­mi­sa de di­se­ño, uni­fi­car la to­ma de de­ci­sio­nes en el PAC y que pue­da ges­tio­nar to­das las tec­no­lo­gías ne­ce­sa­rias pa­ra la má­qui­na.

El con­trol in­dus­trial, con la adop­ción de los Con­tro­la­do­res de Au­to­ma­ti­za­ción Pro­gra­ma­bles co­mo co­ra­zón y ce­re­bro de la má­qui­na, to­mo la de­ci­sión de con­cen­trar to­da la in­te­li­gen­cia en un so­lo equi­po. Se in­ten­ta, co­mo pre­mi­sa de di­se­ño, uni­fi­car la to­ma de de­ci­sio­nes en el PAC y que pue­da ges­tio­nar to­das las tec­no­lo­gías ne­ce­sa­rias pa­ra la má­qui­na. La ges­tión y diag­nós­ti­co de la red Et­her­net, la vi­sión ar­ti­fi­cial o el con­trol de im­pre­sión de eti­que­tas; son ejem­plos de tec­no­lo­gías que se han ido su­man­do a las ca­pa­ci­da­des de los Con­tro­la­do­res de Au­to­ma­ti­za­ción Pro­gra­ma­bles en el es­fuer­zo de sim­pli­fi­car las má­qui­nas. Et­her­net co­mo bus de cam­po. Pro­to­co­lo PRP

El pi­lar que es­tá sus­ten­tan­do la in­cor­po­ra­ción de las má­qui­nas a IIOT es, sin lu­gar a du­das, el uso de la Et­her­net co­mo bus úni­co y ex­clu­si­vo pa­ra to­das las ne­ce­si­da­des de la má­qui­na. Un bus úni­co Et­her­net, que nos per­mi­te el trán­si­to de for­ma in­te­li­gen­te por la mis­ma ins­ta­la­ción de pro­to­co­los muy di­fe­ren­tes y con di­ver­sas ne­ce­si­da­des, es el so­por­te ne­ce­sa­rio pa­ra desa­rro­llar las pres­ta­cio­nes más pun­te­ras del IIOT. Una má­qui­na cu­yo con­trol es­tá ba­sa­do en el pro­to­co­lo Et­her­net/ip, 100% com­pa­ti­ble con los es­tán­da­res Et­her­net IEEE 802.x, per­mi­te sin nin­gún es­fuer­zo aña­dir ser­vi­cios tan dis­pa­res co­mo el con­trol de ser­vo­mo­to­res, la ges­tión de la to­po­lo­gía de un po­si­ble ani­llo de swit­ches o el en­vío del ya tra­di­cio­nal co­rreo elec­tró­ni­co.

Los pri­me­ros ser­vi­cios que se aña­die­ron en los PAC res­pec­to la red Et­her­net fue­ron li­ga­dos a la ne­ce­si­dad de diag­nos­ti­car la red (que puede lle­gar a es­tar for­ma­da por va­rias de­ce­nas de swit­ches).

Un PAC co­no­ce el es­ta­do de la red que usa. De for­ma, que apar­te de diag­nos­ti­car­la puede mo­di­fi­car su to­po­lo­gía. Por ejem­plo anu­lan­do puer­tos en los swi­ches (ya clá­si­co ejem­plo del uso con­jun­to de PACS Lo­gix con swit­ches Stra­tix)

O puede co­no­cer el pun­to de rup­tu­ra de un ani­llo crea­do con pro­to­co­lo DLR de for­ma que tar­da mi­li­se­gun­dos en re-di­rec­cio­nar el trá­fi­co y evi­den­te­men­te avi­sar del lu­gar exac­to de la ro­tu­ra a man­te­ni­mien­to. De­vi­ce Le­vel Ring (DLR): Es un pro­to­co­lo que su­mi­nis­tra los me­ca­nis­mos pa­ra de­tec­tor, ges­tio­nar y re­cu­pe­rar­se de fa­llos en una red ba­sa­da en ani­llo.

Cuan­do se di­se­ña la red Et­her­net de una má­qui­na, se han de te­ner va­rios (por no de­cir mu­chos) pa­rá­me­tros en cuen­ta. Uno de los pa­rá­me­tros que tie­ne mu­cho pe­so, es la re­si­lien­cia de la red. Re­si­lien­cia: Ca­pa­ci­dad de un ma­te­rial, me­ca­nis­mo o sis­te­ma pa­ra re­cu­pe­rar su es­ta­do ini­cial cuan­do ha ce­sa­do la per­tur­ba­ción a la que ha­bía es­ta­do so­me­ti­do.

Di­cho de otra for­ma. Cuan­do apa­rez­ca un agen­te per­tur­ba­dor de mi red (por ejem­plo un ca­ble que se rom­pe de for­ma im­pre­vis­ta) ¿Cuán­to tiem­po pue­do per­ma­ne­cer sin co­mu­ni­ca­cio­nes efec­ti­vas en­tre los ele­men­tos de la má­qui­na?

Es­tá pre­gun­ta siem­pre es un po­co tram­po­sa, ya que to­dos te­ne­mos la idea “lo mí­ni­mo po­si­ble” pe­ro sien­do es­tric­tos el tiem­po de reac­ción ne­ce­sa­rio pa­ra una plan­ta de bombeo es muy di­fe­ren­te al de una má­qui­na

en­va­sa­do­ra o al de una lí­nea de im­pre­sión de papel.

Te­nien­do en cuen­ta que los prin­ci­pa­les pro­to­co­los es­tán­dar que fun­cio­nan en la ca­pa 2 del mo­de­lo OSI que nos per­mi­tan te­ner una al­ta dis­po­ni­bi­li­dad (al­ta re­si­lien­cia) son: Span­ning Tree Pro­to­col, REP Ring, De­vi­ce Le­vel Ring, Pa­ra­llel Re­dun­dancy Pro­to­col, Flex Links y Et­her­chan­nel. ¿Cuál de ellos de­be­mos usar?

Si la res­pues­ta, a la pre­gun­ta, es de va­rios cen­te­na­res de se­gun­dos, pue­do mon­tar una red con swit­ches y pro­to­co­lo STP. Si la res­pues­ta es de de­ce­nas de mi­li­se­gun­dos, mejor que pon­ga swit­ches con al­gún pro­to­co­lo con­cre­to de ges­tión de ani­llos ti­po REP Ring o Flex Links o Et­her­chan­nel. Si ya la res­pues­ta es de 1 o 2 mi­li­se­gun­dos te­ne­mos que mon­tar swit­ches y/o equi­pos con pro­to­co­lo de ani­llo De­vi­ce Le­vel Ring.

¿Pe­ro y si la res­pues­ta es de 0 mi­li­se­gun­dos?

En es­te ca­so, una de las me­jo­res so­lu­cio­nes con­sis­te en ins­ta­lar una red do­ble con el pro­to­co­lo -Pa­ra­llel Re­dun­dancy Pro­to­col- (PRP). Pa­ra­llel Re­dun­dancy Pro­to­col (PRP): Es un pro­to­co­lo stan­dard de red Et­her­net ca­paz de ga­ran­ti­zar una con­mu­ta­ción per­fec­ta en ca­so

de fa­llo de cual­quier com­po­nen­te de la red.

Es­ta in­fra­es­truc­tu­ra de red se ba­sa en crear con swit­ches dos re­des, LAN (A y B) en pa­ra­le­lo, que no tie­nen por qué te­ner la mis­ma es­truc­tu­ra pe­ro si han de es­tar ab­so­lu­ta­men­te ais­la­das en­tre ellas. De es­ta for­ma, un fa­llo en una de ellas no afec­ta al trá­fi­co en la otra red.

Los equi­pos co­nec­ta­dos a es­te ti­po de in­fra­es­truc­tu­ra de co­mu­ni­ca­ción se cla­si­fi­can en tres ca­te­go­rías: DAM, equi­pos con do­ble co­nec­tor Et­her­net que se co­nec­tan di­rec­ta­men­te a las dos re­des sin in­ter­me­dia­rios. SAN equi­pos con co­nec­tor sim­ple úni­ca­men­te co­nec­ta­dos a una de las dos re­des (y por tan­to sin apro­ve­char la do­ble red). Y VDAM, equi­pos con co­nec­tor sim­ple co­nec­ta­do a un –Red­box- que ha­ce de in­ter­me­dia­rio pa­ra po­der ac­ce­der a la dos re­des.

Cual­quier equi­po de con­trol se puede co­nec­tar co­mo VDAM o co­mo SAM, pe­ro evi­den­te­men­te per­de­mos pres­ta­cio­nes en la re­si­lien­cia y en la dis­po­ni­bi­li­dad.

Lo ideal es que el pro­pio equi­po dis­pon­ga de do­ble co­nec­tor con pro­to­co­lo PRP na­ti­vo en su Firm­wa­re, co­mo es el ca­so de los con­tro­la­do­res Con­tro­llo­gix, de las E/S Flex5000 y las ES 1756.

En la si­guien­te ima­gen po­de­mos ver de for­ma es­que­má­ti­ca co­mo tan­to un con­tro­la­dor Con­tro­llo­gix co­mo E/S re­mo­tas de la fa­mi­lia 1756 se co­nec­tan di­rec­ta­men­te a las dos re­des A y B sin in­ter­me­dia­rios gra­cias a la im­ple­men­ta­ción por Firm­wa­re del pro­to­co­lo PRP. En la mis­ma ima­gen tam­bién se ob­ser­va co­mo equi­pos sin es­ta ca­pa­ci­dad se co­nec­tan co­mo es­ta­ción SAN o a tra­vés de un Switch in­dus­trial que se ha con­fi­gu­ra­do co­mo Red­box.

Vea­mos en la si­guien­te ta­bla los di­fe­ren­tes pro­to­co­los exis­ten­tes en los di­fe­ren­tes equi­pos que con­for­man una red Et­her­net In­dus­trial.

Pro­tec­ción avan­za­da de la Pro­pie­dad In­te­lec­tual

La Pro­pie­dad In­te­lec­tual del có­di­go, que se po­ne den­tro de un PAC, ha si­do du­ran­te mu­cho tiem­po una preo­cu­pa­ción me­nor en los fa­bri­can­tes de má­qui­nas. Si bien es cier­to que du­ran­te años se han usa­do mé­to­dos co­mo las con­tra­se­ñas pa­ra su pro­tec­ción, hay que te­ner en cuen­ta que la ges­tión de con­tra­se­ñas re­quie­re de un es­fuer­zo con­si­de­ra­ble en el la­do “hu­mano”. ¿Cuán­tas ve­ces he­mos vis­to las cre­den­cia­les de un de­ter­mi­na­do usua­rio apun­ta­dos en un papel jun­to al fron­tal de un HMI?. Las con­tra­se­ñas son fá­cil­men­te “en­con­tra­das” con téc­ni­cas bá­si­cas de snif­fer en la red, por no men­cio­nar las ma­las pra­xis de en­viar­las a los com­pa­ñe­ros por co­rreo elec­tró­ni­co sin en­crip­tar, apun­tar­las en papel o sim­ple­men­te usar el mis­mo có­di­go en di­fe­ren­tes sis­te­mas de se­gu­ri­dad. Si nos en­fren­ta­mos a pi­ra­tas pro­fe­sio­na­les con su­fi­cien­te pre­pa­ra­ción y re­cur­sos, las con­tra­se­ñas son una pro­tec­ción in­su­fi­cien­te.

Pe­ro ima­gi­ne­mos que usa­mos un sis­te­ma de con­tra­se­ñas ro­bus­to pa­ra pro­te­ger nues­tros có­di­gos más va­lio­sos y que pu­dié­se­mos eli­mi­nar las ma­las pra­xis aso­cia­das al fac­tor hu­mano. ¿Po­de­mos ga­ran­ti­zar la trans­mi­sión se­gu­ra de da­tos en­tre nues­tro PC (sin vi­rus) usa­do pa­ra pro­gra­mar y el PAC?

La ga­ran­tía de trans­mi­sio­nes se­gu­ras en­tre equi­pos puede ser im­ple­men­ta­da me­dian­te la tec­no­lo­gía Ip­sec que se usa co­mún­men­te pa­ra crear Vir­tual Pri­va­te Net­works (VPN). Ip­sec su­mi­nis­tra las si­guien­tes ca­rac­te­rís­ti­cas de se­gu­ri­dad:

Au­ten­ti­fi­ca­ción de los pun­tos fi­na­les (Clien­te y Ser­vi­dor)

Au­ten­ti­fi­ca­ción e in­te­gri­dad de los da­tos (me­dian­te men­sa­jes de com­pro­ba­ción de in­te­gri­dad)

Con­fi­den­cia­li­dad de los da­tos (me­dian­te en­crip­ta­ción)

Por tan­to usan­do con­tra­se­ñas ro­bus­tas más tec­no­lo­gía Ip­sec, ¿Es­ta­mos se­gu­ros de no en­tre­gar nues­tro có­di­go a per­so­nas aje­nas a nues­tra em­pre­sa? La res­pues­ta es: De­pen­de de quien reali­ce el tú­nel.

Lo co­mún­men­te usa­do por mu­chos fa­bri­can­tes de ma­qui­na­ria es ins­ta­lar un dis­po­si­ti­vo ser­vi­dor de tú­ne­les VPN (usual­men­te lla­ma­do Rou­ter VPN) co­lo­ca­do en­tre la red de la má­qui­na y la red pú­bli­ca a la que es­tá co­nec­ta­da la má­qui­na (usual­men­te red del clien­te fi­nal). Por tan­to, aun­que el tú­nel VPN ga­ran­ti­ce au­ten­ti­fi­ca­ción, in­te­gri­dad y con­fi­den­cia­li­dad en­tre nues­tro PC y el dis­po­si­ti­vo que ha­ce el tú­nel, no po­de­mos ase­gu­rar que la red de la má­qui­na ha­ya si­do ata­ca­da y que por con­si­guien­te la in­for­ma­ción que le lle­ga al PAC no ha si­do “vis­ta” por un equi­po co­lo­ca­do en­tre el “Rou­ter VPN” y el PAC. Es la ver­sión in­dus­trial del Man In The Midd­le.

Pe­ro afor­tu­na­da­men­te la so­lu­ción es muy sim­ple, de­be­mos ha­cer que sea el pro­pio PAC el que ha­ga la fun­ción de ser­vi­dor VPN pa­ra im­pe­dir (no de­jar es­pa­cios) pa­ra el ata­que co­no­ci­do co­mo el Man In the Midd­le ni op­cio­nes a los snif­fers.

De es­ta for­ma, al ser el pro­pio PAC el que ge­ne­ra el ser­vi­dor VPN y sien­do nues­tro PC de con­fian­za el clien­te de la VPN po­de­mos ga­ran­ti­zar que la trans­mi­sión es real­men­te se­gu­ra.

Ya he­mos ga­ran­ti­za­do la trans­mi­sión, pe­ro en un en­torno de tra­ba­jo ca­da vez más des­lo­ca­li­za­do don­de di­fe­ren­tes gru­pos de de­sa­rro­llo tra­ba­jan en di­fe­ren­tes se­des y don­de ca­da vez más se tra­ba­ja con sub­con­tra­tas (di­fí­ci­les de su­per­vi­sar, con PC’S fue­ra de nues­tro do­mi­nio, sin ga­ran­tías de an­ti­vi­rus ac­tua­li­za­dos…) ¿Có­mo po­de­mos plan­tear el in­ter­cam­bio de có­di­gos (o par­te de ellos) de for­ma se­gu­ra?

La so­lu­ción fá­cil vie­ne nue­va­men­te de apli­car tec­no­lo­gías de en­crip­ta­do. En es­te ca­so no ha­bla­mos de tú­ne­les se­gu­ros con en­crip­ta­ción pa­ra y úni­ca­men­te la trans­mi­sión, sino de te­ner par­tes del có­di­go del PAC en­crip­ta­do que se pue­den in­ter­cam­biar en­tre los usua­rios sin te­ner ne­ce­si­dad de des-en­crip­tar­los pa­ra su uso.

La res­pon­sa­bi­li­dad de evi­tar fu­gas de có­di­go se cen­tra­li­za en la fi­gu­ra del “Li­bra­rian”, per­so­na que en­crip­ta el có­di­go y que ge­ne­ra los cer­ti­fi­ca­dos de se­gu­ri­dad aso­cia­dos. Es­tos cer­ti­fi­ca­dos ne­ce­si­tan del so­por­te de un chip crip­to­grá­fi­co que sue­le ir in­te­gra­do en una me­mo­ria USB o tar­je­ta SD.

De es­ta for­ma, el có­di­go puede cir­cu­lar por e-mails, de PC en PC o in­clu­so de PAC a PAC con ga­ran­tía que so­lo el Li­bra­rian es ca­paz de ge­ne­rar el cer­ti­fi­ca­do co­rres­pon­dien­te (cer­ti­fi­ca­dos de uso, vi­sión, Edi­ción, Co­pia, Pro­te­ger o ex­por­tar sin en­crip­ta­ción) a la per­so­na con­cre­ta que lo ne­ce­si­te por el tiem­po que el Li­bra­rian con­si­de­re ne­ce­sa­rio.

En es­te es­ce­na­rio, la per­so­na que ha­ce de Li­bra­rian en­crip­ta, los usua­rios au­to­ri­za­dos usan el có­di­go y el PAC des-en­crip­ta y eje­cu­ta el có­di­go ob­te­nién­do­se una pro­tec­ción to­tal!

Lle­ga­dos a es­te pun­to, don­de es el pro­pio PAC que des-en­crip­ta el có­di­go jus­to an­tes de cal­cu­lar­se, ¿Por qué no vin­cu­lar el uso de es­tos có­di­gos a la pre­sen­cia de un cer­ti­fi­ca­do de se­gu­ri­dad con­cre­to?

Es­to es lo que rea­li­zan las nue­vas fa­mi­lias de con­tro­la­do­res de úl­ti­ma ge­ne­ra­ción con los có­di­gos pro­te­gi­dos a eje­cu­ción. Por un la­do, el li­bra­rían en­crip­ta par­tes del có­di­go pa­ra que otros usua­rios pue­dan in­ser­tar­lo en sus pro­gra­mas (Pro­pie­dad In­te­lec­tual ga­ran­ti­za­da por la en­crip­ta­ción). Es­tos có­di­gos son des­car­ga­dos a los PAC y son los pro­pios con­tro­la­do­res los que le­yen­do la tar­je­ta SD con chip crip­to­grá­fi­co y com­pa­ran­do los cer­ti­fi­ca­dos presentes en mis­ma SD, de­ter­mi­na si un có­di­go es eje­cu­ta­ble o no y si ha de eje­cu­tar­lo de una cier­ta for­ma o de otra for­ma.

Es la com­bi­na­ción per­fec­ta pa­ra OEMS o in­te­gra­do­res que quie­ren ase­gu­rar­se al 100% de que su pro­pie­dad in­te­lec­tual (en for­ma de có­di­go de PAC) so­lo se eje­cu­ta en los PAC que ten­gan pre­sen­ten un cer­ti­fi­ca­do de se­gu­ri­dad con­cre­to. En ca­so de que su có­di­go sea usa­do de for­ma no au­to­ri­za­da (sin cer­ti­fi­ca­do de se­gu­ri­dad), el pro­pio có­di­go reac­cio­na con va­ria­cio­nes en su eje­cu­ción que puede lle­var a la má­qui­na a pro­du­cir más des­pa­cio, pa­rar­se o sim­ple­men­te in­for­mar de la per­di­da de los cer­ti­fi­ca­dos. La reac­ción del có­di­go, an­te la pér­di­da del cer­ti­fi­ca­do de se­gu­ri­dad, la de­ci­de el pro­gra­ma­dor an­tes ha­cer la en­crip­ta­ción. Otro va­lor aña­di­do ob­te­ni­do me­dian­te la pro­tec­ción a

eje­cu­ción de los có­di­gos en un sis­te­ma ba­sa­do en cer­ti­fi­ca­dos, es que lo cer­ti­fi­ca­dos se pue­den ob­te­ner (los en­tre­ga el li­bra­rian) por una red no se­gu­ra y ade­más pue­den ser cer­ti­fi­ca­dos tem­po­ra­les que li­mi­tan el uso del có­di­go.

PAC Bró­ker de Alar­mas In­dus­tria­les

Cuan­do desa­rro­lla­mos una apli­ca­ción pa­ra un PAC, que con­tro­la­rá una má­qui­na/pro­ce­so, de­be­mos te­ner en cuen­ta y pla­ni­fi­car muy de­ta­lla­da­men­te el com­por­ta­mien­to del sis­te­ma an­te las alar­mas. Un buen plan­tea­mien­to de las alar­mas y de co­mo el PAC ha de reac­cio­nar an­te ellas, dis­tin­gue mu­chas ve­ces en­tre un buen pro­gra­ma de un mal pro­gra­ma. No hay na­da más frus­tran­te pa­ra un ope­ra­dor, que te­ner una má­qui­na pa­ra­da sin sa­ber qué ac­cio­nes to­mar, por­que la in­ter­fa­ce de usua­rio no in­di­ca co­rrec­ta­men­te la si­tua­ción real.

El plan­tea­mien­to clá­si­co res­pec­to a las alar­mas es el de clien­te/ ser­vi­dor. El ser­vi­dor es el PAC que con­tie­ne las va­ria­bles y que con­tes­ta a las pe­ti­cio­nes de los clien­tes HMI (Hu­man Ma­chi­ne In­ter­fa­ce) so­bre el va­lor de es­tas va­ria­bles. Nor­mal­men­te hay un HMI que es­tá con­sul­tan­do de for­ma con­ti­nua cen­te­na­res o mi­les de va­ria­bles en el PAC, con una fre­cuen­cia pre­de­ter­mi­na­da, pa­ra de­ci­dir ba­jo una ló­gi­ca im­ple­men­ta­da en el HMI cuan­do mos­trar o no una alar­ma (y sus es­ta­dos po­si­bles es­ta­dos co­mo: ac­ti­va, no ac­ti­va, re­co­no­ci­da, no re­co­no­ci­da, si­len­cia­da, etc… ) y mar­car es­tos es­ta­dos con una fe­cha/ ho­ra re­co­gi­da de su re­loj in­terno. Por otro la­do, te­ne­mos el PAC que ha de eva­luar las mis­mas va­ria­bles pa­ra ga­ran­ti­zar la in­te­gri­dad de la má­qui­na/pro­ce­so. Hu­man Ma­chi­ne In­ter­fa­ce (HMI): La in­ter­faz de usua­rio es el me­dio con que el usua­rio puede co­mu­ni­car­se con una má­qui­na, equi­po, compu­tado­ra o dis­po­si­ti­vo, y com­pren­de to­dos los pun­tos de con­tac­to en­tre el usua­rio y el equi­po.

La apro­xi­ma­ción clá­si­ca de clien­te/ser­vi­dor apli­ca­da a las alar­mas tie­ne va­rias des­ven­ta­jas:

Se re­quie­re pro­gra­ma­ción en el PAC y en el soft­wa­re del HMI. Las va­ria­bles se de­ben du­pli­car en el soft­wa­re HMI y ma­pea­das al PAC co­rres­pon­dien­te (lo cual da ori­gen a múl­ti­ples erro­res).

Aña­dir o mo­di­fi­car una alar­ma re­quie­re de re­pro­gra­mar dos sis­te­mas di­fe­ren­tes (PAC y HMI).

Es­ta­dos de alar­ma de muy cor­ta du­ra­ción (al­gu­nos mi­li­se­gun­dos) se han de cap­tu­rar en el PAC.

Las alar­mas son de­tec­ta­das por du­pli­ca­do, pri­me­ro en el PAC y lue­go en el soft­wa­re del HMI.

La con­sul­ta con­ti­nua por par­te del HMI in­cre­men­ta la car­ga de la red.

La de­ter­mi­na­ción del mo­men­to de dis­pa­ro de la alar­ma de­pen­de de la ho­ra del equi­po don­de es­te el HMI eje­cu­tán­do­se y por tan­to aña­de la de­mo­ra de­pen­dien­te de la fre­cuen­cia de las co­mu­ni­ca­cio­nes.

La dis­cri­mi­na­ción de tiem­po en­tre dos alar­mas de­pen­de del ci­clo de con­sul­ta.

Si exis­ten va­rios HMI en di­fe­ren­tes equi­pos, no hay sin­cro­ni­za­ción en la ho­ra de la alar­ma y di­fi­cul­ta sin­cro­ni­zar los re­co­no­ci­mien­tos de las alar­mas ya que re­si­den en di­fe­ren­tes lu­ga­res.

Y por úl­ti­mo, si cae el or­de­na­dor que eje­cu­ta el HMI o hay una dis­con­ti­nui­dad en la co­mu­ni­ca­ción, las alar­mas se pier­den…

Es­te ele­va­do nú­me­ro de des­ven­ta­jas y la cre­cien­te sim­bio­sis con el IIOT ha crea­do la ba­se pa­ra evo­lu­cio­nar el mo­de­lo clá­si­co clien­te/ser­vi­dor al mo­de­lo pu­bli­ca­ción/sus­crip­ción

El mo­de­lo pu­bli­ca­ción/subs­crip­ción, se ba­sa en que la in­for­ma­ción se ha de pu­bli­car cuan­do es re­le­van­te y tie­ne que ser en­via­da a los sus­crip­to­res que es­tán es­pe­ran­do las ac­tua­li­za­cio­nes. Pa­ra coor­di­nar es­tas fun­cio­nes, sue­le ser co­mún el uso de “bró­kers” que son los en­car­ga­dos de man­te­ner los te­mas que los pu­bli­ca­do­res ofre­cen y de con­tro­lar que subs­crip­to­res hay pa­ra ca­da te­ma.

¿Pe­ro có­mo en­ca­ja un mo­de­lo pu­bli­ca­ción/subs­crip­ción en la ges­tión de alar­mas de una má­qui­na/pro­ce­so?

La idea bá­si­ca es que los equi­pos HMI (ya sean pan­ta­llas de­di­ca­das, SCADAS, Ba­ses de Da­tos, etc..) que ne­ce­si­tan co­no­cer las alar­mas se subs­cri­ben a los te­mas (dí­ga­se alar­mas o gru­pos de alar­mas) que los PAC pu­bli­can.

La vi­sión que tie­ne Rock­well Au­to­ma­tion de es­te mo­de­lo se ba­sa en la im­ple­men­ta­ción del pu­bli­ca­dor y del bró­ker en el mis­mo equi­po PAC (CPU Lo­gix). Al te­ner in­te­gra­do en una pie­za in­dus­trial tan­to al pu­bli­ca­dor co­mo al bró­ker, per­mi­te que exis­tan va­rias subs­crip­cio­nes en­la­za­das con el PAC y que tra­ba­jen to­das ellas coor­di­na­das. El re­co­no­ci­mien­to de alar­mas, si­len­cia­do, en­tre otros, es­tá ges­tio­na­do por el PAC (pu­bli­ca­dor y bró­ker) y, por tan­to, se man­tie­ne la con­gruen­cia de los da­tos que mues­tran los di­fe-

ren­tes HMI’S de la ins­ta­la­ción. Otra ven­ta­ja de te­ner el bró­ker in­te­gra­do en PAC es que en ca­so de dis­con­ti­nui­dad en las co­mu­ni­ca­cio­nes (o de par­te de las co­mu­ni­ca­cio­nes), el bró­ker man­tie­ne la in­for­ma­ción a la es­pe­ra de ser en­tre­ga­da a los sus­crip­to­res aun­que ha­yan es­ta­do fue­ra de ser­vi­cio tem­po­ral­men­te.

Po­de­mos po­ner co­mo ejem­plo, una má­qui­na sen­ci­lla con dos pa­ne­les de ope­ra­dor. Las alar­mas que mues­tran son exac­ta­men­te igua­les in­clu­so si un pa­nel se ha des­co­nec­ta­do por te­mas de man­te­ni­mien­to. Por su­pues­to, las alar­mas que han si­do re­co­no­ci­das en un pa­nel, apa­re­cen co­mo ta­les en los dos pa­ne­les ya que el bró­ker dis­tri­bu­ye la in­for­ma­ción a to­dos los subs­crip­to­res in­clu­so si han de­ja­do de co­mu­ni­car tem­po­ral­men­te.

En ins­ta­la­cio­nes más com­ple­jas, ten­dre­mos la ne­ce­si­dad de ha­cer lle­gar es­tas alar­mas a múl­ti­ples soft­wa­res que se pue­den es­tar eje­cu­tan­do en va­rios or­de­na­do­res, dí­ga­se múl­ti­ples clien­tes de un SCADA pa­ra ver y ope­rar las alar­mas, his­to­ria­do­res pa­ra guar­dar las alar­mas en ba­se de da­tos, re­pre­sen­ta­cio­nes gra­fi­cas don­de re­la­cio­nar va­lo­res analó­gi­cos his­tó­ri­cos con las alar­mas, en­tre otros. Co­mo ve­mos, es­te cre­cien­te nú­me­ro de subs­crip­to­res (y por tan­to de me­mo­ria ne­ce­sa­ria en el bró­ker) puede ha­cer que el PAC pier­da ren­di­mien­to en sus otras co­mu­ni­ca­cio­nes Et­her­net.

Pa­ra con­tro­lar es­ta si­tua­ción dón­de un nú­me­ro cre­cien­te de subs­crip­to­res (que pue­den lle­gar a ser de cien­tos de clien­tes del SCADA) quie­ren ac­ce­der a la in­for­ma­ción, se adop­ta el me­ca­nis­mo de aña­dir un bró­ker en for­ma de soft­wa­re que ges­tio­ne to­dos es­tos otros subs­crip­to­res. Es­te se­gun­do bró­ker puede ayu­dar a se­gre­gar re­des en ca­so ne­ce­sa­rio y tam­bién se puede ins­ta­lar de for­ma re­dun­dan­te en dos or­de­na­do­res pa­ra au­men­tar su dis­po­ni­bi­li­dad.

En el ca­so de Rock­well Au­to­ma­tion, es­te se­gun­do bró­ker se lla­ma Fac­tory­talk Alarms&events. Es­te soft­wa­re que ne­ce­si­ta del so­por­te de un or­de­na­dor y que (muy im­por­tan­te) so­por­ta de for­ma na­ti­va una con­fi­gu­ra­ción re­dun­dan­te, ha­ce de bró­ker de los sus­crip­to­res Fac­tory­talk View SE (SCADA dis­tri­bui­do), Fac­tory­talk His­to­rian (His­to­ri­za­dor), Ftlinx Ga­te­way (Ser­vi­dor OPC UA), etc.

Con es­te mo­de­lo de co­mu­ni­ca­ción ob­te­ne­mos los si­guien­tes be­ne­fi­cios:

La de­tec­ción de las alar­mas so­lo se pro­gra­ma una vez en el PAC.

Las con­di­cio­nes de las alar­ma se de­tec­tan más rá­pi­da­men­te.

Alar­mas en tiem­po real se eje­cu­tan en el PAC.

Los tex­tos aso­cia­dos a las alar­mas so­lo se pro­gra­man una vez en el PAC.

Los tex­tos aso­cia­dos a las alar­mas pue­den rea­li­zar­se en los di­fe­ren­tes idio­mas que se re­quie­ran.

Se eli­mi­na la du­pli­ca­ción de va­ria­bles en los di­fe­ren­tes HMI’S (Pa­ne­les o SCADAS)

Se re­du­ce la car­ga de la red al no exis­tir un flu­jo de mi­les de va­ria­bles que su­per­vi­sar.

Los es­ta­dos de las alar­mas se ges­tio­nan en el PAC

La fe­cha/ho­ra se aña­de en el PAC sien­do más pre­ci­sa la dis­cri­mi­na­ción en­tre alar­mas.

La des­co­ne­xión tem­po­ral de un subs­crip­tor no afec­ta a los otros subs­crip­to­res al dis­po­ner el bró­ker de una me­mo­ria-buf­fer in­de­pen­dien­te por ca­da subs­crip­tor.

Por to­das es­tas ra­zo­nes, es­ta me­to­do­lo­gía de fun­cio­na­mien­to se es­tá abrien­do pa­so en­tre los PAC’S de más al­to ni­vel.

CON­CLU­SIO­NES Los PACS son el ce­le­bro de las má­qui­nas más mo­der­nas y no de­jan de me­jo­rar sus pres­ta­cio­nes en as­pec­tos ca­da vez vin­cu­la­dos a la fi­lo­so­fía del IIOT. La ca­pa­ci­dad que tie­nen pa­ra co­nec­tar­se a re­des Et­her­net ya sean par­ti­ci­pan­do en la es­truc­tu­ra de ani­llo o de una ar­qui­tec­tu­ra com­ple­ja PRP, te­ner la ca­pa­ci­dad de tra­ba­jar con có­di­gos en­crip­ta­dos que ga­ran­ti­cen la pro­pie­dad in­te­lec­tual o el po­der tra­ba­jar en mo­de­los de co­mu­ni­ca­ción pu­bli­ca­ción/subs­crip­ción los con­vier­ten en el com­pa­ñe­ro per­fec­to pa­ra im­ple­men­tar el IIOT en las fá­bri­cas.

RE­FE­REN­CIAS CIS­CO –ROCK­WELL AU­TO­MA­TION (Ma­yo 2014). “De­plo­ying the Re­si­lient Et­her­net Pro­to­col (REP) in a Con­ver­ged Plant­wi­de Et­her­net Sys­tem (CPWE) De­sign Gui­de” CIS­CO –ROCK­WELL AU­TO­MA­TION (Fe­bre­ro 2018). “De­plo­ying a Re­si­lient Con­ver­ged Plant­wi­de Et­her­net Ar­chi­tec­tu­re” ROCK­WELL AU­TO­MA­TION (Agos­to 2018). “Et­her­net/ip Pa­ra­llel Re­dun­dancy Pro­to­col” ROCK­WELL AU­TO­MA­TION (No­viem­bre 2015). “Et­her­net/ip Se­cu­re Com­mu­ni­ca­tion” Da­niel Be­ní­tez In­ge­nie­ro Co­mer­cial de Ar­qui­tec­tu­ras In­te­gra­das Rock­well Au­to­ma­tion Ibe­ria

(VTXHPD GH FRQH[LYQ VHJXUD HQWUH XQ 3& \ XQ 5RXWHU SDUD DFDEDU FRPXQLFDQGR PHGLDQWH XQD UHG QR VHJXUD FRQ XQ &RQWURODGRU GH $XWRPDWL]DFLYQ 3URJUDPDEOH

(MHPSOR HVTXHPIWLFR GH UHG (WKHUQHW FRQ SURWRFROR 353 /DV FRPXQLFDFLRQHV HQWUH HTXLSRV '$1 VRQ LQPXQHV D XQ IDOOR GH FXDO TXLHU HOHPHQWR GH OD LQIUDHVWUXFWXUD GH UHG

(Mem­plo real del uso de tar­me­tas (1 76C pa­ra P$C¶S Con­trol/ogi[ de 5ocn­zell $uto­ma­tion pa­ra en­yiar da­tos en­tre dos con­tro­la­do­res y un PC con :in­dozs en ama­ri­llo en el in­te­rior de una in­fra­es­truc­tu­ra de plan­ta (n es­te emem­plo aun­que la ar­qui­tec­tu­ra in­ter­na de la má­qui­na/fa­bri­ca fue­se ata­ca­da y los pi­ra­tas con­si­guie­sen ha­cer una co­pia del trá­fi­co en­tre el PC y el P$C los da­tos es­tar­tan en­crip­ta­dos y no podrtan sa­car pro­ye­cho de ellos

(Mem­plo de tar­me­ta 6' con Crip­to chip pa­ra al­ma­ce­nar los cer­ti­fi­ca­dos de se­gu­ri­dad que usa el P$C du­ran­te la eme­cu­ciyn de cy­di­gos en­crip­ta­dos

Pan­ta­lla de se­lec­ciyn de per­mi­sos a aso­cia­dos a una pro­tec­ciyn en­crip­ta­da de cy­di­go

(sque­ma de co­ne[iyn se­gu­ra en­tre un PC y un Con­tro­la­dor de $uto­ma­ti]aciyn Pro­gra­ma­ble

(MHPSOR FRQ GRV 3DQHOHV GH 2SHUDGRU VXEVFULWRV D GRV OLVWDV GH DODUPDV SXEOLFDGDV HQ GLIHUHQWHV 3$&V

(MHPSOR GH YDULRV VRIWZDUHV LQGXVWULDOHV DFFHGLHQGR DO EUYNHU GH DODUPDV )DFWRU\7DON $ODUPV (YHQWV

Newspapers in Spanish

Newspapers from Spain

© PressReader. All rights reserved.