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

UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudio Profesionales Coordinación de Ingeniería Electrónica DISEÑO CONCEPTUAL DE UN SISTEMA SCADA DISTRIBUIDO BASADO EN MIDDLEWARE Y SOFTWARE DE CÓDIGO ABIERTO. Por Ambrosio José Plaza Schwarck Sartenejas, Noviembre de 2005.

ii UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudio Profesionales Coordinación de Ingeniería Electrónica DISEÑO CONCEPTUAL DE UN SISTEMA SCADA DISTRIBUIDO BASADO EN MIDDLEWARE Y SOFTWARE DE CÓDIGO ABIERTO. Por Ambrosio José Plaza Schwarck REALIZADO CON LA ASESORÍA DE: Prof. Ernesto Granado (Tutor Industrial) Prof. Mario Torre (Tutor Académico) PROYECTO DE GRADO Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero Electrónico Sartenejas, Noviembre de 2005.

iii UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica DISEÑO CONCEPTUAL DE UN SISTEMA SCADA DISTRIBUIDO BASADO EN MIDDLEWARE Y SOFTWARE DE CÓDIGO ABIERTO. PROYECTO DE GRADO presentado por Ambrosio José Plaza Schwarck. REALIZADO CON LA ASESORÍA DE: Prof. Ernesto Granado (Tutor Industrial) Prof. Mario Torre (Tutor Académico) RESUMEN: En este trabajo se presenta el diseño conceptual de un sistema de supervisión, control y adquisición de datos (SCADA) utilizando software de código abierto. Se utiliza el sistema operativo Linux como plataforma de desarrollo. Así mismo, se emplea el sistema middleware como plataforma bajo la cual se comunican las aplicaciones que conforman el sistema SCADA, en especial se ha seleccionado xmlblaster debido a que soporta aplicaciones escritas en distintos lenguajes de programación, y se puede ejecutar en plataformas con diferentes sistemas operativos. PALABRAS CLAVES: SCADA; Middleware; Linux; Software libre; Tiempo real. Aprobado con Mención: Postulado para el premio: Sartenejas, Noviembre de 2005.

iv Agradecimientos A Dios, por su infinita ayuda. A mi familia, por apoyarme día a día en el viaje de la vida. A mis tutores de pasantía, Ernesto Granado y Mario Torre, por todas las enseñanzas y consejos brindados durante el desarrollo de esta pasantía. A Mario Torre, por haber confiado en mí para dar vida a su idea. A Ernesto Granado en especial, por toda la atención prestada durante el desarrollo del proyecto, y en particular por su valiosa ayuda durante los últimos días. A Gaby, por su cariño y apoyo incondicional que me impulsan a mantener el esfuerzo en cada momento. A Julio Navas, por la ayuda prestada en varias ocasiones. A mis amigos, por los momentos de distracción. A todos, gracias!

v Índice General CAPÍTULO 1: INTRODUCCIÓN 11 1.1 Descripción del proyecto 12 1.2 Objetivos 13 1.3 Guía del libro 13 CAPÍTULO 2: MARCO TEÓRICO 15 2.1 Sistemas SCADA 15 2.1.1 Concepto 15 2.1.2 Componentes de un sistema SCADA 16 2.1.2.1 Equipos de instrumentación 17 2.1.2.2 Equipos de campo 18 2.1.2.3 Redes de comunicación 19 2.1.2.4 Estación central 20 2.2 Middleware: 21 2.2.1 Concepto 21 2.2.2 Funciones del middleware 22 2.2.3 Tipos de middleware 23 2.2.4 Middleware orientado a mensajes (MOM). 23 2.3 Sistema Operativo Linux 26 2.3.1 Qué es Linux? 26 2.3.2 Ventajas y desventajas 26 2.3.3 El núcleo 2.6 28 2.4 Licencias para aplicaciones de código abierto 28 2.4.1 Licencia LGPL (Lesser General Public License) 29 2.4.2 Licencia GPL (General Public License) 29 2.5 Sistemas distribuidos 30 2.6 Java 30 2.7 XML 32 2.7.1 Concepto 32 2.7.2 Ventajas y desventajas 33 2.7.3 Componentes principales del lenguaje 34 CAPÍTULO 3: MIDDLEWARE 36 3.1 Selección 36 3.1.1 Opciones disponibles en la web 36 3.1.2 Producto seleccionado 39 3.2 xmlblaster 39 3.2.1 Estructura de los mensajes 40

vi 3.2.2 Herramientas de administración y monitoreo. 41 3.2.3 Configuración 41 3.2.4 Servidor de llamada de retorno 42 3.2.5 Complementos 44 3.2.5.1 Complementos de protocolo 44 3.2.5.2 Mecanismos de seguridad 44 3.2.5.3 Complemento de cola del servidor de llamada de retorno 45 CAPÍTULO 4: OTROS COMPONENTES UTILIZADOS 46 4.1 Lenguaje de programación 46 4.2 Herramienta de desarrollo 48 4.3 Base de datos 49 4.4 phpmyadmin 50 4.5 Apache Tomcat. 51 CAPÍTULO 5: PROTOTIPO 53 5.1 Funcionamiento general 53 5.2 Puntos a manejar 55 5.3 Aplicaciones del prototipo 55 5.3.1 Publicador 56 5.3.2 Manejador 60 5.3.3 Interfaz 63 5.3.4 Interfaz web de monitoreo 65 5.4 Base de datos 66 5.4.1 Tabla Status 67 5.4.2 Tabla Analógico 70 5.4.3 Tablas históricas 73 5.5 Pruebas realizadas 73 5.5.1 Prueba local 73 5.5.2 Prueba distribuida 77 CAPÍTULO 6: CONCLUSIONES Y RECOMENDACIONES. 78

vii Índice de figuras Figura 2.1. Pirámide de automatización 16 Figura 2.2. Componentes de un sistema scada 17 Figura 2.3. Esquemas de middleware 24 Figura 2.4. Estructura del mensaje xml 34 Figura 3.1. Estructura del mensaje xml 40 Figura 4.1. Cuadro comparativo de características según el lenguaje de programación. [7] 47 Figura 4.2. Entorno integrado de desarrollo eclipse. 49 Figura 4.3. Toma de phpmyadmin 51 Figura 5.1. Esquema general del prototipo. 54 Figura 5.2. Pantalla de registro 56 Figura 5.3. Interfaz gráfica del simulador de planta para el sistema scada. 57 Figura 5.4. Estructura del mensaje xml enviado por "publicador". 58 Figura 5.5. Diagrama de flujo de publicador. 59 Figura 5.6. Diagrama de flujo de manejador. 60 Figura 5.7. Estructura del mensaje xml de alarma. 61 Figura 5.8. Procedimiento a seguir al recibir un mensaje en manejador. 62 Figura 5.9. Diagrama de flujo de interfaz. 64 Figura 5.10. Procedimiento a seguir al recibir un mensaje en interfaz web de monitoreo. 65 Figura 5.11. Toma de la aplicación interfaz web de monitoreo. 66 Figura 5.12. Tabla de la base de datos para puntos tipo status 68 Figura 5.13. Tabla de la base de datos para puntos tipo analógico 71 Figura 5.14. Latencia entre publicador y manejador con protocolo socket. 74 Figura 5.15. Latencia entre manejador e interfaz con protocolo socket. 75 Figura 5.16. Latencia entre publicador y manejador con protocolo corba 75 Figura 5.17. Latencia entre manejador e interfaz con protocolo corba. 76

viii Índice de tablas TABLA 3.1 COMPARACIÓN DE LAS APLICACIONES MIDDLEWARE. 37 TABLA 3.2 CUADRO COMPARATIVO ENTRE JORAM Y XMLBLASTER. 38 Índice de anexos ANEXO 1: ESTRUCTURA DEL MENSAJE XML 82 ANEXO 2: CÓDIGO FUENTE DE LOS PROGRAMAS 85

ix Símbolos y abreviaturas API - (Application Programming Interface) Interfaz de Programación de Aplicaciones. CIM (Computer Integrated Manufacturing) Manufactura Integrada por Computadora. CPL (Common Public License) Licencia para software de código abierto desarrollada por IBM. DHTML (Dynamic Hyper Text Markup Language) Lenguaje de marcación de hipertexto dinámico. FSF Free Software Foundation. GNU (Gnu's Not Unix) Proyecto de software libre. GPL (General Public License) Licencia para software de código abierto desarrollada por el proyecto GNU. HTML: (Hyper Text Markup Language) Lenguaje de marcación de hipertexto. IHM Interfaz Humano Máquina. JDBC (Java Database Connectivity) Estándar de conexión de base de datos para Java. JMX (Java Management Extensions) Estándar encargado de definir todo aquello referente a la administración de aplicaciones basadas en Java. JVM (Java Virtual Machine) Máquina Virtual de Java.

x LGPL (Lesser/Library General Public License) Licencia para software de código abierto desarrollada por el proyecto GNU. Mbps Mega bits por segundo. MOM (Message Oriented Middleware) Middleware Orientado a Mensajes NTP (Network Time Protocol) Protocolo de tiempo de red. OSI (Open Source Initiative) Corporación sin fines de lucro dedicada a la promoción del software de código abierto. PLC (Programmable Logic Controller) Controlador Lógico Programable. RPC (Remote Procedure Call) Llamada de procedimiento remoto. SCADA (Supervisory Control and Data Acquisition) Sistema de Adquisición de Datos y Control Supervisorio. SQL (Structured Query Language) Lenguaje de Consulta Estructurado TCP/IP (Transmission Control Protocol/Internet Protocol) Protocolo de Control de Transmisión / Protocolo de Internet. UTC Unidad Terminal Central. UTR Unidad Terminal Remota. W3C (World Wide Web Consortium) Consorcio dedicado a desarrollar estándares para la Web. XML (extensible Markup Language) Lenguaje de marcado extensible.

11 CAPÍTULO 1: INTRODUCCIÓN En la industria venezolana se han utilizado los sistemas SCADA desde hace ya varios años, sobre todo en las grandes empresas estatales. Sin embargo, todos los productos de software utilizados en estas áreas son de carácter privativo, es decir, su licencia no permite tener acceso al código fuente con el que se desarrolló la aplicación. A raíz del decreto presidencial 3390, de fecha 23 de diciembre de 2004, las compañías estatales están en la obligación de migrar sus sistemas a aquellos que sean de código abierto. Esto ha creado una necesidad en la industria nacional de productos con estas características. Los productos de código abierto permiten ver el código fuente del programa, e incluso modificarlo para adaptarlo al funcionamiento particular de la empresa. Además, estos productos suelen estar acompañados de estándares abiertos de manera de lograr un mayor acople de distintas aplicaciones. Para poder comunicar a estas entre sí, es necesario buscar un mecanismo que permita el intercambio de información de manera desacoplada y eficiente. Y esto lo proporciona el middleware, que funciona como una capa de comunicación entre aplicaciones que pueden encontrarse distribuidas en varias computadoras separadas geográficamente. Este proyecto constituye una propuesta como un primer aporte al desarrollo de este tipo de aplicaciones en el país, elaborando el diseño conceptual de un sistema SCADA de código abierto basado en middleware. Este trabajo es realizado en la Universidad Simón Bolívar, a través del Departamento de Procesos y Sistemas, como una idea desarrollada por el profesor Mario Torre y bajo la supervisión del profesor Ernesto Granado.

12 1.1 Descripción del proyecto El proyecto busca presentar una primera aproximación a la problemática actual en la industria venezolana sobre la necesidad del desarrollo de un sistema SCADA con software de código abierto. El estudio se centraliza en uno de los componentes principales de la estación central de un sistema SCADA. En esta sección, denominada servicios SCADA, se manejan los elementos de adquisición de los datos provenientes de los equipos de campo, el procesamiento de los mismos, el mantenimiento de la base de datos que maneja los datos más recientes, y de la generación de las alarmas en caso de que los datos recibidos indiquen un comportamiento anormal en algún punto del sistema. El proyecto presenta varias etapas. En primer lugar, se establece una propuesta de plataforma de middleware para utilizar. Este punto es muy importante, ya que esta aplicación será la columna vertebral del sistema. En segundo lugar, se busca señalar las posibles alternativas para todas las otras aplicaciones necesarias del sistema, como el manejador de la base de datos, las aplicaciones para servicios Web, y los programas de desarrollo. Todos estos, a su vez, deben ser de licencia de código abierto para mantener la premisa del proyecto. Por último, se desarrolla un prototipo conceptual básico para demostrar el funcionamiento de los componentes seleccionados, el cual puede aprovecharse como punto de inicio para el desarrollo de un sistema completo para aplicaciones SCADA.

13 1.2 Objetivos Los objetivos del proyecto son: 1. Elaborar un diseño conceptual básico de un sistema SCADA 2. Seleccionar y evaluar los componentes de software necesarios para el desarrollo de este sistema. 3. Desarrollar un prototipo conceptual básico para la demostración de los componentes seleccionados. 4. Hacer las recomendaciones pertinentes para apoyar la continuidad del proyecto. 1.3 Guía del libro El capítulo 2, Marco Teórico, explica los conceptos necesarios para este proyecto. Se desarrolla la teoría básica respecto a los sistemas SCADAs, indicando sus componentes y haciendo una breve explicación de los mismos. El capítulo 3, Middleware, relata el proceso de selección para el componente principal del proyecto: el middleware. Este será la columna vertebral del sistema SCADA al ser el encargado de la comunicación de todas las aplicaciones. Se exponen las opciones encontradas, los criterios de selección utilizados, y por último se tratan los aspectos generales más importantes del producto escogido. El capítulo 4, Otros componentes utilizados, comenta el proceso de selección de los otros componentes necesarios para el desarrollo del sistema SCADA, con base en la selección de middleware realizada. Estos otros componentes son: el lenguaje de programación, la herramienta de desarrollo, la base de datos, la herramienta para el manejo de la base de datos, y los programas para soporte de las aplicaciones Web.

14 El capítulo 5, Prototipo, describe el prototipo realizado para la demostración de los componentes seleccionados. Indica el funcionamiento general de la plataforma, las aplicaciones desarrolladas, las bases de datos creadas, y las pruebas realizadas al conjunto. En el capítulo 6, Conclusiones y recomendaciones, se incluye una discusión sobre los objetivos logrados, y se dejan las puertas abiertas para una nueva investigación de este tema, con una base más clara precisamente aportada por este proyecto.

15 CAPÍTULO 2: MARCO TEÓRICO 2.1 Sistemas SCADA En esta sección se define lo que es un sistema SCADA, sus características, y se realiza una breve explicación de los componentes de este tipo de sistemas. 2.1.1 Concepto Los sistemas de control supervisorio y adquisición de datos SCADA (por sus siglas en inglés Supervisory Control And Data Acquisition) son aplicaciones dedicadas a la etapa de adquisición de datos a través de los equipos de campo distribuidos geográficamente; y del monitoreo del estado de los distintos elementos del proceso a través de un centro de control principal. También permite realizar control supervisorio de los elementos de campo a través del operador en la estación central. La idea original de los sistemas SCADA es que el lazo de control sea cerrado por el operador, pero se ha podido observar como en los últimos años los sistemas presentan a su vez elementos de control automáticos. Como se puede apreciar en la Figura 2.1, estos sistemas de supervisión y adquisición de datos se ubican en el nivel 2 de la pirámide de automatización o pirámide de manufactura integrada por computadora CIM (por sus siglas en inglés Computer Integrated Manufacturing). Esta pirámide posee cuatro niveles que definen la estructura jerarquizada del proceso. Desde el nivel más alto se toman decisiones empresariales de alto nivel, que van bajando hasta llegar finalmente en el último nivel a los elementos directamente relacionados con el proceso. De la misma manera, para hacer la comprobación del correcto funcionamiento de estas políticas empresariales, se van recolectando datos desde los niveles inferiores hasta traducirse en resultados de negocios en la cúspide de la pirámide.

16 Figura 2.1 Pirámide de automatización 2.1.2 Componentes de un sistema SCADA y son: Los elementos que componen un sistema SCADA se muestran en la Figura 2.2, Equipos de instrumentación. Equipos de campo. Redes de comunicación. Estación central.

17 Figura 2.2 Componentes de un sistema SCADA 2.1.2.1 Equipos de instrumentación Se componen por elementos que se encuentran en contacto directo con el proceso, y que buscan interactuar con él de alguna manera según sea su función. Entre estos tenemos: Indicadores: se limitan a registrar la medición de alguna variable del proceso. Transmisores: además de registrar la medición de una variable, la envían a otro equipo para que pueda tomar decisiones con base en el resultado Actuadores: se encargan de regular de alguna forma el proceso. En este grupo conseguimos las válvulas, los motores, etc.

18 2.1.2.2 Equipos de campo En esta categoría se consiguen tres opciones: las Unidades Terminales Remotas (UTR), los controladores lógicos programables (PLCs, por sus siglas en inglés Programmable Logic Controllers) y los computadores industriales. La escogencia del equipo depende de la filosofía de control a utilizar. UTR: son los equipos por preferencia para los sistemas SCADA. Se encargan de recolectar los datos del lugar, aplicarles un formato acorde al protocolo utilizado, y enviarlo a la estación central para ser procesado. Estos suelen estar diseñados específicamente para un proceso particular, en el sentido de que cada uno presenta características especiales para cada tipo de proceso. Entre estas características se encuentra el rango de temperatura de trabajo, condiciones de funcionamiento frente a ambientes hostiles, y atributos de control especiales para ciertos elementos de instrumentación. Suelen trabajar con lenguajes de programación propietarios, así como protocolos propietarios de comunicación. Las UTRs se prestan más a esquemas de control del tipo centralizado, en el cual un operador desde la Unidad Terminal Central (UTC) controla todos los pasos necesarios para realizar una acción en el proceso. La UTR funciona como una interfaz entre la UTC y los equipos de instrumentación. PLC: al contrario que las UTRs, los PLCs buscan ser lo más estándares posibles, ya que son equipos altamente programables. Esto hace que tiendan a ser equipos de mayor precio, ya que soportan comunicaciones de alta velocidad y protocolos tanto estándares como propietarios. Los PLCs suelen ser utilizados en esquemas de control automático donde la unidad maneja los datos de los instrumentos, y a través de una instrucción desde la UTC se encarga de realizar todos los pasos para realizar una acción en el proceso.

19 Computadores industriales: estos equipos surgen como una alternativa económica para los equipos de campo al masificarse el uso de computadores digitales en el mundo. Presentan ciertas características que los hacen más aptos para el procesamiento de grandes cantidades de datos, y altamente configurables al poseer una excelente interfaz con el usuario. Sin embargo este equipo no posee la misma robustez y protección ante ambientes hostiles que los otros equipos de campo. 2.1.2.3 Redes de comunicación En esta categoría se especifican los parámetros de topología y los medios utilizados para la comunicación entre los equipos de campo y la estación central. Las distintas posibles topologías en las configuraciones SCADA podrían resumirse en dos grupos: Punto a punto: la comunicación se establece directamente entre la estación central y un equipo de campo. Presentan un mejor rendimiento al permitir altas velocidades de transmisión, pero derivan en un alto costo de instalación y mantenimiento. Punto a multipunto: la comunicación entre la estación central y los equipos de campo se establecen a través de un medio compartido. Esto resulta en un menor gasto de infraestructura de telecomunicación, pero en un retardo mayor en la comunicación. El medio a utilizar puede ser alguno de los siguientes: Radio Microondas Satélite Líneas compartidas

20 Fibra óptica 2.1.2.4 Estación central Se puede dividir a la estación central en cuatro elementos principales [1]: Servicios SCADA: engloba los elementos de adquisición de datos, mantenimiento de las tablas en tiempo real y procesamiento de alarmas. Servicios históricos: se refiere a la base de datos histórica, que permite crear estadísticas del proceso y llevar un registro del momento de ocurrencia de las fallas. Interfaz de operador: permite al operador actuar con el sistema enviando instrucciones, o simplemente atendiendo las alarmas producidas. Interfaz de comunicación: se encargan de comprender la información recibida del protocolo de comunicación con los equipos de campo, u otros equipos del sistema, y traducirla a una estructura manejable por los servicios SCADA. Los componentes de la estación central pueden variar considerablemente dependiendo de la aplicación, pero en términos básicos debe poseer: Computador de procesamiento: preferiblemente con varios puertos de expansión para tarjetas de adquisición de datos, y con una capacidad de procesamiento superior a la de un computador personal. También se recomienda el paralelismo para garantizar la redundancia, y así asegurar el continuo funcionamiento del sistema en caso de que alguno de los equipos falle. Pantalla o monitor: permite al operador observar un esquema del proceso, su estado actual, las alarmas, y otro tipo de información histórica que le permita decidir sobre las acciones a tomar.

21 Periférico de interacción: usualmente teclado y ratón. Le permiten al operador seleccionar los componentes que desea ver, y enviar comandos a los equipos de campo. Tarjeta de red de comunicación: es la que permite establecer el flujo de información entre la estación central y los otros equipos del sistema, para enviar las decisiones tomadas o recibir los datos de las mediciones. 2.2 Middleware: En esta sección se pretende explicar qué es el middleware, qué funciones tienen, cuáles son sus ventajas y desventajas, y qué tipos de middleware existen. Específicamente, se quiere explicar el middleware orientado a mensajes. 2.2.1 Concepto El middleware puede ser definido como una aplicación de software que sirve como intermediario entre distintos componentes, y que es utilizado comúnmente para dar servicio a esquemas de aplicaciones distribuidas complejas. Puede ser referido como pega para software o la barra en la frase Cliente/Servidor, ya que precisamente actúa como una capa presente entre las dos aplicaciones y el sistema operativo, o en algunos casos entre la aplicación y los servicios de red.

22 2.2.2 Funciones del middleware Las funciones del middleware son: [2] Transparencia de localización de otras aplicaciones o servicios a través de la red. Busca ocultar el hecho de que la aplicación es distribuida, haciendo sentir al usuario final que está utilizando recursos que se encuentran en su propia área de trabajo. Proveer interfaces estandarizadas uniformes que permitan a los desarrolladores de software implementar las ventajas del middleware a sus programas de una manera sencilla y rápida, permitiendo la reusabilidad del código y la interoperabilidad de los programas. Ocultar detalles de programación de bajo nivel, así como la heterogeneidad de las aplicaciones y los otros componentes del sistema (sistemas operativos, componentes de hardware y protocolos de comunicación, entre otros). 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. Su principal ventaja es que permite alcanzar altos grados de comunicación e integración entre las aplicaciones, pero a la vez facilitando el desarrollo y manejo de las mismas. Entre las desventajas está el aumento de la latencia (o retardo) en las aplicaciones, al tener que relegar éstas las funciones de comunicación a una aplicación externa; y la posible introducción de hoyos de seguridad en la plataforma.

23 2.2.3 Tipos de middleware Existen tres tipos generales de middleware: Middleware Orientado a Mensajes (MOM): es un tipo de middleware que transporta cualquier tipo de información a través de mensajes entre un componente fuente y uno o varios componentes destino, los cuales por lo general se ejecutan en distintos sistemas. Middleware de objetos: estos middleware son de un mayor nivel. Mientras los otros se enfocan en mantener la comunicación sencilla para lograr el desacoplamiento de las aplicaciones, los middleware de objetos van más allá del MOM al conectar a las aplicaciones a un nivel más alto... Este enfoque es más favorable cuando una compañía está estableciendo una arquitectura completamente nueva y se encuentra adquiriendo varias aplicaciones nuevas o desarrollándolas internamente [3]. Middleware RPC o de Llamada de Procedimiento Remoto: es un middleware especializado en servicios de petición / respuesta, donde una aplicación pide alguna información a otra y se queda detenida esperando por la respuesta. Los servicios de comunicación son orientados a conexión. Este tipo de sistemas se encuentran siempre sincronizados. 2.2.4 Middleware orientado a mensajes (MOM). Su funcionamiento se asemeja al del servicio postal. Una aplicación que quiera comunicar algo se dedica únicamente a colocarle una dirección y enviarlo al servidor middleware. Éste se encarga de enviarlo al destinatario o de colocarlo en el tópico correspondiente si existe más de un receptor.

24 Figura 2.3: Esto define los dos esquemas de middleware, que pueden apreciarse en la Punto a punto (PtP): permite a una aplicación enviarle un mensaje específicamente a una aplicación en particular. Este mensaje se coloca en una cola de mensajes de donde se transmiten al destinatario cuando éste se encuentra disponible. Publicar/Suscribir (Pub/Sub): en este esquema un productor de información escribe un mensaje que no se encuentra dirigido a una aplicación en particular sino a un tópico de mensajes. De esta manera, las aplicaciones que estén interesadas en esta información se suscriben al tópico y reciben los mensajes del mismo. Figura 2.3 Esquemas de middleware Entre las ventajas del MOM se encuentra: El esquema publicar/suscribir permite que varios clientes se vayan integrando a la plataforma de manera eficiente, sin tener que reconfigurar los otros componentes para que puedan hablar con el nuevo programa. Por ello, se amplía la escalabilidad del sistema. No es necesario que el destinatario se encuentre conectado para recibir el mensaje. Si en ese momento no se encuentra disponible, se puede configurar el sistema para que almacene los mensajes, para que luego sean retirados por la aplicación al desocuparse.

25 No importa si la aplicación es transferida a otro equipo ya que la forma de direccionamiento se realiza a través de nombres y no de direcciones estrictas. Los sistemas de envío de información y respuesta se encuentran totalmente desacoplados, lo que permite a las aplicaciones realizar otras tareas no criticas mientras se recibe el acuse de recibo de un mensaje. Simplicidad para la comunicación de los programas, al relevar en la plataforma la lógica de transporte del mensaje. La calidad de servicio puede ser ajustada a la necesidad de la aplicación. Por ejemplo, si se tiene un sistema 100 % confiable, esto podría significar un esfuerzo en garantizar la recepción de los mensajes por todos los componentes. Si dada la naturaleza de la aplicación esto no es necesario, sino que se puede soportar una confiabilidad menor (95 %), el sistema se puede adaptar a este nuevo requerimiento y ver incrementada su eficiencia. Se pueden establecer prioridades para los mensajes, de manera que el sistema procese en primer lugar los que son más importantes para él. Para las aplicaciones móviles, que en los últimos años han tenido una evolución significativa en el área tecnológica de las comunicaciones, la arquitectura MOM surge como una alternativa muy interesante. Esto se debe a que estas aplicaciones no se encuentran conectadas en todo momento debido a su naturaleza dinámica. Por ello es atractiva la comunicación a través de mensajes, que pueden ser guardados en un servidor en caso de que no se encuentre disponible el dispositivo en el momento de su envío. Entre sus desventajas están: Por su funcionamiento, no es tan apropiado para aplicaciones de comunicación síncrona, por lo que está diseñado para formas de comunicación asíncrona.

26 No existe aún un estándar que establezca su funcionamiento básico. Por ello, para comunicar MOMs de distintas marcas será necesario desarrollar interfaces de enlaces para ellas. 2.3 Sistema Operativo Linux En esta sección se busca mencionar brevemente qué es el sistema operativo Linux, y sus características concernientes a los sistemas distribuidos para aplicaciones de control. Además se hace mención del núcleo 2.6 del sistema operativo y de como éste evidencia una tendencia del Linux para permitir características de sistemas operativos para aplicaciones en tiempo real. Por último, se mencionan dos de las principales licencias para software de código abierto. 2.3.1 Qué es Linux? El GNU/Linux es un sistema operativo de código abierto desarrollado por Linus Torvalds basado en el UNIX. Implementa los estándares POSIX (por sus siglas inglés Portable Operating System Interface, la X por Unix) especificados por la IEEE los cuales definen las APIs para los programas que corren sobre sistemas UNIX; a la vez que permite la libre distribución del sistema y de su código fuente. La base del sistema operativo es denominada núcleo o kernel, que actualmente se encuentra en su versión 2.6 2.3.2 Ventajas y desventajas Entre las ventajas del Linux se encuentra: Es totalmente gratis y de libre distribución, ya que se rige bajo la licencia GPL.

27 Es portátil a cualquier tipo de plataforma, ya que se puede adaptar el núcleo del sistema a cualquier tipo de hardware. Por ello, es muy conveniente para computadores antiguos de baja capacidad y poco espacio ya que permite elegir con exactitud las aplicaciones necesarias para la función específica de ese equipo. Es posible instalar únicamente los paquetes estrictamente necesarios para las funciones que va a realizar el equipo, los cuales podrán ser compilados directamente en el sitio. Esto permite un mayor rendimiento de las aplicaciones, así como un ahorro en el espacio de almacenamiento. Es seguro y versátil, ya que basa su sistema de seguridad en el del UNIX que ha demostrado ser robusto y eficiente. Es multiusuario, por lo que permite la distribución de los recursos entre los distintos usuarios. Al ser un producto de código abierto, posee miles de personas alrededor del mundo revisando constantemente el código en busca de errores o fallas. Al momento de ser detectada una, es fácil y rápido distribuir un parche que solucione el problema. Entre las desventajas del Linux se tienen: Existen demasiadas distribuciones de Linux, lo cual logra confundir al consumidor. El sistema no es tan amigable como otros, ya que desde sus principios fue destinado para personas con cierto nivel de conocimientos en informática. El hecho de ser un producto de código abierto y distribuido a través de Internet genera desconfianza en el usuario.