En este artículo se proporciona una panorámica sobre las distintas posibilidades que puede utilizar un cliente final para operar/supervisar una instalación de automatización industrial. La premisa de partida es conjugar en la misma instalación distintos fabricantes de equipos industriales. Aquellos integradores que han sufrido años atrás la problemática de hacerse entender entre distintos sistemas tendrán su propia experiencia particular acerca de un escenario concreto.

Es nuestro propósito abordar la supervisión (SCADA) en entornos multi-vendedor, siendo conocedores de la falta de soporte que existe a la hora de poder abordar un sistema heterogéneo, dado que sólo un integrador o técnico especializado en el tema podría acometer dada su dilatada experiencia. En este sentido se desea visualizar la automatización industrial como un proceso incremental, con diferentes hitos temporales, por lo que la escalabilidad e interoperabilidad de los sistemas debe ser una pieza fundamental a la hora de diseñar nuevas plantas o sistemas automatizados.
Como escenario general de trabajo, se desea partir de un sistema de automatización industrial que ha ido creciendo poco a poco, solventando los problemas de intercomunicación que van apareciendo. Así se tienen islas de comunicación, con una interoperabilidad zonificada. Este aislamiento es más apreciable cuanto más alto se encuentra el diseñador en la pirámide de comunicaciones CIM (García et al., 2007). Sirva como ejemplo el caso de una máquina-herramienta que ha sido pensada para funcionar autónomamente con materiales y equipos de un fabricante, y se ha ampliado su funcionalidad con equipamiento de otro fabricante. La solución para comunicar datos a ese nivel se facilita por medio de pasarelas de información, que normalmente son terceras compañías quienes las facilitan para poder interactuar con equipos de las marcas más representativas.

 

Hoy en día se hace necesario implementar la supervisión remota (teleservicio) de sistemas de automatización industrial para múltiples aplicaciones: desde minería, tratamiento de aguas, oleoductos y gasoductos, estaciones de bombeo y sistemas de control de tráfico hasta generación y distribución descentralizadas de energía en los sectores eólico, fotovoltaico y de calefacción de distrito, pasando por paneles de publicidad “inteligentes”, estaciones meteorológicas, faros, expendedores de billetes o cajeros automáticos.

El artículo queda estructurado de la siguiente manera. En primer término se realiza un rápido repaso a las redes de comunicación industrial como base que sustenta el sistema de supervisión. Posteriormente se proporciona al lector una taxonomía muy definida en torno a las capacidades que ofrecen los paquetes de software dedicados a la supervisión y adquisición de datos de proceso. La parte central del artículo describe los distintos elementos y sistemas que se pueden utilizar para realizar la tarea de comunicación de datos a un sistema dessupervisión y control de la instalación. Se revisan distintos paquetes SCADA con configuraciones y opciones de uso en entorno multi-vendedor, para concluir en el protocolo OPC específicamente dedicado a la interoperabilidad de los sistemas. Finalmente se extraen conclusiones de los distintos aspectos analizados.

Redes de comunicación industrial
Las redes de comunicación industrial abordan la problemática de la transferencia de información entre los distintos equipos de un sistema automatizado (Mackay et al., 2004). En la Figura 1 se muestra la pirámide de comunicaciones industriales, atendiendo a su ubicación/número de elementos y funcionalidad (datos o control). Cabe indicar que en la parte inferior, existirán numerosos elementos de automatización industrial capaces de enviar pequeñas cantidades de información. Según se sube en la pirámide, el número de elementos se reduce, pero se amplía el número de datos que se deben comunicar.

El tiempo de respuesta exigible al subsistema de comunicación de cada uno de los niveles de la pirámide CIM, puede variar desde unos pocos microsegundos para el nivel de proceso o campo, hasta segundos para el nivel de planta, posicionando de forma diferente el tipo de red de comunicaciones necesaria para implementar dicha comunicación.
Las redes de control están ligadas a los niveles bajos de la pirámide CIM dado que deben ser capaces de soportar, en “tiempo real”, un tráfico de información formado por un gran número de pequeños paquetes procedentes de un número de estaciones inferior al de las redes de datos. La separación entre ambas redes no es tan clara como a priori pudiera parecer, ya que se tiende a dotar a las redes de datos de características propias de las redes de control, tal como es el caso de ProfiNet (Pigan et al., 2008).
En las redes de datos se ejecutan, entre otras, las siguientes aplicaciones informáticas:

    Programas dedicados a la planificación y logística de todos los recursos de la empresa (ERP-Enterprise Resource Planning).
    Programas dedicados a la gestión de los sistemas de ejecución de la fabricación, que se suelen conocer como MES. (Manufacturing Execution Systems).
    Programas de diseño, simulación, ingeniería y fabricación asistidos por computador, denominados CAD/
/CAM/CAE. (Computer Arded Desing/Manufacturing/Engineerin).
    Herramientas de aplicación general que permiten el trabajo en conjunto de todas las áreas de la empresa.

 

Las Redes de Célula satisfacen determinados requisitos que son propios o característicos del ambiente industrial, entre los que se puede destacar:

    Funcionamiento en ambientes hostiles (presencia de fuertes perturbaciones electromagnéticas, temperaturas extremas, polvo y suciedad, etc.).
    Gran seguridad en el intercambio de datos en un intervalo de tiempo cuyo límite superior se fija con exactitud, teniendo un comportamiento determinista.
    Elevada fiabilidad y disponibilidad de las redes de comunicación, mediante la utilización de dispositivos electrónicos y/o medios físicos redundantes y protocolos de comunicación que dispongan de mecanismos avanzados para la detección y corrección de errores en la comunicación, etc.

 

 

 

 

Actualmente, el establecimiento de comunicaciones industriales en el nivel de célula se realiza mediante redes denominadas Industrial Ethernet, cuya capa de enlace está basada en la técnica de acceso al medio normalizada denominada Ethernet y los protocolos básicos de comunicación (TCP/IP), utilizados por las redes ofimáticas.
Se simplifica así al máximo, la implantación de sistemas electrónicos de intercomunicación entre las redes de datos de los niveles superiores y las redes de control de los niveles inferiores de la pirámide CIM. La tendencia futura es que bajo una única norma se satisfagan las necesidades de ambos tipos de redes.  Las redes Industrial Ethernet tratan fundamentalmente de rediseñar el hardware y el software asociado a las capas inferiores propuestas por la norma Ethernet, con el objetivo principal de adecuarlo para ser utilizado en el entorno de una planta industrial.
En lo que respecta al protocolo de la capa de aplicación del modelo OSI (Gordon et al., 2004) que se deben utilizar en combinación con los protocolos de las capas inferiores del mismo, no existe actualmente una solución única. Existiendo gran variedad de opciones como Modbus/TCP, EtherCat, Profinet, etc.

Sistemas SCADA

SCADA es el acrónimo de “Supervisory Control and Data Acquisition”. Un sistema SCADA permite que un usuario pueda desde una sala de control, recoger datos de uno o varios dispositivos remotos y/o enviar instrucciones de control a dichos dispositivos. En un sistema de supervisión tiene vital importancia el sistema HMI (Human Machine Interface), encargado de facilitar la comunicación hombre-máquina.

Clasificación de sistemas SCADA
Se puede realizar una clasificación de los sistemas SCADA, similar a la que se ha comentado para las redes de control y datos anteriormente, en función de si únicamente visualizan el proceso industrial o por el contrario pueden modificarlo:
Sistemas que afectan al proceso: Son aquellos que permiten al operador intervenir y controlar el proceso, además de monitorizarlo.
Sistemas que no afectan al proceso: Son aquellos que sólo se encargan de obtener datos sobre un proceso, no pudiendo modificar el transcurso de éste.

 

 

 

 

Otra posible taxonomía puede realizarse atendiendo a la ubicación del sistema de supervisión, diferenciando entre una supervisión local o remota, y un sistema HMI de pantalla o basado en PC industrial con mayores capacidades.
Sistemas SCADA analizados
Existen numerosos sistemas de supervisión y control, dado que cada fabricante importante de equipos de automatización proporciona un SCADA propietario, y adicionalmente, terceras empresas proporcionan software SCADA con diferentes funcionalidades, enfocados a sectores concretos, atendiendo a ciertas normativas, etc.

En el presente trabajo se han probado diferentes SCADAs representativos dado que son utilizados por las principales marcas de autómatas industriales:

    WinCC (Siemens)
    CX-Supervisor (Omron)
    Vijeo Citect (Schneider Electric)
    Visu+ (Phoenix Contact)
    KepWare Server - SCADA con drivers OPC multifabricante

A continuación se proporciona una visión global sobre las características de dichos sistemas SCADA, remitiendo al lector a los manuales que proporcionan los fabricantes si se desea profundizar en las características técnicas de dichos sistemas.
Características generalistas de los sistemas SCADA
Aunque diferentes en manejo y con pequeñas funciones específicas, los sistemas SCADA constan de funcionalidades comunes a todos ellos. Así, todos hacen uso del sistema operativo Windows, por temas de licencia, propiedad del código y posibilidad de instalación en gran número de los sistemas existentes. En la siguiente lista se muestran las características generales comunes a los sistemas SCADA:

    Gráficos de tendencias, gestión de alarmas, etc.
    Generación de informes.
    Scripts para realizar funciones y rutinas muy utilizadas.
    Inclusión de controles Activex, COM/DCOM, OLE, etc.
    Unificación de supervisión en pantallas/ordenadores.
    Integración entre software de programación PLC y la aplicación SCADA.
    Biblioteca de símbolos y gráficos para la realización de pantallas.
    Soporte ADO/ODBC para leer o registrar datos en bases de datos.
    Comunicación con otras aplicaciones vía OPC.

 

En lo que respecta a un entorno heterogéneo cabe destacar las siguientes cuestiones que de forma específica se deben revisar:

    Inclusión de drivers de comunicación para otros fabricantes de autómatas.
    Supervisión desde un ordenador local (monopuesto) o en varios ordenadores remotos (multipuesto).
    Visualización y control a través de un navegador web. Publicación web de las pantallas de monitorización y control.
OPC: El protocolo estándar para intercambio de datos

El estándar OPC (OLE for Process Control) es un estándar de comunicación en el campo del control y supervisión de procesos. Este estándar permite que diferentes fuentes de datos envíen datos a un mismo servidor OPC, al que a su vez podrán conectarse diferentes programas compatibles con dicho estándar. De este modo, se elimina la necesidad de que todos los programas cuenten con drivers para dialogar con múltiples fuentes de datos, basta que tengan un driver OPC.

    OPC es un conjunto de protocolos entre los que cabe destacar los siguientes:
    OPC-DA (Data Access).- El original, sirve para el intercambio de datos a tiempo real entre servidores y clientes.
    OPC-AE (Alarms & Events).- Propor-ciona alarmas y notificaciones de eventos.
    OPC B (Batch).- Útil en procesos discontinuos.
    OPC DX (Data eXchange).- Proporcio-na interoperabilidad entre varios servidores.
    OPC HDA (Historical Data Access).- Acceso histórico a datos OPC.
    OPC S (Security).- Especifica cómo controlar el acceso de los clientes a los servidores.
    OPC XML-DA (XML Data Access).- Sirve para el intercambio de datos entre servidores y clientes como OPC-DA pero en vez de utilizar tecnología COM/DCOM utiliza mensajes SOAP (sobre HTTP) con documentos en XML.
    OPC CD (Complex Data).- Permite a los servidores exponer y describir tipos de datos más complicados en forma de estructuras binarias y documentos XML.

 

 

 

 

 

El diseño de las interfaces OPC soporta arquitecturas distribuidas en red. Un servidor OPC se compone de varios objetos que se ajustan a la norma COM:

    El objeto servidor: contiene información sobre la configuración del servidor OPC y sirve de contenedor para los objetos tipo grupo. (figura 2).
    El objeto grupo: sirve para organizar los datos que leen y escriben los clientes (ej.: valores en una pantalla MMI o en un informe de producción). Se pueden establecer conexiones por excepción entre los clientes y los elementos de un grupo. Un grupo puede ser público, es decir, compartido por varios clientes OPC.
    El objeto item: representa conexiones a fuentes de datos en el servidor (no son las fuentes de datos en sí). Tiene asociados los atributos Value, Quality y Time Stamp.

Los accesos a los ítems OPC se hacen a través de los grupos OPC y los clientes pueden definir el ritmo al cual el servidor les informa sobre cambios en los datos.

OPC multimarca: KepWare Server
Como referente en el campo de servidores OPC se va a utilizar el paquete software KepWare Server. Este paquete proporciona conectividad industrial OPC, pudiendo configurar rápidamente la comunicación entre los sistemas de control a través de un diverso rango de controladores o “plug-in” y sus componentes.
El paquete dispone de más de 100 controladores que soportan cientos de tipos de modelos, tomando datos para sus sistemas cliente fácilmente. En la mayoría de los casos los servidores OPC han sido desarrollados como simples programas que sólo pueden manejar un único tipo de dispositivo o protocolo cada vez. El resultado de esto es que son necesarios múltiples servidores OPC para manejar distintos tipos de dispositivos o protocolos. KEPServer ha sido implementado en dos componentes diferenciados. El componente servidor aloja toda la interfaz con el usuario y la tecnología OPC. Los drivers de dispositivo específicos se instalarán sobre este componente servidor. KEPServerEX permite, de este modo, utilizar múltiples drivers de comunicación de modo concurrente.
Para adquirir datos desde un PLC o dispositivo, se debe configurar en el servidor KepWare un canal y un dispositivo, siendo una aplicación cliente la que demande estos datos. Casi todos los parámetros pueden ser modificados mientras el servidor está funcionando. También se pueden incluir nuevos Tags al servidor sin necesidad de cerrar las aplicaciones cliente. Cuando se añade un nuevo Tag al servidor estará inmediatamente disponible para cualquier cliente OPC.

Todas las operaciones de Lectura y Escritura pueden ser visualizadas en la ventana de diagnósticos, o bien pueden ser monitorizadas desde la aplicación OPC cliente empleando los Tags de diagnóstico que existen para tal efecto. Todo ello permite una mejor depuración de los errores de comunicación. La ventana de diagnóstico también puede proporcionar una visión en tiempo real de qué es lo que está haciendo el protocolo.
A continuación, se mostrarán diversos ejemplos de comunicación entre diversos PLC’s y diversos sistemas SCADA. Los PLC’s que se han empleado para las pruebas de comunicación han sido el OMRON CJ1M y el SIEMENS S7-300.  En cuanto a los sistemas SCADA se han elegido el Cx-Supervisor de OMRON, el WinCC de SIEMENS y el Vijeo Citect de SCHNEIDER. También se ha decidido incluir en este estudio un servidor OPC, en concreto el KEPServerEX de la firma KEPWARE. La forma en que se ha organizado este estudio ha sido por SCADAs, de manera inicialmente se describe la configuración de los 2 PLCs a conectar usando diferentes canales de comunicación, unificado todo ello en un único paquete SCADA.

Configuración de las comunicaciones en PLC Siemens S7-300
En cuanto a la conexión entre un posible SCADA y el autómata, se hará uso de tres posibilidades que nos permite el hardware disponible en el PLC (ver figura 3).
Estas posibilidades son vía serie (protocolo MPI), vía Ethernet  (protocolo TCP/IP) y vía PROFIBUS. Para configurar y programar el PLC se hace uso del software SIMATIC STEP 7. En primer término se debe realizar la creación del proyecto (ver figura 4).
Cada red (MPI/Profibus/Ethernet) debe tener un nombre único en el proyecto de automatización. El PLC debe tener una dirección válida dentro del rango de definición del protocolo concreto. Para ello se debe abrir la aplicación de configuración de hardware y hacer doble clic en cada uno de los elementos que se desea conectar a cada red. En la  Figura 5 se muestra la configuración básica de cada una de las redes de comunicación de las que dispone el PLC S7-300.
Mediante el software NetPro se tiene una perspectiva global de la conectividad programada (figura 6).

Configuración de las conexiones en el PLC Omron CJ1M
Para la conexión entre SCADA y autómata CJ1M (figura 7), se analizarán las dos posibilidades que nos permite la configuración hardware del PLC que se dispone. Estas posibilidades son comunicación vía serie (protocolo Toolbus/Sysmac) y vía Ethernet (protocolo FINS/TCP).
Comunicación vía serie: protocolos Toolbus y SysmacWay.
El protocolo serie Toolbus es el más utilizado por las herramientas de Omron, debido a su sencillez de configuración, siendo la conexión por defecto con el PLC Omron. En la Figura 8 se muestra la pantalla de configuración típica en programas de la suite CX-One de Omron.
La configuración Toolbus/Sysmac Way es muy similar, debiendo el instalador modificar un switch hardware para que el autómata se comunique vía serie haciendo uso de uno u otro protocolo. El protocolo SysmacWay es un protocolo más abierto, disponible fuera de las herramientas propietarias Omron. Para la conexión vía serie mediante el protocolo Sysmac Way, el microinterruptor etiquetado como 5 de la CPU del PLC CJ1M debe estar en la posición OFF.

Comunicación Ethernet
Se hace uso de una tarjeta de comunicaciones Ethernet disponible en el rack del PLC CJ1M. Para poder configurar correctamente el módulo hardware de comunicaciones Ethernet ETN21 es necesario conectarse al autómata de forma directa (vía serie) inicialmente.  Las herramientas y drivers nativos de Omron hacen uso del protocolo propietario de comunicación de datos denominado FINS. En el caso de que se establezca el enlace a través de una red Ethernet, este enlace sería una comunicación FINS sobre TCP.
El diseñador debe configurar la tabla de E/S y la unidad ETN21, proporcionando una dirección de red FINS a la que pertenece dicho nodo y una dirección IP para realizar comunicaciones por Ethernet. En la Figura 9 se muestra el acceso a la configuración y asignación de una dirección IP al módulo de comunicaciones ETN21, desde CX-Programmer.

Autor: Alfredo GARDEL, Ignacio BRAVO, José Luis LÁZARO - Dpto. Electrónica – Universidad de Alcalá - Edificio Politécnico. Campus Universitario. Alcala de Henares. 28871. (MADRID)