Ejemplo de integración en una planta industrial de varios autómatas de diferentes fabricantes sin problemas en el intercambio de datos
Los SCADAs (del inglés Supervisory Control And Data Acquisition), son herramientas informáticas que satisfacen la necesidad de intercomunicar al operador con los elementos de control automático, para transmitir las órdenes de éste, facilitar de forma clara y simple los estados de los equipos y almacenar los datos relativos a la producción. Cuando los autómatas que forman el automatismo de la planta pertenecen al mismo proveedor, la comunicación entre estos y el sistema de supervisión y mando suele realizarse con las redes y protocolos propios del fabricante.
De todas formas, cada vez es más habitual que en una misma planta se hayan instalado autómatas de diferentes suministradores. En este caso, la utilización de una red específica de uno de los fabricantes no resuelve el problema, ya que la utilización de SCADAs y redes propietarias de cada uno de ellos genera una arquitectura caótica, que producirá como resultado islas incomunicadas entre sí.
Incluso, cuando todos los dispositivos de control se suministren por el mismo fabricante, sería deseable un soporte físico para las comunicaciones, compartido por los equipos industriales y ofimáticos y abierto a terceros.
El ingeniero debe buscar soluciones sencillas, fiables, versátiles y económicas. Aquí exponemos una alternativa a un problema complejo, para que sirva de experiencia a futuras instalaciones con similar problemática.
Descripción del proyecto
En la planta para la destrucción de Materiales Específicos de Riesgo (MER), que la empresa Logar tiene ubicada en Ólvega, Soria, se pretendía controlar un conjunto formado por los siguientes autómatas, que funcionaban de forma independiente:
– 3 autómatas tipo TSX57-Premium de Telemecanique.
– 2 autómatas tipo TSX37-Micro, también de Telemecanique.
– 1 autómata tipo S7-300 de Siemens.
– 1 autómata tipo SLC-505 de Allen Bradley.
Para hacernos una idea de la talla de la aplicación, debemos indicar que entre el SCADA y la red de autómatas se intercambian 5.200 datos, 3.500 elementos de campo y se han configurado 850 alarmas.
Además, la solución adoptada, debía permitir integrar posibles ampliaciones futuras con autómatas de marcas diferentes a las actuales (figura 1).
Requerimientos del sistema de supervisión y mando
Cada uno de los autómatas realiza el comando de un área específica e independiente. Por tanto, no es preceptivo que exista una comunicación entre ellos. El sistema de supervisión debe permitir controlar cada una de las áreas de la planta y, además, ofrecer una visión de conjunto de la misma. Se distinguirá a los diferentes operadores, otorgándoles derechos de acceso y comando que estarán diferenciados.
El operador introducirá los datos de funcionamiento deseados: peso de los diferentes productos y subproductos, temperaturas de consigna, órdenes de arranque y parada, etc. También conocerá la evolución del sistema en todo momento.
Cualquier anomalía o fallo que se produzca en algún componente del sistema, deberá generar una alarma que quede registrada e informe de las medidas a adoptar para solventar el problema.
Este sistema evolucionará desde una primera fase en la que será una herramienta de ayuda en la puesta en marcha, hasta su desarrollo definitivo una vez finalizado el proyecto (figura 2).
Como podemos ver, el grado de versatilidad de mando genera un alto nivel de complejidad:
– Comunicación con autómatas de diferentes fabricantes. En este caso, 4 modelos distintos.
– Elevado tráfico de datos con los PLCs y tiempo de respuesta reducido, menor a 1s para las órdenes de mando.
– Diseño de puestos de trabajo específicos para cada área de la planta.
– Diferenciación en los niveles de acceso de los operadores.
– Sistema evolutivo desde la puesta en marcha hasta la explotación.
Descripción de la solución adoptada
Los requerimientos enumerados exigen un sistema con sus constituyentes interconectados entre sí mediante un soporte físico, lo más estándar posible, y con una velocidad en el tráfico de datos elevada. Ello nos condujo a adoptar como enlace la red fast-ethernet a 100 Mbps. Ethernet es popular porque aporta un buen balance entre velocidad, costo y facilidad de instalación. Todos los PCs disponen de tarjetas económicas para comunicar con esta red. Los autómatas también permiten esta conexión, a través de conexiones incluidas en su CPU o de tarjetas específicas. Los elementos accesorios son de fácil adquisición y reposición en caso de avería.
Ethernet, en nuestro caso concreto, es el soporte común de la conexión de los PLCs y de los equipos informáticos. Con ello abandonamos las soluciones tradicionales de tipo jerarquizado, en las que se utiliza una red específica para enlazar los autómatas y una red de área local, LAN, en el nivel inmediatamente superior, para la informática. Aquí todos los equipos comparten el mismo medio, simplificando enormemente el cableado y garantizando la apertura de la arquitectura. Si volvemos a la figura 1, la representación utilizada no es un recurso gráfico que simplifique el caos de cableado, es el reflejo fiel de la realidad que plan-tea el proyecto.
Para la topología, se adoptó la configuración en estrella, porque es la que mejor se adapta a la ubicación física de los equipos. En el nodo de la red se encuentra el switch que permite la interconexión de todos los elementos existentes, y de las hipotéticas y futuras ampliaciones.
En cuanto al SCADA, la aplicación se desarrolló sobre monitor-pro V7 de Schneider, utilizando como sistema operativo Windows 2000, que nos aportó una comunicación sencilla con los autómatas de Telemecanique –ya que es el mismo proveedor– y a su vez, a través del driver OPC, con el resto de los PLCs.
Este punto merece una aclaración: la comunicación mediante driver OPC, OLE for Process Control, permite obtener los datos de forma transparente entre equipos de diferentes fabricantes. En nuestro caso, al compartir el mismo soporte físico, el problema queda acotado al direccionamiento de los diferentes datos, y a la correcta utilización de los drivers específicos de cada suministrador. Dicho de forma más simple: al SCADA no le importa qué tipo de autómatas se encuentran en la red, sino la dirección del registro que buscamos.
En los PLCs se han asignado áreas específicas de memoria destinadas al intercambio de datos con el SCADA, para agilizar este tráfico de información (figura 3).
Esta solución nos permite comunicar con cualquier autómata que disponga de una conexión ethernet y que facilite su driver OPC, y en nuestro caso, sobre un único soporte físico: la red ethernet.
El monitor-pro de Telemecanique, divide la aplicación en dos módulos con funciones claramente diferenciadas:
– El servidor. Aquí desarrollamos la comunicación con los PLCs, para que los datos sean legibles y su gestión permita que se los utilice como datos históricos, gráficos de tendencia, informes, etc., permitiéndonos generar una base de datos en tiempo real, RTDB del inglés real-time database.
– El cliente nos permite mostrar estos datos y hace posible el diálogo entre el operador y el sistema de control. Aquí se diseñan, entre otras cosas, las diferentes pantallas, presentación de alarmas, evolución de valores internos de las distintas máquinas, transmisión de las órdenes de funcionamiento…
Así tendremos una base de datos común para los diferentes puestos de trabajo, gestionada por la aplicación servidora, y que garantiza la coherencia de funcionamiento desde todos ellos. Dicho de otro modo, desde cualquier puesto de trabajo manejamos los valores de la base de datos común (figura 4).
Desarrollo del proyecto
Una vez definida la arquitectura del sistema y sus diferentes componentes, se inicia la ejecución del proyecto acorde al siguiente calendario:
– Diseño de la aplicación servidora para la comunicación con los autómatas de planta con pruebas de su buen funcionamiento en bancos de ensayo.
– Diseño de aplicaciones cliente. Distintas pruebas de acceso al servidor de datos.
– Instalación de los componentes de la red ethernet en planta.
– Pruebas in situ de los diseños previos y de la red instalada.
– Optimización de la planta con la ayuda del SCADA.
– Definición definitiva del SCADA e implementación del mismo.
Los puntos críticos del sistema
Entendemos por puntos críticos, aquellos cuyo mal funcionamiento provocaría que el resto de los componentes de la red se viesen afectados o imposibilitados para ejecutar su función, y que provocarían que el operador no pudiese conocer el estado de los equipos ni transmitir las órdenes a estos.
Hemos identificado dos puntos críticos dentro de la arquitectura:
– El fallo en el PC Servidor.
– El fallo en el switch. Nodo de la red.
Aquí está el talón de Aquiles del sistema. Si el servidor tiene cualquier deficiencia, el resto de ordenadores –que actúan como clientes– no tendrán acceso a los datos de la red de autómatas. Para minimizar esta eventualidad hemos dotado al servidor de un SAI, que lo aisla de la red y garantiza su buen funcionamiento ante deficiencias de la misma. De cualquier forma, y ante la avería del servidor, esta situación se señalizaría en el resto de los ordenadores de la red y se ha previsto un procedimiento específico, de forma que cualquiera de estos clientes puede realizar la función de servidor de forma temporal.
En cuanto al switch sólo cabe una medida preventiva: disponer de un repuesto del mismo para poder sustituirlo en caso de avería.
Mejoras sobre los requerimientos previos
Aparte de las funcionalidades previstas inicialmente para el SCADA, que no eran precisamente fáciles de abordar, se han incluido otras que aportan mejoras sobre los requerimientos previos. Una de ellas ha sido la generación de gráficas y bases de datos, de forma que sean válidas de cara a la administración y las autoridades sanitarias, a efectos de justificación de la calidad de los procesos ejecutados.
Las bases de datos generadas pueden consultarse directamente desde Excel, o DB-IV, y permiten al usuario beneficiarse de las funcionalidades de estas hojas de datos. Las bases de datos se han diseñado de forma que su tamaño sea compatible con la capacidad de almacenamiento de un disquete.
En los casos que se requería una mayor precisión y un tamaño de datos considerable surge una disyuntiva. Si realizamos la lectura de datos con una frecuencia elevada, cada 10 s por ejemplo, el tamaño del archivo para almacenar un año de funcionamiento desborda la capacidad del disco. Sin embargo, si dilatamos la toma de datos, cada 300 s, por ejemplo, existe la posibilidad de perder valores extremos de funcionamiento. La técnica utilizada ha sido mixta. Recabamos los datos con frecuencia reducida, cada 600 s, pero de cada medida tomamos tres valores: valor medio en el intervalo, valor máximo y valor mínimo. Con ello garantizamos la elaboración de una gráfica fiel a la evolución del proceso acotada por otras dos curvas, de máximo y mínimo. Esta técnica aporta gráficas fiables de tamaño manejable.
Otra mejora aportada por la red de comunicaciones es la interacción entre los diferentes autómatas. Efectivamente, los estados de unos provocan acciones sobre el proceso que antes se ejecutaba de forma manual por el operador. Incluso, y con las aportaciones del cliente, se han ejecutado procedimientos lógicos por parte del SCADA que afectan a los autómatas, cuyas aplicaciones no eran accesibles por motivos de garantía del suministrador, y que aumentan el nivel de automatización en la planta. Con un ejemplo, en el párrafo siguiente, aclararemos este concepto.
En un depósito, del que conocemos el peso de producto, alimenta, mediante sinfín, a un digestor continuo. En un módulo adicional del programa, calcula la cadencia de llenado del digestor, y en función de una consigna introducida por el operador, controla el estado de la tajadera de apertura de alimentación. El operador conoce la cadencia y la con-signa, así como los tiempos de la tajadera cerrada para regular el proceso. Como este SCADA está en funcionamiento de forma continua, minimiza las desventajas de esta solución. Efectivamente, el programa del PLC debe residir, en su integridad, en la memoria de este dispositivo. Pero cuando no se tiene acceso a esta memoria, ciertos módulos de funciones auxiliares que manejen los mismos datos que el PLC, pueden ejecutarse en otro dispositivo –el SCADA en este caso– que transmita los datos obtenidos. El resultado es satisfactorio, y desde el punto de vista del operador, no se observa ninguna disfunción.
También disponemos de un módulo de ayuda al mantenimiento, que permite conocer el número de horas totales y parciales de funcionamiento de los diferentes equipos –con previsión para 200 unidades– y la generación de avisos en tiempos predeterminados por el operador del sistema. Gracias a esta herramienta podemos planificar las diferentes acciones del mantenimiento preventivo (figura 5).
Conclusiones
En el desarrollo del proyecto se observó que la utilización de ethernet, como soporte físico, facilitó enormemente la integración de los diferentes componentes. No sólo los autómatas existentes en la planta, sino el resto de marcas disponen de conexiones a esta red. En el mundo de la ofimática, ethernet se ha consolidado como un estándar, la instalación de los elementos de interconexión se facilita por su simplicidad y el coste es mucho más reducido que el de las redes propietarias.
En cuanto a la respuesta del sistema, ésta es lo suficientemente rápida para poder hablar de control en tiempo real y se han superado las especificaciones iniciales:
– Menos de 40 centésimas de segundo para la transmisión de la orden de marcha o paro de cualquier equipo.
– Menos de 1 s para la visualización de cualquier alarma.
La utilización de la tecnología OPC permite simplificar la comunicación con cada uno de los PLCs, aunque hay que resolver el primer enlace con cada fabricante. Una vez establecido este enlace y direccionados correctamente los registros del autómata, la programación del SCADA no plantea problemas adicionales.
Aun cuando no figurase en las especificaciones previas, esta solución ha permitido que los autómatas de marcas diferentes intercambien datos entre sí. Mediante módulos de programa residentes en el SCADA, el estado de un autómata provoca acciones en aquel PLC que nosotros deseemos.
Que el sistema sea evolutivo genera gran cantidad de modificaciones y trabajo adicional, pero facilita enormemente la labor de la puesta en marcha de la planta. De todas formas, se ha revelado enormemente ventajosa la definición de áreas de memoria específica en los autómatas destinada a la comunicación. Ahora que ya está en funcionamiento, queda demostrando su adaptabilidad a los nuevos requerimientos, que surgen con motivo de la optimización del proceso productivo.
Internet
http://www.automatas.org Información genérica sobre automatización y SCADAs con enlaces a los fabricantes del sector. En español.
http://www.scadanews.com Lugar de divulgación sobre el tema con enlaces a los principales fabricantes mundiales. En inglés.
http://ref.cern.ch/CERN/CNL/2000/003/scada Artículo generalista sobre SCADAs. En inglés. Por Axel Daneels y Wayne Salter.
RESUMEN
La utilización de sistemas informáticos para la supervisión y control de procesos y maquinaria resulta cada vez más habitual. La fuerte implantación de los autómatas programables en el entorno industrial, y la necesidad de obtener datos precisos del proceso productivo han impulsado este crecimiento. Sin embargo, cuando el objetivo es intercambiar datos con autómatas de diferentes fabricantes, la complejidad del sistema aumenta de forma exponencial. El presente artículo trata sobre un proyecto real, ejecutado en la planta de Industrias Logar en Ólvega (Soria), por la empresa Hernar, S.A., y cuenta con la colaboración de Julián Fernández, de la empresa Formatec, que integra autómatas de tres fabricantes: Telemecanique, Siemens y Allen Bradley.
