La primera necesidad que se concibió fue justamente la originada por la razón de ser de Ethernet: llevar información, voluminosa y compleja, del proceso al sistema de monitoreo y adquisición de datos. Haciendo una revisión del modelo de capas de comunicaciones ISO-OSI o más modernamente del modelo TCP/IP, encontramos capas que dependen del hardware, otras que están relacionadas a la placa de comunicaciones y su microprocesador, y los niveles de presentación y aplicación que se relacionan con el software que corre en el terminal (en general, un PC cliente), haciendo esto referencia directa al protocolo en ciernes. Cada una de estas capas permiten que una trama de información pueda recorrer una red Ethernet, pero son estas últimas las que ponen mayores limitaciones a la "apertura de comunicación" de esta red.

Capas del Modelo ISO-OSI.

Un protocolo para cada aplicación

Haciendo una analogía entre sistemas industriales y comerciales, podemos decir que en estos últimos es donde nacieron los protocolos más populares que concibieron las redes Ethernet como las conocemos hoy en día. Un navegador de Internet funciona gracias al protocolo HTTP, como también podemos hacer uso de ficheros comunes o descargar archivos remotos gracias a FTP. Sin embargo, los PLCs y las diferentes redes industriales transmiten en protocolos especializados, propietarios y optimizados para determinados procesos, muy distintos a los de oficinas, con lo que, en principio, el nivel de aplicación debía restringirse al propietario de todo el sistema, es decir, utilizar un mismo software HMI diseñado con los drivers integrados para interpretar la información de un sistema de automatización acotado a la misma marca.

Rápidamente, aquellos fabricantes exclusivos de software HMI adquirieron las licencias de los drivers de los sistemas de automatización más importantes para que su producto también fuese capaz de "desen-criptar" del paquete TCP/IP la información relevante de aplicación. Pero, esto no sólo llevó al encarecimiento de estos software, sino también a una frecuente desactualización de versiones de drivers, al ser provistos por terceros.

La estandarización del protocolo y mecanismo de transmisión de información denominado OPC permitió garantizar la comunicación de cualquier plataforma de software con cualquier protocolo industrial. Obviamente, el precio que se paga es performance del sistema (siempre es mejor cuanto menos intermediarios hay en el pasaje de datos), pero la gran ventaja es que se pueden integrar sistemas antiguos y modernos sobre TCP/IP, incluso a niveles de aplicaciones elementales como planillas de cálculo.

Ejemplo de una red Ethernet.

Integración en los sistemas de automatización

Desde hace unos años, se han desarrollado en los mismos PLCs y componentes de sistemas de automati-zación dispositivos que integran los protocolos de comunicación "de oficina". Esto lo vemos en placas de comunicación sobre Ethernet para PLCs con funcionalidad "IT", lo que implica que la placa integra páginas web, puede enviar mails, permite subir y bajar archivos (planos, manuales u otra información relevante al proceso) e incluso ser diagnosticada con herramientas estándar. Con esto, en vez de disponerse de aplicaciones de software industriales en el PC, el sistema de automatización puede ser accedido con herramientas de oficinas. Por ejemplo, podemos ver lo que pasa en cualquier PLC del mundo por su página web, recibir por e-mail información del proceso o alarmas, actualizar un manual de mantenimiento, etc. A pesar que la tentación de recurrir a estas soluciones es grande, debe tenerse bien en claro que de ninguna manera estas herramientas tienen la prestación, seguridad y potencia de un software industrial, como un SCADA.

Modelo TCP/IP.

Comunicación entre
automatismos

Con la extensión de Ethernet dentro del mismo proceso se hace cada vez más frecuente la necesidad de intercomunicar equipos de un mismo nivel, sean estos PLCs o instrumentos. Esto es totalmente viable hace tiempo, desde las redes en 10MB/s (leáse redes Sinec H1) hasta hoy día sobre TCP/IP. Pero, es muy importante destacar que desde entonces y hasta ahora sólo se ha resuelto la transmisión con los protocolos propietarios de la misma marca, integrados en TCP/IP. Esto, significa que aún no es posible conectar en forma directa dos PLCs de marca diferente sobre Ethernet TCP/IP sin hacer uso de un trasductor, que reste eficiencia.

Por esto, el ingeniero proyectista debe tener claro que no es suficiente con que un dispositivo transmita en TCP/IP para garantizar su comunicación universal; siempre deberá preguntar por el protocolo de aplicación que integra en TCP/IP para saber con qué otros equipos ese podrá "hablar" sin inconvenientes. En este contexto, mecanismos como OPC se están tratando de extender a los PLCs para resolver esta situación, pero la evolución aún es lenta. Nuevos standards, como Profinet, están dando una solución al tema.