UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica

- i - UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica DESARROLLO BÁSICO DE UN SISTEMA SCADA DISTRIBUIDO BASADO EN MIDDLEWARE Y SOFTWARE DE CÓDIGO ABIERTO Por Luis Enrique Vaamonde Lemke Sartenejas, Febrero de 2007

- ii - UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica DESARROLLO BÁSICO DE UN SISTEMA SCADA DISTRIBUIDO BASADO EN MIDDLEWARE Y SOFTWARE DE CÓDIGO ABIERTO Por Luis Enrique Vaamonde Lemke Realizado con la Asesoría de: Prof. Ernesto Granado (Tutor Académico) Prof. Mario Torre (Tutor Industrial) Informe Final de Cursos en Cooperación Técnica y Desarrollo Social Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero Electrónico Sartenejas, Febrero de 2007

- iii - UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica DESARROLLO BÁSICO DE UN SISTEMA SCADA DISTRIBUIDO BASADO EN MIDDLEWARE Y SOFTWARE DE CÓDIGO ABIERTO Informe Final de Cursos en Cooperación Técnica y Desarrollo Social Presentado por Luis Enrique Vaamonde Lemke REALIZADO CON LA ASESORÍA DE: Prof. Ernesto Granado (Tutor Académico) Prof. Mario Torre (Tutor Industrial) RESUMEN: En este trabajo se continúa con el desarrollo de un sistema básico de supervisión, control y adquisición de datos (SCADA), bajo la plataforma Linux, que se compone de aplicaciones que trabajan de forma distribuida a través de un middleware orientado a mensajes. Implementado con el uso de software de código abierto, el prototipo de estación maestra SCADA usando el protocolo de comunicación industrial Modbus para el intercambio de datos con estaciones remotas en campo, una base de datos para el almacenamiento de la información y una interfaz gráfica de usuario para la supervisión y control del proceso. Se busca que las aplicaciones del prototipo se acerquen al cumplimiento pleno de los requerimientos de escalabilidad, modularidad y procesamiento en tiempo real, necesarios para aplicaciones distribuidas de control industrial. PALABRAS CLAVES: SCADA; Middleware; Linux; Software libre; Tiempo real. Aprobado con Mención: Postulado para el premio: Sartenejas, Febrero de 2007.

- iv - Índice General CAPÍTULO 1: INTRODUCCIÓN... 9 1.1 DESCRIPCIÓN DEL PROYECTO... 10 1.2 OBJETIVOS:... 11 1.3 GUÍA DEL LIBRO... 12 CAPÍTULO 2: FUNDAMENTOS TEÓRICOS... 13 2.1. SISTEMAS SCADA... 13 2.2. SISTEMAS DISTRIBUIDOS... 16 2.3 MIDDLEWARE... 18 2.3.1 Tipos de Middleware:... 19 2.3.2 Middleware orientado a Mensajes (MOM):... 19 2.4. CÓDIGO ABIERTO... 20 2.5. CONSIDERACIONES DE TIEMPO REAL... 21 2.6. PROTOCOLO MODBUS... 21 2.6.1. Descripción General... 22 2.6.1.1. Descripción del Protocolo...22 2.6.1.2. Codificación de los Datos...22 2.6.1.3. Modelo de Datos y Direccionamiento....23 2.6.1.4. Procesamiento en el Servidor...23 2.6.2. Modbus sobre TCP / IP... 24 2.6.3. Categorías de Códigos de Función... 25 2.6.3.1. Códigos de Excepción....25 2.6.3.2. Códigos de Función Públicos más comunes....26 2.7. COMPONENTES ESTUDIADOS PARA EL PROTOTIPO... 32 2.7.1. Sistema Operativo... 33 2.7.2. Lenguajes de Programación... 33 2.7.2.1. Lenguaje C...33 2.7.2.2 Lenguaje C++...33 2.7.2.3. Java...34 2.7.3. Base de Datos... 34 2.7.4. XML... 34 2.7.4.1. Parser XML...35 2.7.4.1.1 Parser Expat...36 2.7.4.1.2 Parser Xerces[12]...36 2.7.4.1.3 Parser Java...36 2.7.5. XmlBlaster.... 37 2.7.5.1 Características principales...37 2.7.6. Simuladores RTU- Modbus... 38 2.7.6.1 ModSim32...38 2.7.6.2 Simulador RTU-Modbus...39 2.7.7 Mecanismo Señal/Casilla... 40 2.7.7.1 Librería Boost:...41 2.7.7.1 Librería Sigslot:...41 2.7.8 Librería FOX-TOOLKIT... 41 CAPÍTULO 3: COMPONENTES USADOS EN EL PROTOTIPO... 43 3.1 LENGUAJE DE PROGRAMACIÓN... 43 3.2 PARSER XML... 43 3.3 SIMULADORES RTU-MODBUS... 44 3.4 MECANISMO SEÑAL/CASILLA... 44 3.5 XMLBLASTER.... 44 3.5.1 Pruebas realizadas... 44 3.5.2. Resultados.... 46 3.5.3 Análisis de resultados... 50 CAPÍTULO 4: PROTOTIPO... 55 4.1. DESCRIPCIÓN DEL PROTOTIPO... 55 4.1.1. Arquitectura del Prototipo... 55

- v - 4.1.2. Funcionamiento General... 56 4.2. MODELO DE DATOS... 58 4.3. TÓPICOS DE MENSAJES XML... 59 4.4. TIPOS DE MENSAJES XML... 61 4.4.1. Mensaje XML de Datos... 62 4.4.2. Mensaje XML de Control... 64 4.4.3. Mensaje XML de Error... 65 4.4.4. Mensaje XML de Alarma... 69 4.4.5. Mensaje XML de Reconocimiento de Alarma... 71 4.4.6. Mensaje XML de Fin de Alarma... 71 4.4.7. Mensaje XML de Actualización... 72 4.4.8. Mensaje XML de Solicitud de Actualización... 72 4.4.9. Mensaje XML de Solicitud de Valores Históricos... 72 4.4.10. Mensaje XML de Valores Históricos... 73 4.4.11 Mensaje XML de Configuración del Driver... 74 4.4.12. Mensaje XML de Configuración del Sistema.... 77 4.5. CAMBIOS REALIZADOS AL PROTOTIPO... 84 4.5.1. Modelo de datos... 84 4.5.2. Interfaz CTU-RTU... 85 4.5.2.1. Funcionamiento general de la Interfaz CTU RTU...87 4.5.2.2. Drivers de comunicación...87 4.5.2.3 Nuevas características:...89 4.5.2.4 Otros cambios:...89 4.5.3 Servidor de Datos... 90 4.5.3.1. Funcionamiento general del Servidor de Datos SCADA...90 4.5.3.2. Base de Datos...91 4.5.4 Sistema Supervisorio... 98 4.5.5 Reestructuración de Mensajes... 98 4.5.5.1 Mensaje de datos:...98 4.5.5.2 Mensaje de error:...98 4.5.5.3. Otros mensajes:...98 CAPÍTULO 5: CONCLUSIONES Y RECOMENDACIONES... 99 REFERENCIAS BIBLIOGRÁFICAS... 101

- vi - Índice de Figuras Figura 2.1 Elementos de un sistema SCADA....16 Figura 2.2 Sistema distribuido conectado mediante un Middleware.18 Figura 2.3 PDU de Modbus 22 Figura 2.4 ADU de Modbus incluyendo en MBAP...25 Figura 3.1: tiempo entre mensajes del publicador..47 Figura 3.2: tiempo entre mensajes del receptor:.47 Figura 3.3: tiempo total del publicador:.48 Figura 3.4: tiempo total del Suscriptor...48 Figura 3.5: tiempo entre primer mensaje publicado y último mensaje recibido 49 Figura 3.6: tiempo neto promedio de un mismo mensaje: 49 Figura 4.1 Ciclo de Interrogación...57 Figura 4.2. Modelo original de la Interfaz CTU-RTU...85 Figura 4.3: modelo propuesto de la Interfaz CTU-RTU 86

- vii - Índice de Tablas Tabla 2.1 Códigos de Excepción de Modbus.25 Tabla 2-2 PDU para petición de lectura de bobinas...26 Tabla 2-3 PDU para respuesta normal de lectura de bobinas.26 Tabla 2-4 PDU para respuesta de excepción de lectura de bobinas...27 Tabla 2-5 PDU para petición de lectura de entradas discretas...27 Tabla 2-6 PDU para respuesta normal de lectura de entradas discretas.28 Tabla 2-7 PDU para respuesta de excepción de lectura de entradas discretas...28 Tabla 2-8 PDU para petición lectura de registros de almacenamiento..28 Tabla 2-9 PDU para respuesta normal de lectura de registros de almacenamiento...29 Tabla 2-10 PDU para respuesta de excepción de lectura de registros de almacenamiento 29 Tabla 2-11 PDU para petición de lectura de registros de entrada..30 Tabla 2-12 PDU para respuesta normal de lectura de registros de entrada 30 Tabla 2-13 PDU para respuesta de excepción de lectura de registros de entrada..30 Tabla 2-14 PDU para petición de escritura de bobina 31 Tabla 2-15 PDU para respuesta normal de escritura de bobina.31 Tabla 2-16 PDU para respuesta de excepción de escritura de bobina 31 Tabla 2-17 PDU para petición de escritura de registro de almacenamiento..32 Tabla 2-18 PDU para respuesta normal de escritura de registro de almacenamiento 32 Tabla 2-19 PDU para respuesta de excepción de escritura de registro de almacenamiento..32 Tabla 4.1 Tipos de puntos..59 Tabla 4.2 Funciones de Modbus usadas por el prototipo...88 Tabla 4.3: puntos discretos.93 Tabla 4.4: puntos registros.94 Tabla 4.5: alarmashistoricos..95

- viii - Tabla 4.6: errores 95 Tabla 4.7: rtus.96 Tabla 4.8: valores históricos...96 Tabla 4.9: configuracionrtu 97 Tabla 4.10: eventosclientes 97 Tabla 4.11: configuracioninterrogacionmodbus 97

- 9 - CAPÍTULO 1: INTRODUCCIÓN El presente trabajo es la continuación de los proyectos iniciados a partir de: la pasantía "DISEÑO CONCEPTUAL DE UN SISTEMA SCADA DISTRIBUIDO BASADO EN MIDDLEWARE Y SOFTWARE DE CÓDIGO ABIERTO" presentada por Ambrosio Plaza en noviembre de 2005 en la Universidad Simón Bolívar, y la tesis DESARROLLO BÁSICO DE UN SISTEMA SCADA DISTRIBUIDO BASADO EN MIDDLEWARE Y SOFTWARE DE CÓDIGO ABIERTO presentada por Luis Luque en Julio de 2006 en la Universidad Simón Bolívar. Originalmente concebido a raíz de la adopción de una política del Estado venezolano orientada a promover e incentivar el desarrollo de software de código abierto, plasmado en la promulgación del decreto presidencial 3390 de fecha 23 de diciembre de 2004. Este decreto obliga a los organismos del sector público a migrar sus sistemas a alternativas de código abierto, en la medida en que sea posible. Lo que se busca con este proyecto, es continuar con el desarrollo de un sistema SCADA completo que posea características de alto procesamiento de datos, que cumpla con los requerimientos de tiempo real, estabilidad, modularidad y escalabilidad. Para ello, es necesario un aporte gradual y constante de la comunidad académica. Los proyectos que originaron el presente trabajo, sirvieron de base, como aproximación teórica y práctica, y como punto de comparación en la búsqueda de soluciones apropiadas para la realización del prototipo. Pese a los aportes obtenidos en los trabajos anteriores, todavía cuentan con ciertas limitaciones: 1. Falta de modularidad en el sistema, crear nuevos módulos resulta complicado debido al lenguaje de programación empleado. 2. Limitaciones para la configuración del prototipo, ya que sólo se puede configurar antes de iniciar las aplicaciones.

- 10-3. No se hace una exhaustiva revisión de los componentes empleados, ni se tienen pruebas de desempeño que sirvan como punto de comparación. 4. Falta de distributabilidad en el prototipo, debido a la cantidad limitada de aplicaciones que se pueden configurar. Pese a estas limitaciones en la implementación del prototipo, las investigaciones teóricas y el diseño conceptual de la arquitectura y el funcionamiento de los sistemas, sin duda alguna, fueron los mayores aportes tomados en cuenta para la realización de este trabajo. 1.1 Descripción del Proyecto El proyecto consiste en la continuación del desarrollo de un prototipo básico de una estación maestra de un sistema SCADA [2]. Entre las características del prototipo se encuentran: 1. Posee una arquitectura distribuida basada en Middleware orientado a mensajes, en donde se hace uso del código XML para el envío de informaciones. 2. Se comunica con las estaciones remotas a través del protocolo Modbus sobre TCP / IP. 3. Es altamente configurable para una gran cantidad de procesos a supervisar y controlar. 4. Permite tanto el monitoreo como el control del proceso, al garantizar una comunicación bidireccional entre las estaciones remotas y el operador de la estación maestra. 5. Provee una interfaz gráfica de usuario completa, que permita el monitoreo y configuración del sistema. 6. Utiliza una base de datos para mantener los valores actuales e históricos de los puntos a medir, las alarmas vigentes, finalizadas y reconocidas, información sobre los eventos de errores, las estadísticas de cada una de las estaciones remotas configuradas, y la información del sistema en

general. - 11-7. Se acerca al cumplimiento de los criterios para el procesamiento de datos en tiempo real al utilizar al máximo la programación multihilos. 8. Se compone de herramientas de software de código abierto, por lo que se desarrolló las herramientas necesarias para completar los requerimientos de software de código abierto. 9. Se utilizó un estilo de programación compatible con la filosofía del software libre, para garantizar la adecuada continuación del proyecto. En este sentido se intentó hacer hincapié en la documentación, la claridad del código, la programación modular y se utilizaron herramientas universales y sencillas para el desarrollo de las aplicaciones: un editor de texto y compiladores de línea de comando, ambas herramientas de código abierto, además de otras herramientas de ayuda para la optimización y revisión del código, también de código abierto. 1.2 Objetivos: El objetivo general del proyecto es: Continuar con el desarrollo de un prototipo básico de una estación maestra para un sistema SCADA [2], revisando la arquitectura propuesta, para garantizar un desarrollo modular y escalable, y que permita una fácil configuración. Los objetivos específicos del presente proyecto son los siguientes: -Hacer una revisión completa del enfoque tomado por los proyectos anteriores. -Buscar soluciones para garantizar al máximo la modularidad del sistema, permitiendo facilitar desarrollos futuros de las aplicaciones. -Garantizar el cumplimiento pleno en cuanto a las exigencias del uso de software de código abierto. -Apegarse al cumplimiento pleno en cuanto a las exigencias del procesamiento en tiempo real.

1.3 Guía del Libro - 12 - Este libro está estructurado de la siguiente forma, en el Capítulo 2: Fundamentos Teóricos, se hace una revisión de las bases teóricas del proyecto, prestándole especial atención, a aquellos conceptos de los cuales se hace uso para el desarrollo del prototipo. En el Capítulo 3: Componentes usados en el prototipo, se presentan los componentes usados para el diseño del prototipo, y el motivo por el cuál fueron escogidos. En el Capítulo 4: Prototipo, se desarrolla a profundidad el funcionamiento del sistema, mencionando los cambios realizados al modelo anterior En el Capítulo 5: Conclusiones y Recomendaciones, se presenta una discusión sobre los objetivos logrados en el desarrollo del proyecto, además de recomendaciones necesarias para su continuación.

- 13 - CAPÍTULO 2: FUNDAMENTOS TEÓRICOS El presente trabajo, está basado en las investigaciones teóricas y desarrollo práctico, realizado por Ambrosio Plaza [1] y Luis Luque [2] en sus proyectos de grado, siguiendo sus recomendaciones y conclusiones como base para la elaboración de un nuevo prototipo que cumpla más adecuadamente los objetivos del proyecto. En este capítulo, se hace un repaso a los fundamentos teóricos, y se desarrollan los nuevos tópicos introducidos en el presente proyecto. 2.1. Sistemas SCADA Un sistema de adquisición y control de datos Supervisorio (por sus siglas en inglés Supervisory Control And Data Acquisition) es un conjunto de aplicaciones que permite el monitoreo y control de los distintos elementos de un proceso, a través de los equipos de campo distribuidos geográficamente [3]. Está compuesto por los siguientes elementos: a) La aplicación central, se caracteriza por las siguientes funciones: -Es la que se comunica con las estaciones remotas, para traducir los datos recibidos en una estructura manejable por el sistema. -Presenta una interfaz de operador que permite que el operador interactúe con el sistema, observando el estado del sistema, y enviando señales de control para establecer los puntos de referencia o set-points. -Mantiene los datos históricos para tener una referencia de las alarmas, errores y punto de funcionamiento del sistema, para permitir la creación de estadísticas, y analizar el desempeño del proceso. b) Las estaciones remotas, también denominados equipos de campo, son los encargados de recopilar la información de las variables físicas del proceso, y transmitirlas a la unidad central.

Existen tres categorías principales de estaciones remotas: - 14 - Unidades Terminales Remotas: llamadas RTU por sus siglas en inglés (Remote Terminal Unit) son las preferidas para sistemas SCADA, ya que su función principal es la de recolectar datos, y aplicarles un formato según las aplicaciones de algún protocolo conocido por la aplicación central, para transmitírselos y que puedan ser recopilados y analizados. Estos equipos suelen estar diseñados para procesos específicos, manteniendo generalmente un esquema de control centralizado, por lo que suelen ser una interfaz entre la estación central y los equipos de instrumentación. Controladores lógicos programables: llamados PLC por sus siglas en inglés (Programmable Logic Controllers). Estos equipos buscan ser lo más estándar posible ya que son altamente programables. Suelen usarse en esquemas de control automático, ya que manejan todos los datos de los instrumentos, y a través de una instrucción de la estación central, realizan los pasos necesarios para generar una acción en el proceso. Computadores industriales: son las alternativas de menor costo, ya que son altamente configurables, presentan una interfaz gráfica, y procesan grandes cantidades de datos, pero presentan la desventaja que no soportan ambientes de trabajo hostiles como los otros dispositivos. c) Redes de Comunicación. Permiten la interconexión entre la estación central y las estaciones remotas. Suelen clasificarse de acuerdo a su topología: Punto a punto: en donde la estación central mantiene un canal de comunicación directa con una estación remota, permitiendo altas velocidades de transmisión, con la desventaja de incrementos de costo en la instalación y mantenimiento de la infraestructura. Punto a multipunto: en donde el medio de transmisión es compartido entre diferentes estaciones remotas, lo que reduce los costos en la infraestructura de comunicación,

pero incrementa los retardos de transmisión. - 15 - Dependiendo de los requisitos en la infraestructura, ya sean velocidades de transmisión o distancia entre los componentes del sistema, estas redes de comunicación pueden utilizar diferentes medios, entre ellos: Líneas compartidas Fibra óptica Radio Microondas Satélites d) Equipos de Instrumentación: Son los equipos que interactúan de forma directa con el proceso, entre ellos se tienen: Sensor: Es la parte de una cadena de medición y control que mide primero la magnitud de una variable de proceso, asumiendo un estado de salida correspondiente que es predeterminado e inteligible. El sensor puede estar separado o ser parte integral de otro elemento funcional del lazo, es equivalente a Detector y Elemento primario. Transmisor: Es un dispositivo que mide una variable de proceso por medio de un sensor y tiene una salida de una señal estándar, cuyo estado varía solamente como una función predeterminada de la variable de proceso. El sensor puede ser o no, parte integral del transmisor. Transductor: es un dispositivo que recibe información en la forma de una o más cantidades físicas, modifica la información y/o su forma, si se requiere, y produce una señal resultante de salida. Dependiendo de la aplicación, puede ser un elemento primario, un transmisor, un relé, un convertidor u otro dispositivo. Actuador: se encargan de regular de alguna forma el proceso. En este grupo

conseguimos las válvulas, los motores, etc. - 16 - e) Protocolos de Comunicación: constituyen los conjuntos de reglas y convenciones entre entes comunicantes. El objetivo es establecer una conexión entre los diferentes equipos de un sistema, identificando el emisor y el receptor, asegurando que todos los mensajes se transfieran correctamente y controlando toda la transferencia de información. Un protocolo define los detalles y especificaciones técnicas del lenguaje de comunicación entre los equipos. En la figura 2.1 se presenta los elementos que conforman el sistema SCADA. Figura 2.1 Elementos de un sistema SCADA 2.2. Sistemas Distribuidos Se define como sistema distribuido aquél en el cual varios procesadores autónomos, procesos de almacenamiento de datos o bases de datos interactúan entre sí para la consecución de un fin común. Los procesos coordinan sus actividades e intercambian información a través de una red de comunicaciones [5]. Estos sistemas presentan las siguientes características:

- 17 - Presentan una arquitectura modular: ya que el sistema puede variar en número, los diferentes equipos empleados para llevar a cabo tareas específicas asignadas. Número arbitrario de procesos de aplicación: debe ser flexible para poder crecer o decrecer el número de procesos según sea necesario. Transparencia: comúnmente se requiere que la arquitectura distribuida sea transparente para el usuario. Comunicación de mensajes a través de una red de comunicaciones: se diseña para tener un funcionamiento cooperativo, en vez de tener un comportamiento a modo maestro / esclavo o petición / respuesta. Sistema de control global: necesario para conformar un único sistema coherente, en donde se establece una política común para el uso del sistema, los servicios que provee, los criterios de seguridad, etc. La ventaja de los sistemas distribuidos respecto a los no distribuidos reside básicamente en: Reduce los costos, debido al uso de equipos más económicos, como por ejemplo: usar varios microprocesadores especializados de bajo costo en vez de computadores para el procesamiento de todos los datos. Es modular, en donde cada componente tiene su propia interfaz con el resto del sistema, lo que permite diseños más simples. Es flexible, lo que permite modificar de una manera más cómoda la cantidad de componentes necesarios para supervisar y controlar el proceso. Mejora la disponibilidad e integridad debido a una mejora en la tolerancia a fallas usando componentes autónomos que permitan una redundancia en el sistema. Mejora el desempeño empleando el procesamiento en paralelo, el cual es más eficiente. Una de las formas empleadas para facilitar la comunicación entre los diferentes módulos, es

mediante el uso de un Middleware. - 18 - La figura 2.2 muestra diversas aplicaciones conectadas a través de un Middleware como servidor central. Figura 2.2 Sistema distribuido conectado mediante un Middleware 2.3 Middleware. El Middleware se define como una capa de software intermedio que gestiona la comunicación entre diferentes aplicaciones. Sus principales funciones son: Proveer de una interfaz estandarizada, para permitir a los desarrolladores la reusabilidad del código y la fácil integración en la aplicación de las ventajas del Middleware para su interconexión con el resto de módulos del sistema. Ocultar detalles de programación de bajo nivel, así como la heterogeneidad de las aplicaciones y los otros componentes del sistema. Permitir la escalabilidad de las aplicaciones, de manera que se puedan agregar, eliminar y modificar los componentes sin que esto se traduzca en la modificación de

todos los otros componentes para que admitan la nueva configuración. - 19 - La principal desventaja de los Middleware, está en el incremento en el retardo de las comunicaciones, debido a que están diseñados para cumplir con un amplio rango de usos, y no se encuentran optimizados para una aplicación específica. 2.3.1 Tipos de Middleware: Según el sistema empleado se pueden agrupar en tres diferentes grupos: a) Orientado a Mensajes: denominados MoM por sus siglas en inglés (Message Oriented Middleware) se encargan de transportar una gran variedad de tipos diferentes de mensajes, entre una aplicación fuente y una o más de destino. b) Orientado a Objetos: funcionan a un mayor nivel, sin presentar una forma tan sencilla de usar como los otros estilos, permiten un acoplamiento más directo entre las aplicaciones, pero resultan menos versátiles en el momento de desarrollar nuevos módulos. c) Orientado a llamadas de Procedimiento Remoto: están diseñados para funcionar a modo de petición / respuesta, en el que una aplicación le pide a otra aplicación por datos, y espera hasta que le sean enviados. La gran ventaja de este sistema, es que presenta una alta sincronización. 2.3.2 Middleware orientado a Mensajes (MOM): Presenta dos modos principales de funcionamiento: a) Punto a punto (PtP): en donde una aplicación puede enviarle el mensaje de información a otra aplicación en específico. b) Publicador / Suscriptor: en donde los mensajes son enviados, no a un cliente específico, sino a todos aquellos clientes que estén interesados en un tipo de mensajes. Para

- 20 - esto, se publica el mensaje con un tópico previamente definido por el sistema, y los clientes que requieran ese tipo de mensajes, se suscriben al tópico, y estos mensajes les son entregados. Una gran ventaja de este sistema, es que la aplicación que publica los mensajes, no tiene que conocer previamente a los clientes interesados en los mensajes, sino que sólo debe enviarle el mensaje a una aplicación central, y ésta es la que se encarga de repartir los mensajes a todos los clientes que los requieran. 2.4. Código Abierto También llamado software libre, consiste en una corriente de pensamiento muy arraigada en grandes comunidades de programadores a nivel mundial que se centra en promover la distribución, comercial o no, de aplicaciones informáticas incluyendo su código fuente y permitiendo la modificación y re-distribución del mismo [6]. Dentro de esta modalidad de software se pueden diferenciar varias modalidades, representadas por las distintas licencias que adoptan los productos desarrollados bajo esta filosofía. Los criterios divergen en permitir o no la distribución comercial de los productos derivados del original, impedir que estos productos dejen de ser software libre o permitir que pasen a formar parte de aplicaciones propietarias. Entre estas licencias se tienen: a) Licencia LGPL (Lesser General Public License): es una licencia que protege menos las libertades del desarrollador, y a ello debe su nombre. Es desarrollada con el fin de permitir el uso de las aplicaciones que ampara tanto en proyectos de software libre como en los que son de software propietario. La intención de esta licencia, es que las aplicaciones que cubre, se puedan convertir en estándares, para poder ser utilizados en cualquier plataforma (incluida el GNU/Linux). b) Licencia GPL (General Public License): esta licencia garantiza completamente que el

- 21 - software que ampara sea totalmente libre para su uso y distribución. Sin embargo, hace la acotación de que al hablar de libertad del software no se refiere a que sea gratuito, sino a que el software se distribuya con su código fuente de manera que se tenga la libertad de modificar el programa para, por ejemplo, añadir nuevas funciones necesarias para la aplicación en que se va a utilizar. 2.5. Consideraciones de Tiempo Real Para un sistema de automatización y control de un proceso industrial, se requiere, no sólo procesar una gran cantidad de datos, sino también procesarlos de una manera rápida, para permitir que las instrucciones de control lleguen de manera rápida y oportuna. Se considera como criterio tomar como valor aceptable de respuesta, que esta sea menor al 10% de la constante de tiempo (τ) del sistema. Es decir, desde el momento en que se transmite un paquete de datos con la información del proceso, hasta la llegada de la respuesta con las instrucciones de control, debe haber transcurrido un tiempo menor al 10% de τ. Una forma apropiada para mejorar el funcionamiento de un sistema de automatización y control, es diseñar su arquitectura basado en procesamiento multitarea. El concepto de tiempo real no es absoluto y varía de acuerdo a la naturaleza de los sistemas que implementen esta característica. En el área de control de procesos, las consideraciones para garantizar un funcionamiento a tiempo real dependen por completo del proceso a controlar. De acuerdo a los requerimientos de velocidad de respuesta de cada proceso, se debe garantizar que el sistema presente retrasos aceptables, un comportamiento predecible y que la cantidad de datos procesados por intervalo de tiempo sea el requerido [2]. 2.6. Protocolo Modbus Modbus es un protocolo de comunicación industrial abierto desarrollado por la empresa

- 22 - Modicon en 1979. Es considerado un estándar de facto en la industria por su amplia difusión desde hace varias décadas. Modbus es un protocolo de mensajes ubicado en la capa siete del modelo OSI, que provee una comunicación Servidor / Cliente sobre una gran variedad de protocolos inferiores. Este protocolo, funciona en el modo de petición / respuesta, ofreciendo sus servicios mediante códigos de función especificados por este estándar. En un sistema SCADA, se define como Servidor Modbus, a la Unidad Terminal Remota, y como cliente, a la estación central del sistema. 2.6.1. Descripción General Esta sección describe el protocolo Modbus, las reglas para la transmisión y recepción de paquetes y algunas de las funciones que soporta. 2.6.1.1. Descripción del Protocolo El protocolo Modbus, define una unidad de datos principal, que se mantiene constante para los diferentes medios en que sea transmitido. Esta unidad principal se denomina Unidad de Datos de Protocolo (PDU por sus siglas en inglés: Protocol Data Unit) [8]. La figura 2.3 representa el PDU del protocolo Modbus. Figura 2.3 PDU de Modbus 2.6.1.2. Codificación de los Datos El protocolo Modbus, se rige por el modelo big-endian, por lo que el byte más significativo es el primero en enviarse.

2.6.1.3. Modelo de Datos y Direccionamiento. - 23 - Independientemente como se haya diseñado un servidor Modbus, se exige que todos sus datos sean direccionados de una forma específica, para cumplir la normativa del protocolo. Dependiendo del tipo de datos, se usa el siguiente modelo: Puntos discretos de sólo lectura: sus posibles valores son sólo cero o uno, llamados Entradas Discretas. Puntos discretos de lectura y escritura: sus posibles valores son sólo cero o uno, llamados Bobinas. Registros de sólo lectura: tienen un tamaño de 16 bits, llamados: Registros de Entrada. Registros de lectura y escritura: con 16 bits de tamaño, se llaman Registros de Almacenamiento. Para cada uno de estos tipos de datos, se pueden tener hasta 65536 elementos individuales, numerados comenzando desde cero. 2.6.1.4. Procesamiento en el Servidor Cuando un cliente envía una petición a un servidor, pueden generarse los siguientes eventos: 1. Si el servidor recibe una petición sin ningún error de comunicación y puede manejarla de forma normal, retorna una respuesta normal con el código de función de la petición y los datos solicitados según la función de la petición. 2. Si el servidor no recibe una petición debido a errores de comunicación éste no envía ninguna respuesta y eventualmente se vencerá un temporizador en el lado del cliente, generando una excepción en la aplicación. 3. Si el servidor recibe una petición con errores de comunicación (chequeo de paridad, CRC, etc.) no genera ninguna respuesta y eventualmente se vencerá un temporizador en el lado del cliente, generando una excepción en la aplicación.