Início / Noticias / Blog Automatas / Comentarios sobre OPC

Comentarios sobre OPC

Hace ya algún tiempo que la industria de los PLC y la Automatización industrial nos ofrece productos que utilizan OPC para la comunicación, pero ¿qué le falta a OPC?

Comentarios sobre OPC

En sistemas distribuidos, OPC esto ha supuesto una gran mejora con respecto a antiguos protocolos de comunicación. Comparémoslo con el antiguo Modbus. Modbus es un protocolo antiguo y muy utilizado pero tiene una estructura de maestro esclavo. Esto es: Se pregunta continuamente al aparato ¿ qué tienes? ¿ qué tienes? y el aparato te va respondiendo. Esto no es viable para redes que sean más grandes y que se salgan del ámbito de lo local.

OPC tiene un sistema de servidor-cliente. El servidor funciona en el automatismo y envía los cambios, los valores que deseemos controlar, a cualquier cliente que quiera oírlos. Esto es mucho más eficiente. OPC nació en el mundo Windows pero ya se ha liberado de él. Ahora es un estándar mucho más abierto y la última versión (OPC UA ) tiene gran cantidad de mejoras en el campo de la comunicación a través de internet. De hecho es uno de los protocolos más avanzados en ese apartado.

¿Qué le falta a OPC?  

Quiero comparar OPC con MMS, un protocolo muy extendido en la industria, muy completo y en el que seguramente OPC inspiro gran cantidad de sus cualidades. En lo básico ambos son similares:
- Son protocolos cliente-servidor
- Ofrecen servicios de Históricos, y alarmas ( más o menos parecidos)
- Almacenan la estructura de la información en el ‘ espacio de nombres’ ( XML)

Dicho esto quiero recordar que todo esto sirve de poco sin una representación de los datos para el usuario. Se necesita un SCADA, por ejemplo. Pero un SCADA debe ser programado. Un profesional muy cualificado debe definir como se representan los datos y configurar un software a medida. El SCADA debe representar la estructura de información que nos presenta precisamente el ‘espacio de nombres ‘. En esta estructura, normalmente XML, se muestra como se definen los datos, que forma tienen o que magnitudes se usan. Se define asimismo, y es muy importante, qué relación tienen entre ellos.

OPC y MMS son muy genéricos en cuanto a las reglas que debe tener una estructura. El fabricante de un PLC que utilice OPC definirá su estructura de datos casi como le venga en gana, con tal que sea coherente. El problema es que nadie más podrá leerla. De ahí que los programas cliente de OPC genéricos, los hechos para que funcione con cualquier fabricante, sean terriblemente incomodos de usar (por no decir inviables). El cliente no sabe interpretar que es lo que le dice el servidor, excepto si es de la misma marca o está preparado para él.

MMS ha evolucionado para solucionar este problema, se ha especializado. Por ejemplo en el mundo de la distribución eléctrica se ha creado un protocolo, IEC61850, sobre el MMS. Esto que decir que usando las reglas de MMS se ha definido como se debe escribir el XML del ‘espacio de nombres’. El protocolo IEC61850 nos dice como se deben escribir las características que tiene un aparato y que hace. Por ejemplo: un aparato de protección de sobreintensidad tendrá un xml en el que aparece el texto

Un cliente de IEC61850 mostrando la estructura de un aparato

Esto es tremendamente potente. Un ingeniero que quiera mostrar los datos de una red eléctrica podrá leer el conjunto de todos los XML y sabrá como representárselos al operador. De cualquier marca. No tendrá que dibujar el SCADA. Bueno, eso es en la teoría, en la vida real las redes son tan complejas que es difícil que esto funcione. Pero es un avance. La implantación de IEC61850 es lenta porque las empresas ya tienen sus propios sistemas de control implantados y hay pocas ganas de meterse en protocolos tan complejos como IEC61850.

¿Qué ocurre con OPC?

En muchos casos los sistemas a automatizar no son demasiado complejos: unos instrumentos de medida o algunos PLC. En este ambiente, una iniciativa como la del IEC61850 sería muy útil y los clientes OPC genéricos podrían mostrar datos mucho más cómodos. 

Hay intentos como FDI en este sentido. FDI es un intento de aunar dos corrientes para mejorar la presentación de los datos de instrumentos en sistemas Windows : mediante ficheros EDD y programas FDT que muestran ( incluso con imágenes ) como son los aparatos que queremos utilizar.



Un programa con tecnologia FDT

La pega es que, en mi opinión FDT es un lastre. Me explico… FDI se incrustara en el servidor a modo de plugin de forma que el servidor OPC entregue esos datos a un cliente FDI (ver el link de FDI). Sin embargo, no veo referencia a que los incluya en el espacio de nombres definido en XML (al contrario que con IEC61850). Esto está fuera del protocolo y si se coloca varios servidores OPC en cadena (como se permite en el protocolo) la información se pierde.

Otra corriente es la que lleva PLCOpen . Aquí se intenta crear un lenguaje común para cualquier PLC sea cual sea el fabricante. Hábilmente la gente de PLCOpen quiere utilizar OPC para comunicar a los PLC que quiere programar. La idea es muy buena e incluyen el programa dentro de la propia estructura OPC del aparato. Esto permitiría a un cliente OPC conocer cómo funciona el PLC: que variables expone y como se está usando.

Puede que sea un poco pronto pero quizás puedan verse clientes OPC que sin necesidad de SCADA nos permitan controlar remotamente los PLC. De cualquier marca.

Autor: Javier Bilbao    

www.kerbero.net

/noticias/marcas/223-blog-automatas

Blog Automatas

Blog dedicado a comentar experiencias, tendencias, tecnologías y mercados relacionados  
con la Automatización Industrial