De In­dus­tria 4.0, ne­ce­si­da­des de co­nec­ti­vi­dad y gue­rras de pro­to­co­los y es­tán­da­res

Automática e Instrumentación - - CONTERNTS - Asier Or­tiz, Chief Ope­ra­ting Of­fi­cer (COO) de Lan­tek.

Cual­quie­ra que ha­ya asis­ti­do a una fe­ria, we­bi­nar o vi­si­ta­do un si­te re­la­cio­na­do con In­dus­tria 4.0 ha­brá po­di­do de­tec­tar que en­tre los con­cep­tos más ha­bi­tua­les y ex­ten­di­dos es­tá el de IOT (In­ter­net of Things), ade­más de es­tar fa­mi­lia­ri­za­do con co­mo otros mu­chos tér­mi­nos y es­tán­da­res a su al­re­de­dor: IIOT, IOE, HTTP, REST, JSON, MQTT, OPC-UA, DDS… la lis­ta po­dría con­ti­nuar.

Cual­quie­ra que ha­ya asis­ti­do a una fe­ria, we­bi­nar o vi­si­ta­do un si­te re­la­cio­na­do con In­dus­tria 4.0 ha­brá po­di­do de­tec­tar que en­tre los con­cep­tos más ha­bi­tua­les y ex­ten­di­dos es­tá el de IOT (In­ter­net of Things), ade­más de es­tar fa­mi­lia­ri­za­do con co­mo otros mu­chos tér­mi­nos y es­tán­da­res a su al­re­de­dor: IIOT, IOE, HTTP, REST, JSON, MQTT, OPC-UA, DDS… la lis­ta po­dría con­ti­nuar.

To­dos sa­be­mos que lo que que­re­mos es ob­te­ner co­nec­ti­vi­dad on­li­ne en­tre nues­tros sis­te­mas de TI y los pro­ce­sos reales que es­tán su­ce­dien­do en las plan­tas. Pe­ro la reali­dad que nos en­con­tra­mos es que no hay un úni­co es­tán­dar de co­mu­ni­ca­cio­nes hoy en día que nos per­mi­ta co­mu­ni­car nues­tras so­lu­cio­nes de TI (ERP/MRP/MES) con cual­quier má­qui­na de cual­quier fa­bri­can­te, y tam­po­co es fá­cil en­ten­der en­tre to­dos es­tos tér­mi­nos cuá­les son im­por­tan­tes en ca­da caso.

Tra­ba­jar pa­ra ayu­dar con es­te mix de tér­mi­nos es par­te de la la­bor de los pro­vee­do­res del sec­tor, por­que sin du­da uno de los gran­des desafíos cuan­do se ne­ce­si­ta co­nec­tar un ERP/MES y sus má­qui­nas, es la co­nec­ti­vi­dad e in­ter­ope­ra­bi­li­dad. Hay mu­chos pro­to­co­los pa­ra lo­grar es­to: al­gu­nos que son pro­pie­ta­rios y otros que son es­tán­da­res abier­tos, y es nues­tro tra­ba­jo en­ten­der dón­de y cuán­do uti­li­zar­los.

Pa­ra el pro­pó­si­to de es­ta dis­cu­sión, es im­por­tan­te agru­par los pro­to­co­los en dos ca­te­go­rías: Clien­te/ser­vi­dor y Pu­blish/subs­cri­be (de pu­bli­ca­ción/ sus­crip­ción)

Los pro­to­co­los clien­te/ser­vi­dor re­quie­ren que el clien­te se co­nec­te al ser­vi­dor y reali­ce so­li­ci­tu­des. En es­te mo­de­lo, el ser­vi­dor con­tie­ne los da­tos y res­pon­de a las so­li­ci­tu­des del clien­te. Por ejem­plo, el clien­te pue­de así leer un da­to de una má­qui­na (véa­se: un tiem­po de cor­te) si co­no­ce el ser­vi­dor. Es­te mo­de­lo es más ade­cua­do cuan­do los equi­pos co­no­cen su in­fra­es­truc­tu­ra a ni­vel de red (di­rec­ción IP y puer­to del ser­vi­dor).

Por su par­te, los pro­to­co­los de pu­bli­ca­ción/sus­crip­ción re­quie­ren que los dis­po­si­ti­vos se sus­cri­ban, y lue­go re­co­jan da­tos a tra­vés de un pro­ce­so o sis­te­ma in­ter­me­dio. Por ejem­plo, un dis­po­si­ti­vo pue­de mues­trear un da­to de una má­qui­na ca­da mi­nu­to, y lue­go pu­bli­car­lo una vez por ho­ra. En es­te mo­de­lo, una apli­ca­ción sus­cri­ta a di­cho flu­jo de da­tos re­ci­be ca­da ho­ra un lis­ta­do de mues­tras de un mi­nu­to. Es­te mo­de­lo des­vin­cu­la en cier­ta for­ma al pro­duc­tor de da­tos del con­su­mi­dor, y es más ade­cua­do cuan­do la in­fra­es­truc­tu­ra de red es más des­co­no­ci­da o va­ria­ble.

Qué pro­to­co­los (OPC-UA, MQTT, DDS…) ten­drán más cuo­ta de mer­ca­do es al­go que to­da­vía no es­tá cla­ro, pe­ro ca­da uno tie­ne sus pros y sus con­tras. Lo im­por­tan­te es ele­gir el pro­to­co­lo que me­jor se adap­te a las ne­ce­si­da­des de ca­da or­ga­ni­za­ción, aun­que to­da­vía es más im­por­tan­te se­lec­cio­nar y con­tar con part­ners tec­no­ló­gi­cos con ex­pe­rien­cia, que pue­dan adap­tar­se a es­tos pro­to­co­los y a las di­fe­ren­tes ca­suís­ti­cas y per­mi­tan abs­traer las apli­ca­cio­nes de las gue­rras de pro­to­co­los y es­tán­da­res.

Newspapers in Spanish

Newspapers from Spain

© PressReader. All rights reserved.