Sistemas en Tiempo Real con monitoreo Web.

Modificaciones y mejoras sobre el proyecto

SCADA SMVE

Autores: Castro, Lucas Luis.

Harris, Gonzalo Ezequiel.

Tutor: Lopez, Ricardo

Tesis presentada para obtener el grado de

Licenciatura en Sistemas Informáticos.

Facultad de Ingeniería - Universidad Nacional de La Patagonia San Juan Bosco

Agosto de 2016.

INDICECAPÍTULO 1: Introducción , Alcances Y Objetivos de la Tesis........................................................5

1.1 Resumen............................................................................................................................... 5 1.2 Introducción.......................................................................................................................... 5 1.3 Definición de sistema SCADA..............................................................................................6 1.4 Características de un sistema SCADA...................................................................................61.5 Componentes de hardware..................................................................................................... 8

Computador Central o MTU (Master Terminal Unit)..............................................................9 Unidad Terminal Remota - RTU's (Remote Terminal Unit).....................................................9 Red de comunicación........................................................................................................... 10

1.6 Necesidades de un sistema SCADA....................................................................................10 1.7 Sistema SCADA SMVE (Sistema de Monitoreo de Variables Eléctricas)............................11

Estándar de Comunicaciones RS-485...................................................................................11 Variables de Tiempo Real:.................................................................................................... 12 Variables de tipo Históricas:................................................................................................. 13

1.8 El servidor del sistema........................................................................................................ 13 1.9 Objetivos de la tesis............................................................................................................. 15 1.10 Alcance............................................................................................................................. 16 1.11 Propuestas de mejoras....................................................................................................... 18 1.12 Técnicas a implementar..................................................................................................... 181.13 Resultados esperados..........................................................................................................19

CAPITULO 2: Requerimientos de las Aplicaciones........................................................................21 2.1 Introducción........................................................................................................................ 21 2.2 Definición de Entradas y Salidas.........................................................................................21

Eventos................................................................................................................................. 21 Estados................................................................................................................................. 23 Entradas Digitales................................................................................................................. 24 Entradas Analógicas............................................................................................................. 24 Salidas Digitales................................................................................................................... 25 Salidas PWM........................................................................................................................ 25

2.3 Elementos intervinientes en el SCADA eléctrico.................................................................25 Interruptores......................................................................................................................... 25 Transformadores................................................................................................................... 25 Relés.................................................................................................................................... 26

Protección diferencial..................................................................................................26 Protección de distancia......................................................................................................... 26 Seccionadores....................................................................................................................... 27

2.5 Propiedades de los componentes de un circuito...................................................................29 2.6 Actualización de datos......................................................................................................... 30

CAPÍTULO 3: La Base de Datos del Sistema SCADA...................................................................33 3.1 Resumen............................................................................................................................. 33 3.2 Introducción........................................................................................................................ 33

Generalidades....................................................................................................................... 33 3.3 Disparadores (Triggers).......................................................................................................35

Características y reglas a seguir al utilizar un disparador......................................................36 Variables especiales en PL/pgSQL al utilizar un disparador..................................................38 Orden de ejecución de los triggers........................................................................................39 Restricciones de los Triggers................................................................................................ 40

3.4 Herramientas de Administración de PostgreSQL.................................................................40

2

3.5 Mecanismos de Notificación en Postrges: LISTEN/NOTIFY (Notificaciones Real-time)....41 3.6 Diseño y definición de la base de datos del proyecto SMVE...............................................44

Problemas detectados y soluciones propuestas......................................................................45 3.7 Conclusiones....................................................................................................................... 48

CAPÍTULO 4: Programación Reactiva........................................................................................... 49 4.1 Resumen............................................................................................................................. 49 4.2 Introducción - Patrón de diseño Observer............................................................................49 4.3 Programación Reactiva........................................................................................................50

Componentes Reactive X.....................................................................................................53 4.4 Operadores.......................................................................................................................... 55 4.5 Subject................................................................................................................................ 58

Variantes de Subject............................................................................................................. 58 4.6 Problema y Solución. Implementación realizada en la tesis.................................................63

Problema a resolver. Finalidad del proceso...........................................................................63 Solución actual del sistema SCADA.....................................................................................64 Implementación de mejora con Programación Reactiva........................................................65

4.7 Conclusiones....................................................................................................................... 67CAPÍTULO 5: Bróker de mensajes................................................................................................. 68

5.1 Resumen............................................................................................................................. 68 5.2 Introducción........................................................................................................................ 68 5.3 Patrón.................................................................................................................................. 69

5.5 Mosquitto........................................................................................................................ 78Connect................................................................................................................................. 80Conectar con LWT................................................................................................................ 81Connect................................................................................................................................. 83Conectar con LWT................................................................................................................ 83

5.10 Implementación................................................................................................................. 84 5.11 Conclusiones..................................................................................................................... 86RabbitMQ – Protocolo AMQP a implemetar reemplazado por MQTT.......................................87El estándar AMQP..................................................................................................................... 87 Modelo AMQP.......................................................................................................................... 87Elementos Intervinientes en el modelo AMQP...........................................................................89

Intercambiadores (Exchange)...............................................................................................89 Colas.................................................................................................................................... 89 Mensajes.............................................................................................................................. 90Vinculaciones (Bindings).......................................................................................................91

RabbitMQ................................................................................................................................. 94CAPÍTULO 6: Introducción al formato SVG..................................................................................96

6.1 Resumen............................................................................................................................. 96 6.2 Introducción........................................................................................................................ 96 6.3 El formato SVG.................................................................................................................. 97 6.4 Ventajas del formato SVG................................................................................................... 98 6.5 Vista general........................................................................................................................ 99 6.6 Editor de Gráficos Vectoriales INKSCAPE.......................................................................100 6.7 Conclusiones..................................................................................................................... 103

Capítulo 7 Flask – Servidor Web del sistema SMVE....................................................................1057.1 Resumen............................................................................................................................ 1057.2 Flask. Definición y características...................................................................................... 1057.3 Comparación Flask / DJango.............................................................................................. 1067.4 Trabajo realizado sobre Flask............................................................................................. 107

3

Capitulo 8 Resumen de lo desarrollado......................................................................................... 1098.1 Resumen............................................................................................................................ 109

Capitulo 9 Conclusiones – Líneas futuras de investigación...........................................................112 9.1 Resumen............................................................................................................................ 112 9.2. Observación de resultados y Conclusiones.......................................................................112 9.3. Líneas futuras de investigación.........................................................................................113 Referencias:............................................................................................................................ 115Agradecimientos:..................................................................................................................... 117

4

CAPÍTULO 1: Introducción , Alcances Y Objetivos de la Tesis.

1.1 Resumen

El objetivo principal de la automatización industrial consiste en gobernar laactividad y la evolución de los procesos sin la intervención continua de unoperador humano.

En la presente tesina se estudiará un Sistema SCADA para variables eléctricas,con el objetivo de mejorar sustancialmente procesos que hasta el momentofuncionan de una manera no óptima en materia de eficiencia. SeImplementarán nuevas tecnologías, abordando el paradigma de laprogramación reactiva para el cálculo de fórmulas y obtención de datoscalculados que representarán estados de elementos eléctricos. Éstos seránreflejados vía interfaz web sobre planos unifilares de estacionesTransformadoras y que podrán ser controladas en tiempo real por un operadordel servicio.

Además, abordaremos el uso del protocolo MQTT para el envío de mensajeríaentre el servidor del sistema y los clientes que se encuentren conectados. Estopermitirá reducir el tráfico de intercambio de información entre ambos,permitiendo que el servidor del sistema anuncie los cambios introducidos sobrela cola de mensajes correspondiente, que luego el cliente asociado tomará paraactualizar su pantalla.

Cada uno de los esquemas unifilares, se desarrollaron mediante el formatográfico SVG basado en XML, que nos proporciona un acceso efectivo a cadaelemento gráfico para poder modificar sus propiedades y poder actualizar cadaesquema. Sobre la base de la definición lograda, este capítulo describe en unmodo general los alcances de la tesis.

1.2 Introducción

En los últimos años se han estado desarrollando sistemas de Adquisición dedatos y Control, los cuales permiten supervisar y controlar las distintasvariables que se encuentran en un proceso o planta determinada. Para ello sedeben utilizar distintos periféricos, software de aplicación, unidades remotas,sistemas de comunicación, etc., los cuales permiten al operador tenercompleto acceso al proceso mediante la visualización en una pantalla en uncomputador.

No sólo se puede supervisar el proceso, sino además se puede tener acceso alhistorial de las alarmas y variables de control con mayor claridad, combinarbases de datos relacionadas, obtener gráficos, estadísticas y curvas defuncionamiento en un determinado período de tiempo para su análisis. Estatesina está basada sobre un sistema SCADA desarrollado por un grupo de

5

investigación de la Universidad Nacional de la Patagonia San Juan Bosco, delcual hemos sido partícipes en su desarrollo.

El objetivo primordial de la tesis es el de enfocarnos en algunos procesos quemediante la aplicación de nuevas tecnologías, sea posible optimizar variosaspectos del sistema, mejorando la performance y funcionamiento del servidornúcleo de la información que detallaremos en lo que sigue.

1.3 Definición de sistema SCADA

Describiremos un sistema SCADA y en nuestro caso cómo está conformado elactual desarrollo.

Un SCADA, acrónimo de Supervisory Control And Data Acquisition(Supervisión, Control y Adquisición de Datos) es un software paracomputadoras que permite controlar y supervisar procesos industriales adistancia. Facilita retroalimentación en tiempo real con los dispositivos decampo (sensores y actuadores) y controla automáticamente partes del proceso.Provee de toda la información que se genera en el proceso productivo(supervisión, control calidad, control de producción, almacenamiento de datos,etc.) y permite su gestión a usuarios del sistema (operadores, ingenieros decampo, gerentes, etc.)[5].

Un centro de control es el que comanda los equipos de la estación y puede a suvez, presentar información en tiempo real sobre el estado actual del sistema.

1.4 Características de un sistema SCADA

Los sistemas SCADA, en su función de sistemas de control, dan una nuevacaracterística de automatización que realmente pocos sistemas ofrecen: laSupervisión.

Sistemas de control existen muy variados y todos, bien aplicados, ofrecensoluciones óptimas en entornos industriales. Lo que hace de los sistemasSCADA una herramienta diferenciadora, es su característica de controlsupervisado. De hecho, la parte de control viene definida y supeditada, por elproceso a controlar y en última instancia, por el hardware e instrumental decontrol (PLCs, dispositivos lógicos, armarios de control... ) y los algoritmoslógicos de control aplicados sobre la planta, los cuales pueden existirpreviamente a la implantación del sistema SCADA. Éste se instalará sobre y enfunción de estos sistemas de control. Otros sistemas SCADA pueden requerir oaprovechar el hecho de implementación de un nuevo sistema deautomatización en la planta, para sustituir u optimizar los sistemas de controlexistentes.

En consecuencia, supervisamos el control de la planta y no solamentesupervisamos las variables que en un momento determinado están actuando

6

sobre la planta, sino que también podemos actuar y modificar las variables decontrol en tiempo real.

La labor del supervisor representa una tarea delicada y esencial desde el puntode vista normativo y operativo. De ésta acción depende en gran medidagarantizar la calidad y eficiencia del proceso que se desarrolla. En el supervisordescansa la responsabilidad de orientar o corregir las acciones de operaciónque se desarrollan y por lo tanto, tenemos una toma de decisiones sobre lasacciones de control.

Esto diferencia notablemente los sistemas SCADA de los sistemas clásicos deautomatización donde las variables de control están distribuidas sobre loscontroladores electrónicos de la planta, lo que dificulta el proceso de controlcentralizado, ya que estos sistemas una vez implementados no permiten uncontrol en tiempo real óptimo. La función de controlar y supervisar estossistemas se realiza sobre un PC industrial ofreciendo una visión de losparámetros de control sobre la pantalla del computador, lo que se denominacomúnmente como HMI (Human Machine Interface), como en los sistemasSCADA, pero sólo ofrecen una función complementaria de control y supervisión:Observar mediante aparatos especiales el curso de uno o varios parámetroseléctricos o de otra naturaleza, para detectar posibles anomalías.

Los sistemas de automatización de interfaz gráfica tipo HMI básicos, ofrecenuna gestión de alarmas en formato rudimentario mediante el cual, la únicaopción que le queda al operario es realizar una parada de emergencia, repararo compensar la anomalía y realizar un reset. En los sistemas SCADA se utilizaun HMI interactivo ,el cual permite detectar alarmas y a través de la pantallasolucionar el problema mediante las acciones adecuadas en tiempo real. Estootorga una gran flexibilidad a los sistemas SCADA. El modo supervisor del HMIde un sistema SCADA no solamente señala los problemas, sino que lo masimportante, orienta en los procedimientos para su solución.

A menudo, las palabras SCADA y HMI inducen a cierta confusión(frecuentemente alentada por los mismos fabricantes en su afán de diferenciarel producto o exaltar comercialmente el mismo). Cierto es que todos lossistemas SCADA ofrecen una interfaz gráfica tipo HMI, pero no todos lossistemas de automatización que tienen HMI son SCADA. La diferencia radica enla función de supervisión que pueden realizar estos últimos a través de la HMI.

Generalmente un SCADA presenta:

• Adquisición y almacenamiento de datos, para recoger, procesar yalmacenar la información recibida, en forma continua y confiable.

• Representación gráfica y animada de variables de proceso y control oseguimiento de éstas por medio de alarmas.

7

• Ejecución de acciones de control, para modificar la evolución del proceso,actuando bien sobre los reguladores autónomos básicos (consignas, alarmas,menús, etc.), o bien directamente sobre el proceso, mediante las salidasconectadas.

• Arquitectura abierta y flexible con capacidad de ampliación y adaptación.

• Conectividad con otras aplicaciones y bases de datos, locales o distribuidasen redes de comunicación.

• Supervisión, para observar desde un monitor la evolución de las variablesde control.

• Transmisión, de información con dispositivos de campo y otros PC.

• Base de datos, gestión de datos con bajos tiempos de acceso. Suele utilizarODBC.

• Presentación, representación gráfica de los datos. Interfaz del Operador oHMI (Human Machine Interface).

• Explotación de los datos adquiridos para gestión de la calidad, controlestadístico, gestión de la producción y gestión administrativa y financiera.

• Alertar al operador de cambios detectados en la planta, tanto aquellos que nose consideren normales (alarmas) como cambios que se produzcan en laoperación diaria de la planta (eventos). Estos cambios son almacenados en elsistema para su posterior análisis.

1.5 Componentes de hardware.

Un sistema SCADA, como aplicación de software industrial específica, necesitaciertos componentes inherentes de hardware en su sistema para poder tratar ygestionar la información captada. La figura 1 presenta su arquitectura.

Figura 1: Arquitectura SCADA

8

Computador Central o MTU (Master Terminal Unit)

Se trata del ordenador principal del sistema el cual supervisa y recoge lainformación del conjunto de Unidades Remotas de Control (RTU), situadas enlas distintas plantas del sistema. En el caso de un sistema eléctrico estasplantas son las subestaciones transformadoras. También supervisa a otrosprocesadores conectados a los instrumentos de medición de campo, ensistemas más complejos, o directamente a dichos instrumentos. Estecomputador suele ser una PC, la cual soporta el HMI. De esto se deriva que elsistema SCADA más sencillo es el compuesto por un único computador, que esel MTU que supervisa toda la subestación.

Las funciones principales de la MTU son:

• Interrogar en forma periódica a las RTU’s, transmitiendo consignas, siguiendousualmente un esquema maestro-esclavo. • Actúar como interfase al operador, incluyendo la presentación de informaciónde variables en tiempo real, la administración de alarmas y la recolección ypresentación de información histórica.

• Ejecutar software especializado que cumple funciones específicas asociadasal proceso supervisado por el SCADA. Por ejemplo, software para detección depérdidas en un oleoducto.

Unidad Terminal Remota - RTU's (Remote Terminal Unit)

Estas unidades remotas están situadas en los nodos estratégicos del sistema,gestionando y controlando las subestaciones, reciben las señales de lossensores de campo y comandan los actuadores de control.

Se encuentran en el nivel intermedio o de automatización, a un nivel superiorestá el MTU y a un nivel inferior los distintos instrumentos de campo que sonlos que ejercen la automatización física del sistema de control y adquisición dedatos.

Estos dispositivos no tienen porque ser PC's, ya que la necesidad de soportarun HMI no es tan grande a este nivel. Suelen ser dispositivos basados enmicroprocesadores o microcontroladores, aunque en sistemas muy complejospueden haber subestaciones intermedias en formato HMI. Una tendencia actuales la de dotar a los PLC's (en función de las E/S a gestionar) con la capacidadde funcionar como RTU's gracias a un nivel de integración mayor y CPU's conmayor potencia de cómputo. Esta solución minimiza costos en sistemas dondelas subestaciones no sean muy complejas, sustituyendo el ordenador industrialmucho más costoso. Un ejemplo de esto son los nuevos PLC's (adaptables a susistema SCADA Experion PKS(Power Knowledge System)) de Honeywell o los deMotorola MOSCAD, de implementación mucho más genérica.

9

Red de comunicación

Éste es el nivel que gestiona la información que los instrumentos de campoenvían a la red de ordenadores desde el sistema. El tipo de BUS utilizado en lascomunicaciones puede ser muy variado según las necesidades del sistema ydel software escogido para implementar el sistema SCADA.

Hoy en día, gracias a la estandarización de las comunicaciones con losdispositivos de campo, podemos implementar un sistema SCADA sobreprácticamente cualquier tipo de BUS. Podemos encontrar SCADA's sobreformatos estándares como los RS-232, RS-422, RS-485 o ethernet y medianteun protocolo de aplicación sobre TCP/IP, podemos interconectar el sistema.Tambien es posible una interconexión sobre todo tipo de buses de campoindustriales, hasta formas más modernas de comunicación como Bluetooth(Bus de Radio), WiFi, Micro-Ondas, Satélite, Cable, etc.

Otra característica de las comunicaciones de un sistema SCADA es que lamayoría se implementan sobre sistemas WAN de comunicaciones. Es decir, losdistintos terminales RTU pueden estar localizados muy distantesgeográficamente.

1.6 Necesidades de un sistema SCADA

Para que se pueda implementar un sistema SCADA es necesario que el procesoa controlar cumpla con las siguientes características:

• Elevado número de variables destinadas a seguimiento y control.

• Proceso geográficamente distribuido. Esta condición no se limita, ya quepuede instalarse un SCADA para la supervisión y control de un procesoconcentrado en una localidad.

• La información del proceso se necesita en el momento en que seproducen los cambios, o sea, la información se requiere en tiempo real.

• Necesidad de optimizar y facilitar las operaciones de la planta, así comola toma de decisiones, tanto gerenciales como operativas.

• Los beneficios obtenidos en el proceso justifican la inversión en unsistema SCADA. Estos beneficios pueden reflejarse como aumento de laefectividad de la producción, de los niveles de seguridad, etc.

10

1.7 Sistema SCADA SMVE (Sistema de Monitoreo de Variables Eléctricas)

El SCADA en el cual nos basamos es un software de recolección de datosgenerados en diferentes subestaciones transformadoras eléctricas, ubicadas enla ciudad de Trelew. Cada subestación transformadora está compuesta devarios IED's que recolectan datos de cada uno de los elementos intervinientesen el sistema eléctrico, a controlar desde nuestro sistema SCADA.

Un IED (Inteligent Electronic Device) es un Dispositivo ElectrónicoInteligente según lo define la norma IEC 61850. Conceptualmente y aplicadoal campo eléctrico, es una placa con un microcontrolador y sus periféricos, queresulta apta para controlar un Equipo de la red de potencia (interruptor,transformador, protección eléctrica, medidor de energía, etc).

Los IED's reciben datos de sensores y de diversos dispositivos eléctricos ypueden informar estados de ciertos dispositivos, como interruptores que sedisparan cuando se detectan tensiónes, corrientes o frecuencias en exceso odefectos sobre un estado considerado como normal o cuando se sucedenvariaciones (deriva máxima) por encima de cierto valor predeterminado(setup).

Un IED controla la entrada y salida hacia el equipo de campo y dispone lascomunicaciones necesarias para poder ejercer la supervisión y control. Todoslos IED's asociados al equipamiento de la red de potencia pueden sernormalizados y conformar de este modo una red de comunicaciones y control.

Como mencionamos en la definición del IED, cada uno de ellos esta compuestopor un microcontrolador. Éste es un circuito integrado que incluye unacomputadora: CPU (unidad central de procesamiento), memoria y periféricosde entrada y salida. El microcontrolador es una computadora diminuta, conreducido costo económico y consumo de energía.

En el sistema que abordamos, existen IEDs insertos en los medidores AlphaII delas subestaciones transformadoras. Éstos presentan la posibilidad de extraerlas variables de medida de interés, enviando la información al exterior, pormedio de una placa de comunicaciones de red bajo norma RS-485.

Estándar de Comunicaciones RS-485

Es un estándar de comunicaciones en bus de la capa física del Modelo OSI,está definido como un sistema en bus de transmisión multipunto diferencial, esideal para transmitir a altas velocidades sobre largas distancias (35 Mbit/shasta 10 metros y 100 kbit/s en 1200 metros) y a través de canales ruidosos,

11

ya que, por ser un bus balanceado, es prácticamente inmune a los ruidos quese producen por inducción eléctrica de las líneas de transmisión.

Figura 2: Medidores asociados a un IED

Además en cada estación transformadora se encuentra un Concentrador deInformación Maestro, que recolecta los datos enviados por cada IED.

Cada Concentrador Maestro (CoMaster) tiene como función:

• Concentrar todos los IED's (medidores) de la subestación.

• Oficia de Puente o Gateway entre la red local RS485 de los IED's de la

subestación y la Red Privada Virtual (VPN) sobre ethernet / internet.

• Conforma un IED embebido en si mismo, para ingresar los estados de

dispositivos eléctricos de la subestación (Interruptores, seccionadores).

• Se convierte en Puente para acceso a un IED en forma remota, en caso

de necesidad de diagnóstico o configuración.

• Cada Concentrador Maestro recopila variables de tiempo real y variables

históricas que almacena por subestación.

Variables de Tiempo Real:

• Potencias Activa y Reactiva por alimentador. (Indirectas de Corrientes y

Potencia Aparente)

• Tensión 33KV/ 13.2KV

• Estados de Interruptores.

• Alarmas Dinámicas y Estáticas.

• Tensión y Estado de Alta o Baja Tensión de Servicios Auxiliares.

12

Variables de tipo Históricas:

• Eventos: Apertura/cierre de Interruptores . Disparos y Alarmas.

• Energías Activa y Reactiva, con períodos de 15 minutos.

Estas variables son enviadas al Servidor, mediante tramas que responden a unprotocolo propietario (denominado Mara 1-v4).

Las variables se dividen en:

1) variables Analógicas (ai).

2) variables Digitales (di).

3) Eventos (ev).

En las figuras 3 y 4 se representa una interconexión de los módulos quecomponen el SCADA.

Figura 3: Estructura General del SCADA

1.8 El servidor del sistema.

Toda la información recogida por los Concentradores Maestros de los IEDs decada Estación Transformadora es almacenada en el servidor del sistemaSCADA. Esta información llega desde campo, como tramas de bits con datos deentrada y salida analógicos y digitales.

Estas tramas son procesadas por un proceso Python (Motor Scada) que seencarga de decodificar la información y almacenarla en la base de datos(BDD). Estos módulos se destacan en las figuras 2 y 3.

13

Muchos de estos datos, sirven para obtener una serie de datos calculados queserán de vital importancia en el sistema. Además de contener la base de datosdel sistema será el encargado de alimentar al Servidor Web, que elaborapáginas tanto estáticas como dinámicas que alimentarán a usuariosconectados a través de internet desde PC's, Notebooks y celulares.

El motor SCADA será también el encargado del envío de avisos tanto enformato de mensajes de Texto o mails en función de una tabla de parámetrosprogramable por el usuario administrador del sistema, para alertar sobrealguna anomalía que haya surgido en el sistema.

Cada Operador del sistema SMVE se conecta mediante un navegador a lapagina web del servidor. Desde allí, podrá acceder a cada una de lasestaciones transformadoras para ver su estado, analizar estadísticas, o verlistados de eventos históricos.Cada estación transformadora tiene un esquema unifilar único, con lo cual eloperador del sistema deberá optar por un esquema a la vez para visualizar entiempo real el estado del sistema.

Figura 4: Estructura General (2) del SCADA

14

Figura 5: Esquema Funcional

1.9 Objetivos de la tesis.

Nuestro objetivo se centra en mejorar sustancialmente, ciertos aspectos quepueden implementarse en el desarrollo del Sistema SCADA de mediciones devariables eléctricas construido y actualmente en fase de producción.

Un tema sensible en el SCADA son los datos calculados que se generan en basea datos reales provenientes del campo. Cada dato calculado, posee unaformula asociada, la cual puede contener una o mas variables de campo. Almodificarse algunas de estas variables, se deben generar los cálculosnecesarios para que las variables calculadas actualicen su valor y seanalmacenadas en la base de datos.

A cada esquema unifilar de una estación Transformadora, se puede accederdesde la pagina web del sistema SCADA. Estos esquemas indican mediantedatos numéricos y coloración el estado de elementos eléctricos y cuál es elestado de una subestación transformadora en tiempo real. En este último sepuede apreciar por ejemplo, el nivel de tensión de una barra en Kv, laintensidad de corriente (medida en Amperes) y la potencia Activa (MVA) de undeterminado campo, como así también el estado de las alarmas y distintoselementos que gracias a su coloración indican si un elemento esta activo o noen el sistema.

Los datos que provienen de campo nos indican el estado en que se encuentracada componente eléctrico (Interruptor, seccionador, puesta a tierra, alarma).

15

Con el transcurso del tiempo estos componentes pueden cambiar su estadogenerando eventos, con lo cual el esquema unifilar representado en la web,debe indicar de manera coherente los cambios ocurridos en cada estación.Desde las entradas de alimentación de cada estación en sus campos superioresde 33kv, descendiendo hasta las barras de salida de 13,2 Kv, el esquemaunifilar debe representar el estado real del sistema. Según el elemento quereporte un cambio de estado, el esquema unifilar deberá modificar algún valorde los elementos relacionados, dando al operador una idea clara y precisa de loque esta ocurriendo en cada estación transformadora.

En los próximos capítulos se detallará cómo se realizan los cálculos para que seactualicen los elementos del esquema según su relación en el circuito y cómoestos resultados impactan en el plano visualizado por el operador del sistemadesde el navegador web. Para resolver este problema de una manera maseficiente , se modificó el procedimiento de cálculo, utilizando un nuevoparadigma de programación como es la programación reactiva, donde ensimples palabras lo que se logra es que solamente se ejecute el re-cálculo delas variables que cambiaron su estado en campo y aquellas que tengan algunarelación dependiente de estas.

Daremos estadísticas de uso con cada uno de los procesos en ejecución,(sistema actual vs sistema modificado) bajo las mismas cargas, para analizar elresultado de las dos implementaciones y poder así sacar conclusiones decuánto se ha mejorado en el uso de recursos del sistema de cómputo. Otro aspecto importante que queremos mejorar del SCADA es la comunicaciónentre Cliente y Servidor, utilizando un protocolo de mensajería llamado MQTT(Message Queue Telemetry Transport), donde mediante un servicio demensajes con reconocimiento se puede optimizar el envío de paquetes yactualizaciones de pantallas, recibiendo exclusivamente lo que es de interésdel operador, sin tener que hacer una actualización completa de toda lapantalla cada vez.

Cabe destacar que sin esta solución, el cliente web envía peticiones cada 5segundos al servidor web, solicitando los cambios registrados con posterioridada su ultima estampa de tiempo. Para desarrollar la comunicación se utilizó unbróker de mensajes. El mismo es un software de negociación de mensajes decódigo abierto, y entra dentro de la categoría de middleware de mensajería.

1.10 Alcance

El enfoque de la presente tesina hará hincapié dentro del proyecto SMVE, en laredefinición del proceso de actualizaciones de variables en base a cálculos quedeben ejecutarse cuando las variables de campo se modifican y estas tienenrelación directa con variables calculadas.

16

El funcionamiento del proyecto como base al inicio de nuestra intervención eracomo se describe a continuación:

Cada concentrador maestro envía al servidor del sistema SCADA cada 15segundos los valores de mediciones y estados de los componentes eléctricosinstalados en cada subestación. El servidor procesa cada trama y almacenaestos valores en las tablas correspondientes, según sean señales analógicas odigitales.

Luego, dentro del motor SCADA y cada 5 segundos, se despierta un procesoque recorre una tabla que calcula fórmulas relacionadas con las variables deentrada. El resultado de estas fórmulas, son variables calculadas que seránalmacenadas en otras tablas de la base de datos y servirán para poder dibujarel esquema unifilar en la pantalla del cliente web.

Las fórmulas residen en una tabla específica de la base de datos y por su grancantidad, cada ejecución ocupa gran parte de los recursos de procesamientodel servidor, ya que re-calcula desde la primera a la última fórmula en cadanueva ejecución. Los resultados de estos cálculos son valores que modificanpropiedades de objetos relacionados con el esquema gráfico de cadasubestación y responden a la dependencia que tienen con los componenteseléctricos que emitieron las señales desde las estaciones. Básicamente aportanel resultado de propiedades de color o de texto, que deben cambiar para que eloperador tenga a la vista un modelo que representa el estado eléctrico de unasubestación de una forma coherente para la operación eléctrica.

Solo mencionaremos la llegada de tramas con eventos provenientes desde lassubestaciones de energía. Estas tramas son enviadas mediante un protocolopropietario aunque abierto, denominado Mara-1-v4, el cual mencionaremos enpróximos capítulos, pero que no será parte de la tesis su especificación nitratamiento.

A modo de resumen y para poder ubicarnos, nuestro trabajo se iniciará a partirde la actualización de la base de datos a través de sucesivas llegadas detramas Mara-1 provenientes del campo, (enviadas por el concentradormaestro), o por medio de un comando emitido por un operador desde lainterfaz web. Allí trabajamos en el proceso de cálculos de fórmulas y nuevasactualizaciones, ejecutando de manera eficiente solo las fórmulas quecontengan las variables que nos anuncia el CoMaster que se han modificado,utilizando un nuevo paradigma de programación como es la ProgramaciónReactiva.

Otro aspecto importante a mencionar es el desarrollo de una comunicaciónmas eficiente entre el servidor y cliente mediante el uso de bróker demensajes. El sistema SCADA originalmente actualizaba los esquemas de lasiguiente manera:

Al inicio cuando un operador solicitaba una subestación a la aplicación web, seprecargaba el esquema y se solicitaban las actualizaciones de todos suscomponentes para obtener de manera inmediata el estado del sistema real.

17

Luego, cada 5 segundos el cliente web enviaba una petición al servidor,solicitando los cambios ocurridos con posterioridad a su última actualización(mediante timestamp incorporado en el mensaje) y actualizaba el esquema.

Con el enfoque de bróker de mensajes, se logra una eficiencia muy grande enla comunicación entre cliente y servidor. Básicamente el servidor es quienanuncia mediante mensajes a un bŕoker informando los cambios ocurridos yeste reenvia el mismo al cliente asociado al mismo topico y actualiza losesquemas en base a estos. Un proceso java script analiza cada mensaje ymediante el uso del lenguaje XML usado en los esquemas SVG, se modificanlas propiedades de los objetos gráficos acorde al funcionamiento real delsistema.

Estos son los límites donde se centrará nuestro desarrollo y mejoramiento delsistema.

Observación: Como se mencionó con anterioridad no será abarcado en lapresente tesis el tipo de comunicación y protocolo utilizado para la recolecciónde datos de cada Concentrador maestro al servidor.

1.11 Propuestas de mejoras.

Principalmente las mejoras que proponemos están relacionadas con laelaboración de las variables calculadas. La forma en que este cálculo se realizaes el que propondremos realizar desde la perspectiva de la programaciónreactiva, ya que implementa el patrón de diseño Observer, en el cual unevento sobre un objeto dispara una reacción en cadena hacia otros objetos.

La segunda propuesta tiene que ver con la forma en que es notificada lainterfaz web de los cambios que se van sucediendo en las estaciones deenergía. Nuestro trabajo propone la implementación de una herramientadisponible en el mercado, que administre la interoperabilidad entre procesos,basado en el protocolo MQTT. El mismo será detallado en los próximoscapítulos.

Las modificaciones que se deberán reflejar en los esquemas unifilares selograron mediante el uso de gráficos con formato SVG, los cuales tienen unarepresentación XML, lo que nos permite modificar cualquier propiedad ocaracterística gráfica del esquema de manera muy cómoda y sencilla.

1.12 Técnicas a implementar.

Uno de los primeros cambios que realizamos en el esquema del sistema SCADASMVE es en la base de datos. Aprovechamos una de las opciones deconfiguración que tienen las bases de datos postgresql con respecto a lasnotificaciones sobre las tablas de la base de datos. Identificamos cuáles son lastablas críticas para nuestro objetivo y programaremos trigger's, que identificancuándo la tabla se actualiza. En ese preciso momento enviaría una notificación

18

a través de un canal de comunicación, que es atrapado desde la aplicacióndesarrollada en lenguaje Python y hace el tratamiento correspondiente con esedato. Esto será explicado con detalle en el capítulo sobre el diseño y las basesde datos postgresql.

Utilizamos la programación reactiva para el re-cálculo de variables de medicióny el acceso/actualización de la base de datos. Detallaremos cuál de todas lasopciones que nos ofrece la programación reactiva nos pareció la másadecuada, y mostraremos las diferencias en performance con respecto a cómose estaban realizando los cálculos hasta el momento.

Por último, mostraremos la implementación de una herramienta deinteroperabilidad para la comunicación entre procesos basada en el protocolode comunicación AMQP. Utilizaremos esta herramienta para transparentar lacomunicación entre los procesos. La propuesta trata del envío de mensajes conlas novedades sobre datos de cada subestación a los clientes web que esténsubscriptos a una cola de mensajes y sean reflejados en los esquemasunifilares desarrollados en formato SVG, el cual nos brinda beneficios que en sucapítulo específico serán mencionados.

1.13 Resultados esperados.

Conociendo desde su inicio el desarrollo del sistema SCADA de medicionesvariables eléctricas, nos vimos con la posibilidad de introducirnos en eldesarrollo de procesos claves que podían ser estudiados y que aportarían unamejora sustancial en materia de eficiencia y performance con respecto alsistema que se encuentra funcionando en la actualidad. Para ello tuvimos que investigar dos tecnologías nuevas y poco aplicadas en losdesarrollos como son la Programación Reactiva y Bróker de mensajes. En cadauno de los capítulos correspondientes se explica detalladamente cada uno deestos conceptos y se da una explicación de cómo se implementó en el sistemaSCADA.

Una vez terminados ambos desarrollos y puestos en funcionamiento en elsistema de adquisición de datos, daremos un conjunto de comparaciones deperformance para que quede plasmado a la vista del usuario en cuántopodemos mejorar nuestro sistema, qué cantidad de recursos se haneconomizado y cuánto tiempo de procesamiento ahorramos en el servidor. Estoes importante ante la posiblidad que en un futuro el sistema creciera, ya sea encuanto a ampliaciones de estaciones transformadoras, creación de nuevasestaciones en la ciudad o la incorporación de nuevos puntos de monitoreo dedifícil acceso (como pueden ser las zonas rurales). Para que pueda seguirfuncionando como hasta el momento, sin ningún tipo de limitación.

Además demostraremos que con bróker’s de mensajes la comunicación entreel cliente web y el servidor puede ser mas eficiente, enviando desde el servidor

19

al cliente web solamente los cambios mínimos e indispensables para poder re-dibujar una estación transformadora, controlada por un operador de formaremota.

20

CAPITULO 2: Requerimientos de las Aplicaciones.

2.1 Introducción.

Los sistemas SCADA (Supervisory Control and Data Adquisition), vinculados asistemas eléctricos han tenido desde muchos años atrás gran importancia parael manejo de redes de potencia. Los sistemas computados y decomunicaciones han ido evolucionando en velocidad y capacidad dealmacenamiento y todo ello ha redundado en confiabilidad en la operación deun sistema eléctrico.

Estos sistemas poseían Unidades Remotas de Telecontrol (RTU's) que permitíanla inclusión de placas destinadas a distintas funciones: Adquisición de variablesdigitales, Analógicas y Emisión de comandos binarios. Las salidas analógicas olas digitales PWM (Pulse Width Modulation) eran de muy rara aparición, perotenían como utilidad el movimiento de motores o el cambio de posición de losreguladores de tensión en Trasformadores de potencia.

En el ambiente de la generación, transporte y distribución eléctrica, serequieren cierto grado de exactitud de los valores de medida. Estos valores sonimpuestos por el Ente Regulador de la Electricidad (ENRE) y las condicionesmás relevantes se detallan en el siguiente listado:

En mediciones para la operación: 0,5%

En mediciones comerciales entre agentes del mercado: 0,2%

Como constantes de tiempo en trasductores de medición: 300 ms.

Oscilaciones de la onda eléctrica: considerar 0,5 a 3 Hz.

Discriminación de eventos: 1 ms.

Discriminación de propagación de fallas: 1 ms.

2.2 Definición de Entradas y Salidas.

Eventos

En los sistemas de control existe un flujo de información que se propaga entrecomponentes de un circuito (mecánico, hidráulico, eléctrico, etc.)conformando lo que da en denominarse: Lazo. El lazo puede ser abierto,donde cada acción se desarrolla en cascada como una consecuencia decausas-efectos, sin que exista ningún vínculo o relación entre la primera quedispara la secuencia y la última que se considera como efecto o resultante detodas las anteriores. En otro caso, existe una realimentación o feedback entreel último efecto desarrollado y el primero iniciador, conformando un lazo

21

cerrado, de un modo tal que éste puede corregirse o modularse gracias a larealimentación, para desarrollar una nueva secuencia. En general, los ciclosde control suelen ser de lazo cerrado, dado que en este caso la acción decontrol es más segura, precisa y predecible.

En particular, los sistemas de de control eléctrico son casi siempre de lazocerrado. Solamente se deja librado a sistemas de control de lazo abierto, auna serie de procesos individuales y menores, donde el riesgo es pequeño yconocido de antemano. En esos sistemas de lazo cerrado muchas veces elhombre es parte componente del lazo. Esto es así porque en determinadascircunstancias, debido a su complejidad, se requiere una decisión que sólo elhombre puede resolver (aunque para determinadas acciones sistemáticas,cada vez más, las decisiones son tomadas por computadores). En estos casosel hombre actúa con un rol de Operador del sistema.

En estos sistemas realimentados es importante tener en cuenta el orden demagnitud de los tiempos involucrados en el retorno de realimentación quepermite efectuar la corrección. En los sistemas eléctricos estos órdenes sonbastante dispares y puede compararse los tiempos involucrados en losejemplos que se exhiben en la Tabla 1.

En cualquiera de los casos apuntados, debe existir el registro de una acciónde campo, por parte de un componente electrónico que realiza una traduccióndel evento a alguna variable eléctrica. A su vez la acción o una serie deacciones simultáneas con o sin relación entre sí, deben ser registradas debidoa que es importante su análisis ulterior y debe estar involucrada en eseanálisis, la hora de ocurrencia de cada uno de los eventos apuntados.

El registro, muchas veces se efectúa con equipos computados que están aalguna distancia entre sí (miles de kilómetros o pocos decímetros) por lo queal ser procesos diferentes en distintos computadores, debe haber algunasincronización entre ellos.

Acciones Ejemplos Orden de tiempos involucrados

1) Acciones donde el hombre es parte del lazo cerrado

Apertura y cierre de interruptores.

Cambios de puntos de operación detransformadores.

Cierres de compuertas hidráulicas.

20 segundos a minutos.

2) Proceso automático (sin intervención del hombre)

Actuación de protecciones eléctricas.

Vuelco de álabes de turbinas ante rechazo de carga.

60 a 400 milisegundos

3) Eventos eléctricos con o sin relación causa - efecto

Disparos de protecciones.

Apertura simultánea de interruptores.

1 ms a 80 ms

4) Eventos Eléctricos por causas naturales

Propagación de fallas en líneas1 microsegundo a varios microsegundos.

Tabla 1: Comparación de tiempos de ocurrencia de distintos eventos eléctricos.

22

En el mercado eléctrico existe una regulación que ejerce la CompañíaAdministradora del Mercado Mayorista Eléctrico (CAMMESA), que requiere quela información de todos los eventos de importancia que produzcan los actoresdel mercado (Generadores, transportistas y distribuidores de energíaeléctrica), sea comunicada en tiempo real mediante enlaces directos decomunicaciones con esta empresa, bajo las siguientes condiciones:

1) Discriminación de 1 ms entre eventos.

2) Antigüedad del evento desde su ocurrencia hasta estar en las bases dedatos de CAMMESA, no mayor a 20 segundos.

El no cumplimiento de estas normas impuestas por el ENRE conlleva aimportantes multas. Debido a ello, los actores del mercado se ven obligados aconfigurar enlaces de comunicaciones redundantes (satelitales, fibra óptica,radioenlaces, etc.)

Estados

La información de eventos aludida en el apartado anterior, tiene su soporte enel estado que se mantiene dentro de cada sistema y que a su vez se conformasobre la base de los estados individuales de cada uno de los componentes.

El estado de un sistema lo conforman una serie de variables que se recabancon cierta periodicidad en cada UC. Efectivamente, con un periodo que va devarios centisegundos hasta algunos segundos, según el caso, la UC tieneprevisto una rutina que recaba estados y los coloca como variables enmemoria. Estos estados generalmente se conforman con entradas digitales decampo, entradas analógicas, valores registrados por los subsistemas decomunicaciones o por el propio procesador de cada UC.

Los estados tendrán su correlato en variables que el procesador escribirá en sumemoria de lecto-escritura y a diferencia de los eventos que se guardan enuna cola rotativa, la toma de un nuevo estado sobreescribe los valores quelas variables poseían como consecuencia de la toma de estado inmediataanterior.

En general, ese estado global de una UC es recabado también periódicamentemediante un comando de protocolo emitido por parte del CC. Este estadonormalmente sirve con dos objetivos bastante diferenciados:

a) El mantenimiento de mímicos del sistema, en pantallas de lasterminales del CC y que otorgan al operador una información visual quele permite la toma de decisiones en un tiempo relativamente corto(algunos segundos).

b) La acumulación paulatina de estos estados sucesivos con periodos dealgunos segundos entre sí y con marcas temporales, lo que permiten laconformación de la base de datos histórica del sistema.

23

Entradas Digitales

Las entradas digitales son uno de los tipos de registro traducidos de fenómenosexternos a tener en cuenta. Provienen de fenómenos que tienen característicaON/OFF o abierto/cerrado.

En los sistemas eléctricos, tales tipos de señales provienen de un muy variado tipo de fuentes de las que citamos algunas:

• Apertura/Cierre de interruptores o seccionadores, detectados por contactos fines de carrera de elementos mecánicos.

• Apertura/Cierre de contactos de detectores de gases en transformadores (Sistema Buchholz de detección de descarga interna) por aumento de la presión interna.

• Apertura/Cierre de contactos con par bi-metálico para medición de temperatura en transformadores, motores y otras máquinas eléctricas.

• Apertura/Cierre de contactos traducidos por la circulación de corriente como elemento de detección (cambios de resistencia por temperatura, por posición, presión, etc).

A esta altura no debe confundirse el estado digital (o analógico) con un evento.En el primero tiene primordial importancia cuál es el valor de la variable sin importar cuándo este cambio ocurrió. En los eventos en cambio, lo primordial es el registro del tiempo de ocurrencia, necesario para determinar la secuenciade fenómenos que ocurrieron en el campo y en un momento totalmente diferido de análisis ulterior. Estas dos entidades tienen un distingo muy claro en el ambiente eléctrico fundamentalmente por la instancia en que son útiles. Los estados permiten al operador tomar una decisión de operación en tiempo interactuando con el sistema. Los listados de eventos en cambio, permiten un análisis ulterior de falla, ya por un profesional más capacitado y a efectos de efectuar modificaciones de mayor envergadura en el propio sistema o para el análisis de la falla con fines contractuales (multas).

Entradas Analógicas

Para la detección de este tipo de señales es muy común la adopción de losconversores analógico-digitales (ADC: Analogic Digital Converter). Estedispositivo convierte una entrada (analógica) eléctrica de tensión en un valorbinario (digital) representativo de esa tensión. Para ello la señal analógica - queposee una variación continua en el tiempo -, se la vincula con la entrada delADC y se somete a ésta a un muestreo. Los muestreos de la señal se efectúana intervalos regulares, normalmente en el ciclo de toma de estado que realizacada UC. Estos estados pueden tomarse con dos modalidades: Constituyendoun listado consecutivo de estados de cada variable o que cada estado vayasobrescribiendo su correspondiente anterior.

24

Salidas Digitales

Este tipo de información es la que refleja las realimentaciones que efectúa elcontrol sobre el sistema, ya sea el control automático o el que involucra a unOperador como parte del lazo.

En los sistemas eléctricos de potencia son muy raras las intervenciones máscomplejas que la unaria sobre el sistema. Esto es, las acciones de salida estánperfectamente individualizadas y por seguridad de operación de la red, esnormal que cada comando sea una acción aislada y distinguible de otrasacciones de salida similares, como parte integrante de un protocolo deoperación paso a paso que debe seguir el operador del sistema.

No existen para estas salidas mayores requerimientos y comúnmente seadicionan aquí los opto-acopladores y relés repetidores para aumentar elmargen de potencia de control exiguo que posee una salida digital

Salidas PWM

Este tipo de salida comúnmente es utilizada para el control de velocidad demotores, por modulación del valor medio de un tren de pulsos de tensiónaplicada, que regula bastante eficientemente la velocidad en motores deCorriente Continua. En otros casos de necesidad de mayor precisión puederecurrirse a mecanismos de control para motores paso a paso.

2.3 Elementos intervinientes en el SCADA eléctrico.

Interruptores

El interruptor, también llamado disyuntor, es un dispositivo destinado aestablecer o a cortar la continuidad de un circuito eléctrico bajo carga (concorriente circulante), y está construido de tal modo que puede agregar o quitargeneradores o líneas en un sistema eléctrico, en un modo de operación.También puede interrumpir el circuito cuando se produce una sobre-intensidadde corriente. Esta interrupción se realiza automáticamente y en un tiempo muybreve (típico 10/20 ms).

Transformadores

El transformador es un dispositivo en el cual la energía eléctrica estransformada en dos factores: tensión e intensidad. Independientemente deluso que se haga del transformador, se llama primario al circuito que recibe laenergía y secundario al que la suministra a los aparatos receptores.

25

Figura 6: Estación Eléctrica Transformadora

A ellos se debe la elevación de tensión elevadas para el transporte de energía,y luego la reducción de aquella para su distribución en el consumo.

Relés

La desconexión automática de los interruptores, a causa de las sobre-intensidades producidas, se realiza por intermedio de aparatos especialesllamados relés, los cuales pueden ser accionados por una muestra de lacorriente real que atraviesa el interruptor.

Protección diferencialEste tipo de protección se basa en el hecho de que mientras el objetoprotegido no presenta ningún defecto (cortocircuito o puesta a tierra), lascorrientes en la entrada y salida de cada fase son iguales. Bajo estascondiciones no podrá circular ninguna corriente por el relé diferencial. Sinembargo, al aparecer un defecto en el objeto que debe protegerse, lascorrientes primarias y secundarias serán diferentes. La corriente diferencialresultante circulará por el relé poniéndolo en funcionamiento, lo que causará laapertura del interruptor asociado al circuito.

Protección de distancia

En caso de cortocircuito la relación de la tensión a la corriente, es decir laimpedancia del bucle formado por los dos conductores por los cuales circula lacorriente de cortocircuito, es la medida de la distancia del relé al lugar del

26

cortocircuito y por consiguiente, un medio ideal para la temporización del relé.La protección de distancia es un relé que tendrá un retardo en sufuncionamiento tanto más pequeño cuanto más cerca se encuentre del lugarde la perturbación. La idea subyacente es relacionar el tiempo de desconexiónde los relés en función de las características particulares debidas alcortocircuito.

Seccionadores

Se utilizan para aislar las diversas partes de la instalación eléctrica, o bien paradividir las barras colectoras, o para poner a tierra los circuitos de lasinstalaciones cuando se procede al mantenimiento de las instalaciones. Elseccionador – a diferencia de un disyuntor -, debe trabajar bajo tensión pero sincorriente circulante.

2.4 Componentes de un circuito.

Cada componente eléctrico de un circuito de una estación transformadoraposee una forma de identificación única, diseñada para que de forma rápida eintuitiva podamos ubicar un elemento dentro del universo posible. Esta formade nombrar los equipos la llamamos TAG.

Los TAG's identifican de forma biunívoca cada elemento de campo como puedeser un Relé de Mínima tensión, un Interruptor, las Protecciones, etc. Estos componentes eléctricos emiten señales o mediciones que almacenará elConcentrador maestro de cada estación y que luego serán enviadas al servidorcada vez que este solicite los cambios originados (petición que se realiza cada15 segundos).

Cada trama emitida por un concentrador, contiene señales digitales, comopueden ser alarmas, aperturas o cierres de interruptores, seccionadores etc,como así también variables analógicas como por ejemplo: tensiones de barras,potencias activas y reactivas de cada alimentador, que indican de formanumérica su estado mediante una medición de su magnitud. Estas tramas sondesempaquetadas y analizadas por el sistema SCADA, el cual toma el valor decada una de ellas y las almacena en las tablas de entradas digitales oanalógicas según corresponda en la base de datos.

Estas tablas, además de contener los valores de estado de cada componenteelectrónico, tienen asociado un TAG identificatorio que será utilizado para todotipo de tratamiento en el sistema.

Los Tag's al ser únicos e irrepetibles, nos servirán como referencia para el tratamiento especifico de cada elemento.

Ejemplos de TAG's de componentes eléctricos característicos y su significado:

27

E11PR_04

E4252B03

Cada uno de estos TAG's se conforman de la siguiente manera:

• 2 caracteres iniciales para indicar el número de estación transformadora en la cual se encuentra ubicado.

• 1 carácter para indicar el nivel de tensón en el cual trabaja el componente.(1 : 13,2 Kv, 2 : 33 Kv.)

• 3 caracteres para indicar la clase del componente.(52B: Interruptor, 89S seccionador)

• 2 caracteres finales para indicar el campo en el cual esta instalado dentro de la estación transformadora.

Esta forma de nombrar cada componente, como concatenación de campos detamaño fijo, resulta muy eficiente ya que con su Tag podemos saberrápidamente, en que estación transformadora se encuentra, el nivel de tensiónen que trabaja, clase de componente y en qué campo de la estación seencuentra ubicado. Este mecanismo asociativo es muy útil para identificaciónde un componente en tareas de mantenimiento u operación.

28

2 carácteres:Estación Transformadora: N° 1

1 carácter:Nivel de tensión 1: 13,2 KV

3 caracteres:PR_: Potencia Reactiva

2 caracteres:Campo eléctrico: N° 04

2 caracteresEstación Transformadora: N° 4

1 carácter:Nivel de tensión 2: 33 KV

3 caracteres:52B: Interruptor Alimentador

2 caracteres:Campo eléctrico: N° 03

2.5 Propiedades de los componentes de un circuito.

Cada componente de los distintos circuitos eléctricos de nuestro SCADA, tieneun TAG o etiqueta asociado que lo identifica, pero además poseen otraspropiedades. Éstas pueden variar en el tiempo, dependiendo de los cambios deestados que puedan surgir en el campo o bien por algún cambio queexpresamente quiera realizar el administrador del sistema SCADA. La base dedatos del sistema posee una tabla que almacena dichas propiedades y sellama: hmi_svgelement.

De los datos que esta tabla contenga será nutrida la página web para reflejar elestado de cada componente para su representación en tiempo real.

Los campos mas importantes de esta tabla son:

Tag: Identificador único para cada componente eléctrico.

Description: Contiene la descripción del componente eléctrico.

ej: para el tag: E42RBD03, Description: "Prot.Int.RBC Disparo Transformador TR2"

Text: Generalmente en este campo se almacenan los valores de ingenieríade las mediciones de potencias, corrientes y en algunos casos textosdescriptivos de algún componente.

Fill: Este campo almacena un valor numérico solo en los casos que elcomponente eléctrico que se quiere representar gráficamente tenga estapropiedad. Este valor numérico es una referencia a un color del objeto enparticular.

Un ejemplo claro del uso del campo fill se da en las alarmas. En un esquemaunifilar de una estación, las alarmas se representan con un recuadro de bordeblanco, donde su relleno puede cambiar. En condiciones normales el color derelleno de una alarma es negro, pasando a rojo si la alarma se ha disparado.Ejemplo: Al activarse una alarma en campo, se envía una señal que el SCADAintroducirá en el campo fill del componente un Id_color = 6 equivalente al colorrojo, con lo cual este elemento en el diagrama será pintado en su interior concolor rojo, indicando que se disparo dicha alarma.

Stroke: Representa la propiedad borde de los objetos, como puede ser unconductor o un Devanado de Transformador de Potencia.

Para casos como el devanado de un transformador, su representación gráficaes un anillo, por lo tanto en el diagrama se utiliza un circulo donde su fill esnegro y se mantiene en el tiempo sin alterarse, mientras que su propiedadstroke o borde, cambiará de acuerdo al color asociado a la tensión que poseaen ese momento (por convención) , o blanco si se encuentra desenergizado.

Enabled: Indica si el elemento esta habilitado o no.

29

LastUpdate: Indica mediante una estampa de tiempo, cuándo fue la últimaactualización del componente.

On_Click_text_toggle: Este campo se usa en los casos que un operador delsistema haga click en componentes que puede operar para indicar la aperturao cierre de un componente, como por ejemplo un seccionador conaccionamiento de carro.

Observación: Cabe aclarar que el sistema SCADA no posee operación adistancia de los componentes del sistema (Telecomando mediante salidasdigitales), con lo cual un operador podrá indicar que un seccionador estaabierto de forma manual, a modo de aviso de mantenimiento.

2.6 Actualización de datos.

En la base de datos del SCADA, reside una tabla muy importante para elsistema denominada hmi_Formula. Esta tabla fue creada con el propósito deactualizar todos los valores de la tabla svg_element, que es la tabla que nutre acada componente de los esquemas unifilares de las estacionestransformadoras que veremos desde nuestro navegador web, en cuanto acoloración o datos de mediciones.

En este punto describiremos el funcionamiento de esta tabla sin hacer mencióna los cambios que introdujimos en el proceso de cálculos. Estos se verán endetalle en capítulos siguientes.

Esta tabla contiene 3 campos fundamentales para su uso:

Targuet_id: Identificador que hace referencia a un elemento de la tablasvg_element.

Svg_element contiene cada componente a ser reflejado en el diagrama unifilarque se presenta en la página web.

Attribute: atributo que deberá ser modificado del elemento apuntado portarguet_id luego que se haya calculado la formula asociada.

Formula: fórmula que deberá ser recalculada cada vez que se modifiquealguna de las variables intervinientes en la misma.

Cada fórmula fue importada a la base de datos luego de un exhaustivo análisisde cada componente. Para desarrollarlas se tuvo que tener en cuenta cómoafectaban los estados de componentes anteriores en el flujo normal de cadaestación.

Hay elementos gráficos, que dependen del estado del elementoinmediatamente anterior.

30

Recordemos que en los esquemas Unifilares la actualización de loselementos eléctricos se realizan siguiendo un flujo normal de energía,partiendo desde los alimentadores superiores hasta llegar a losdevanados superiores de los transformadores de potencia y desdecada distribuidor inferior hasta el devanado inferior de cadatransformador.

Ejemplos de fórmulas y como deben interpretarse

id_target attribute formula

91 text str((ai.E41VV_07.value-1227) * ai.E41VV_07.escala)

La formula que aparece en la grilla deberá ser ejecutada cuando elconcentrador maestro de campo acuse un cambio en la entrada analógica detensión (elemento ai.E41VV_07.value de la fórmula) o se haya modificado lavariable escala en la base de datos por el administrador del SCADA. Encualquiera de los casos se debe calcular la fórmula presentada. Para ello, antesdebemos obtener el valor que contenga la tabla de entradas analógicas ai enla fila cuyo tag sea E41VV_07, columna value y lo mismo con la columnaescala.

La fórmula quedaría conformada = ((2-1227)* 0.0074104)

El resultado de la misma, deberá ser almacenado en la tabla de elementosgráficos hmi_svgelement cuyo Id = 91 (Tensión Barra 2- 13.2KV) en sucampo text. Además, se modifica el campo last_update con la estampa detiempo actual.

Figura7: Imagen del campo calculado – Tensión de barra

Esto hará que el elemento gráfico en la pagina web cuyo tag sea el delidentificador 91 muestre el valor calculado en la fórmula (Indicado medianterecuadro rojo en la Figura 7) .

31

El ejemplo antes mencionado calcula la fórmula en base a datos provenientesde campo o modificación expresa del operador. Veamos ahora un ejemplodonde un componente depende del estado de otros componentes:

id_target attribute formula

81 fill SI(di.E4252B05.value,si(int(eg.E4289I05.text),eg.E4289I05.stroke,12),si(int(eg.E4252B05.text),6,10))

Aquí vemos una formula que afecta el relleno o fill, de un InterruptorAlimentador Linea 1 33 KV Entrada Anillo (id_targuet = 81).

En su fórmula se hacen varias comparaciones según distintos campos a teneren cuenta. En resumen, si el campo value del interruptor en la tabla de di(entradas digitales) es 1 toma el color que tiene el seccionador que lo contiene,sino le asigna el color cuyo id = 12 (Gris: sin tensión).

Si su valor digital es 0, se encuentra abierto, puede tomar el color rojo ( id = 6)o negro (id = 10) si la apertura fue controlada.

Figura 8: Imagen del Interruptor calculado – Alimentador Linea 1

Cabe destacar que los cambios hacia el entorno web, los realiza unprocedimiento desarrollado en Java Script, que cada 5 segundos envía unapetición al servidor web Apache para que le envíe las ultimas modificaciones.

El cliente al enviar esta petición también envía un parámetro indicando laestampa de tiempo de su ultima actualización, con lo cual el servidor deberárecuperar los cambios que se hayan suscitado con posterioridad. Es por estemotivo que la tabla de elementos gráficos se almacena una estampa de tiempoal momento en que se registra la modificación.

Observación: Este procedimiento de actualización recientementemencionado corresponde al sistema sin la implementación de las colasde mensajes. Se explicará detalladamente como se modificó elsistema y como realiza el proceso de actualización en el capitulo 6 dela presente tesina.

32

InterruptorTag=E4252B05

CAPÍTULO 3: La Base de Datos del Sistema SCADA.

3.1 Resumen.

Dentro de los objetivos de ésta tesis mencionamos la mejora de procesossensibles en el proyecto SMVE. En éste capitulo abordaremos la mejora en loque refiere a los procesos relacionados con la base de datos utilizada en elsistema. Mostraremos en detalle los cambios realizados y las técnicasimplementadas para realizar dicha mejora. También mencionaremos algunascaracterísticas de las base de datos Postgresql, que es la base de datos elegidaen el desarrollo del proyecto SMVE. Veremos en detalle el diseño de la base dedatos utilizada por el sistema, su definición y su funcionamiento.

3.2 Introducción.

PostgreSQL es un sistema de gestión de bases de datos objeto-relacional.

Utiliza un modelo cliente/servidor y usa multiprocesos en vez de multihilos para

garantizar la estabilidad del sistema. Un fallo en uno de los procesos no

afectará el resto y el sistema continuará funcionando [8].

La última serie de producción es la 9.3. Sus características técnicas la hacenuna de las bases de datos más potentes y robustas del mercado. Su desarrollocomenzó hace más de 16 años, y durante este tiempo, estabilidad, potencia,robustez, facilidad de administración e implementación de estándares han sidolas características que más se han tenido en cuenta durante su desarrollo.PostgreSQL funciona muy bien con grandes cantidades de datos y una altaconcurrencia de usuarios accediendo a la vez al sistema.

Generalidades

• Es una base de datos 100% ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad)

• Soporta distintos tipos de datos: además del soporte para los tipos basemas conocidos, también soporta datos de tipo fecha, monetarios, elementos gráficos, datos sobre redes (MAC, IP ), cadenas de bits, etc. También permite la creación de tipos propios.

• Incluye herencia entre tablas, por lo que a este gestor de bases de datos se lo incluye entre los gestores objeto-relacionales.

• Copias de seguridad en caliente (Online/hot backups)

• Unicode

33

• Juegos de caracteres internacionales

• Regionalización por columna

• Multi-Version Concurrency Control (MVCC), detallado más adelante.

• Múltiples métodos de autenticación.

• Acceso encriptado vía SSL

• Completa documentación

• Licencia BSD

• Disponible para Linux y UNIX en todas sus variantes (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows 32/64bit.

Alta concurrencia

Mediante un sistema denominado MVCC (Acceso concurrente multiversión,

por sus siglas en inglés) PostgreSQL permite que mientras un proceso escribe

en una tabla, otros accedan a la misma tabla sin necesidad de bloqueos.

Cada usuario obtiene una visión consistente de lo último a lo que se le hizo

commit.

Variedad de tipos nativos

PostgreSQL provee nativamente soporte para:

• Números de precisión arbitraria.

• Texto de largo ilimitado.

• Figuras geométricas (con una variedad de funciones asociadas).

• Direcciones IP (IPv4 e IPv6).

• Bloques de direcciones estilo CIDR.

• Direcciones MAC.

• Arrays (arreglos, colección de elementos de tipo base).

Adicionalmente los usuarios pueden crear sus propios tipos de datos, los quepueden ser por completo indexables gracias a la infraestructura GiST dePostgreSQL.

34

Claves

En PostgreSQL se pueden definir claves ajenas también denominadas Llaves

ajenas o Claves Foráneas (foreign keys).

3.3 Disparadores (Triggers).

Un disparador o trigger se define como una acción específica que se realiza deacuerdo a un evento, cuando éste ocurra dentro de la base de datos. Es laacción asociada a un evento. En PostgreSQL esto significa la ejecución de unprocedimiento almacenado basado en una determinada acción sobre una tablaespecífica. Todos los disparadores se definen por seis características:

• El nombre del disparador o trigger

• El momento en que el disparador debe arrancar

• El evento del disparador deberá activarse sobre...

• La tabla donde el disparador se activará

• La frecuencia de la ejecución

• La función que podría ser llamada

Entonces, combinando estas seis características, PostgreSQL ofrece crear una amplia funcionalidad a través de su sistema de activación de disparadores (triggers).

Su definición en base a la acción que se realiza en la tabla sería: Un disparadorno es otra cosa que una acción definida en una tabla de nuestra base de datosy ejecutada automáticamente por una función programada por nosotros. Estaacción se activará, según la definamos, cuando realicemos un INSERT, unUPDATE ó un DELETE en la tabla.

Un disparador se puede definir de las siguientes maneras:

Para que ocurra ANTES de cualquier INSERT,UPDATE ó DELETE.

Para que ocurra DESPUES de cualquier INSERT,UPDATE ó DELETE.

Para que se ejecute una sola vez por comando SQL (statement-level

trigger) Para que se ejecute por cada linea afectada por un comando SQL (row-

level trigger)

35

Su definición en lenguaje SQL es:

CREATE {OR REPLACE} TRIGGER nombre_disp

[BEFORE|AFTER] [DELETE|INSERT|UPDATE {OF columnas}] [ OR [DELETE|INSERT|UPDATE {OF columnas}]...] ON tabla [FOR EACH ROW [WHEN condicion disparo]][DECLARE] -- Declaración de variables localesBEGIN -- Instrucciones de ejecución[EXCEPTION] -- Instrucciones de excepciónEND;

El uso de OR REPLACE permite sobrescribir un trigger existente. Si se omite, yel trigger existe, se producirá, un error.

Antes de definir el disparador tendremos que definir el procedimientoalmacenado que se ejecutará cuando nuestro disparador se active.

El procedimiento almacenado usado por nuestro disparador se puedeprogramar en cualquiera de los lenguajes de procedimientos disponibles, entreellos, el proporcionado por defecto cuando se instala PostgreSQL, PL/pgSQL.

Características y reglas a seguir al utilizar un disparador

A continuación mostraremos algunas de las características y reglas másimportantes a tener en cuenta, cuando definimos un disparador y/oprogramamos un procedimiento almacenado que se vaya a utilizar por undisparador:

1) El procedimiento almacenado que se vaya a utilizar por el disparador debe definirse e instalarse antes de definir el propio disparador.

2) Un procedimiento que se vaya a utilizar por un disparador no puede tener argumentos y tiene que devolver el tipo "trigger".

3) Un mismo procedimiento almacenado se puede utilizar por múltiples disparadores en diferentes tablas.

4) Procedimientos almacenados utilizados por disparadores que se ejecutan una sola vez por comando SQL (statement-level) tienen que devolver siempre NULL.

36

5) Procedimientos almacenados utilizados por disparadores que se ejecutan una vez por línea afectada por el comando SQL (row-level) pueden devolver una fila de tabla.

6) Procedimientos almacenados utilizados por disparadores que se ejecutan una vez por fila afectada por el comando SQL (row-level) y ANTES de ejecutar el comando SQL que lo lanzó, pueden:

1. Retornar NULL para saltarse la operación en la fila afectada. 2. Ó devolver una fila de tabla (RECORD)

7) Procedimientos almacenados utilizados por disparadores que se ejecutan DESPUES de ejecutar el comando SQL que lo lanzó, ignoran el valor de retorno, así que pueden retornar NULL.

8) En resumen, independientemente de como se defina un disparador, el procedimiento almacenado utilizado por dicho disparador tiene que devolver o bien NULL, o bien un valor RECORD con la misma estructura que la tabla que lanzó dicho disparador.

9) Si una tabla tiene más de un disparador definido para un mismo evento (INSERT,UPDATE,DELETE), estos se ejecutarán en orden alfabético por elnombre del disparador. En el caso de disparadores del tipo ANTES / row-level, la fila retornada por cada disparador, se convierte en la entrada del siguiente. Si alguno de ellos retorna NULL, la operación será anulada para la fila afectada.

10) Procedimientos almacenados utilizados por disparadores pueden ejecutar sentencias SQL que a su vez pueden activar otros disparadores.Esto se conoce como disparadores en cascada. No existe límite para el número de disparadores que se pueden llamar pero es responsabilidad del programador el evitar una recursión infinita de llamadas en la que un disparador se llame así mismo de manera recursiva.

Otra cosa a tener en cuenta es que, por cada disparador que definamos en unatabla, nuestra base de datos tendrá que ejecutar la función asociada a dichodisparador. El uso de disparadores de manera incorrecta o inefectiva puedeafectar significativamente al rendimiento de nuestra base de datos. Losusuarios principiantes deberían de usar un tiempo para entender comofuncionan y así poder hacer un uso correcto de los mismos antes de usarlos ensistemas en producción.

37

Variables especiales en PL/pgSQL al utilizar un disparador

Cuando una función escrita en PL/pgSQL es llamada por un disparador tenemosciertas variables especiales disponibles en dicha función. Estas variables sonlas siguientes:

NEW: Tipo de dato RECORD; Variable que contiene la nueva fila de la tablapara las operaciones INSERT/UPDATE en disparadores del tipo row-level. Estavariable es NULL en disparadores del tipo statement-level.

OLD: Tipo de dato RECORD; Variable que contiene la antigua fila de la tablapara las operaciones UPDATE/DELETE en disparadores del tipo row-level. Estavariable es NULL en disparadores del tipo statement-level.

TG_NAME: Tipo de dato name; variable que contiene el nombre del disparadorque está usando la función actualmente.

TG_WHEN: Tipo de dato text; una cadena de texto con el valor BEFORE oAFTER dependiendo de como el disparador que está usando la funciónactualmente ha sido definido.

TG_LEVEL: Tipo de dato text; una cadena de texto con el valor ROW oSTATEMENT dependiendo de como el disparador que está usando la funciónactualmente ha sido definido.

TG_OP: Tipo de dato text; una cadena de texto con el valor INSERT, UPDATE oDELETE dependiendo de la operación que ha activado el disparador que estáusando la función actualmente.

TG_RELID: Tipo de dato oid; el identificador de objeto de la tabla que haactivado el disparador que está usando la función actualmente.

TG_RELNAME: Tipo de dato name; el nombre de la tabla que ha activado eldisparador que está usando la función actualmente. Esta variable es obsoleta ypuede desaparacer en el futuro. Usar TG_TABLE_NAME.

TG_TABLE_NAME: Tipo de dato name; el nombre de la tabla que ha activadoel disparador que está usando la función actualmente.

TG_TABLE_SCHEMA: Tipo de dato name; el nombre del schema de la tablaque ha activado el disparador que está usando la función actualmente.

TG_NARGS: Tipo de dato integer; el número de argumentos dados alprocedimiento en la sentencia CREATE TRIGGER.

TG_ARGV[]: Tipo de dato text array; los argumentos de la sentencia CREATETRIGGER. El índice empieza a contar desde 0. Índices inválidos (menores que 0ó mayores/iguales que tg_nargs) resultan en valores nulos.

38

Utilización de :old y :new en Triggers con nivel de fila (row-level)

Un trigger o disparador con nivel de fila, se ejecuta una vez por cada filaprocesada por la orden que provoca el disparo. Dentro del disparador, puedeaccederse a la fila que está siendo actualmente procesada utilizando, para ello,dos pseudo-registros, :old y :new.

Orden de Disparo :OLD :NEW

INSERTINSERT No definido; todos los campos toman elvalor NULL.

Valores que serán insertados cuando se complete la orden

UPDATE Valores originales de la fila, antes de la actualización.

Nuevos valores que serán escritos cuando se complete la orden.

DELETE Valores originales, antes del borrado de la fila. No definido; todos los campos toman el valor NULL.

Utilización de predicados de los triggers: INSERTING, UPDATING yDELETING

Dentro de un disparador en el que se disparan distintos tipos de órdenes DML(INSERT, UPDATE y DELETE), hay tres funciones booleanas que puedenemplearse para determinar de qué operación se trata. Estos predicados sonINSERTING, UPDATING y DELETING.

Su comportamiento es el siguiente:

Predicado Comportamiento

INSERTING TRUE si la orden de disparo es INSERT; FALSE en otro caso.

UPDATINGTRUE si la orden de disparo es UPDATE; FALSE en otro caso.

DELETING TRUE si la orden de disparo es DELETE; FALSE en otro caso.

Orden de ejecución de los triggers

Una misma tabla puede tener varios triggers asociados. En tal caso esnecesario conocer el orden en el que se van a ejecutar.

Los triggers se activan al ejecutarse la sentencia SQL.

c) Si existe, se ejecuta el disparador de tipo BEFORE (disparador previo)con nivel de orden.

d) Para cada fila a la que afecte la orden: e) Se ejecuta si existe, el disparador de tipo BEFORE con nivel de fila. f) Se ejecuta la propia orden.

39

g) Se ejecuta si existe, el disparador de tipo AFTER (disparador posterior)con nivel de fila.

h) Se ejecuta, si existe, el disparador de tipo AFTER con nivel de orden.

Restricciones de los Triggers.

El cuerpo de un disparador es un bloque PL/SQL. Cualquier orden que sea legalen un bloque PL/SQL , es legal en el cuerpo de un disparador, con lassiguientes restricciones:

– Un disparador no puede emitir ninguna orden de control de transacciones(COMMIT, ROLLBACK o SAVEPOINT). El disparador se activa como parte de laejecución de la orden que provocó el disparo, y forma parte de la mismatransacción de dicha orden. Cuando la orden que provoca la orden esconfirmada o cancelada, se confirma o se cancela también el trabajo realizadopor el disparador.

– Por las mismas razones, ningún procedure o función llamado por eldisparador puede emitir órdenes de control de transacciones.

Cuando se realiza un trigger sobre una tabla, dicha tabla se dice que está en“proceso de mutación”, es decir, que se están realizando cambios sobre ellay que por tanto dentro del trigger no se debe hacer ningún tipo deacceso a dicha tabla con operaciones DML (SELECT, INSERT, DELETE oUPDATE).

Si queremos conocer los valores del registro de la tabla sobre la que se hadisparado el trigger, este último debe estar declarado de forma FOR EACH ROWy acceder a sus valores mediante las pseudo columnas :NEW y :OLD.

3.4 Herramientas de Administración de PostgreSQL

Aquí daremos un vistazo a la herramienta de administración de PostgreSQL,PgAdmin3. Esta herramienta fue utilizada en el desarrollo de la tesina, la cualsirvió de manera eficiente para las pruebas y modificaciones realizadas en labase de datos del sistema SMVE. Destacamos la gran cantidad de ayuda enlínea con la que cuenta PgAdmin3, la cual hizo que nuestro aprendizaje sobre lamisma sea más rápido.

Aquí una breve descripción sobre la misma.

40

PgAdmin3:Es un entorno de escritorio visual. Instalable en plataformas Linux, FreeBSD,Solaris, Mac OSX y Windows. Permite conectarse a bases de datos PostgreSQLque estén ejecutándose en cualquier plataforma.

Facilita la gestión y administración de bases de datos ya sea medianteinstrucciones SQL o con ayuda de un entorno gráfico. Permite acceder a todaslas funcionalidades de la base de datos; consulta, manipulación y gestión dedatos.

PgAccess: Entorno de escritorio visual.

PhpPgAdmin: Entorno web.

Psql: Cliente de consola. Database Master: Entorno de escritorio visual.

3.5 Mecanismos de Notificación en Postrges: LISTEN/NOTIFY (Notificaciones Real-time)

Postgres nos ofrece las funciones LISTEN, UNLISTEN y NOTIFY que nosfacilitan el envío de notificaciones asíncronas a todos los procesosconectados a la base de datos.

Son mecanismos para notificar cambios hacia el exterior.

• Asegura transaccionalidad

• sólo se dispara al momento de hacer COMMIT.

• sólo si la transacción ha sido exitosa.

Gracias a estas funciones podemos crear un sistema de datos que se mantienesincronizado en todos nuestros clientes de forma asíncrona y nos da un grancontrol sobre el proceso.

LISTEN: Recibe aviso de notificación de una condición [11].

Synopsis:

LISTEN nombre

Entradas:

41

Nombre: Nombre de la condición de notificación.

Salidas:

LISTEN: Mensaje devuelto cuando se completa exitosamente el registro.

Descripción:

LISTEN registra al backend Postgres para recibir aviso de la notificación de unacondición nombre.

Cada vez que el comando NOTIFY nombre es invocado, ya sea por estebackend u otro conectado a la misma base de datos, todos los backends queestán registrados para ser avisados de la notificación de esa condición, recibenel aviso y en su momento cada uno de ellos notificará a su aplicación frontend.

Un backend puede anular su registro de recepción de aviso de una condiciónde notificación dada a través del comando UNLISTEN. Asimismo, todos losregistros de recepción de avisos se anulan automáticamente cuando finaliza elproceso backend.

El método mediante el cual la aplicación frontend detecta los eventos denotificación depende de la interfaz de programación de aplicaciones Postgresutilizada. Con la librería básica libpq, la aplicación envía LISTEN como uncomando SQL ordinario, y entonces llama periódicamente a la rutina PQnotifiespara averiguar si se ha recibido algún evento de notificación. Otras interfacescomo libpgtcl proporcionan métodos de alto nivel para el manejo de eventos denotificación; de hecho, con libpgtcl el programador de aplicaciones no debeenviar LISTEN o UNLISTEN directamente.

NOTIFY: Señala todos los "frontends" y "backends" a la escucha de unacondición notify [10].

Sinopsis:

NOTIFY name

Entradas:

Notifyname Notifica la condición a ser señalada.

Salidas:

NOTIFY Acuse de recibo de que el comando notify ha sido ejecutado.

42

Eventos Notify

Los eventos son repartidos a los “frontend” que están a la escucha; el cómo y si cada aplicación “frontend” reacciona depende de su programación.

Descripción:

El comando NOTIFY envía un evento notify a cada aplicación frontend quepreviamente ha ejecutado LISTEN notifyname para la condición notifyespecífica en la base de datos en curso.

La información pasada al "frontend" para un evento notify incluye el nombre dela condición notify y el PID de la notificación del proceso "backend". Es asuntodel diseñador de la base de datos el definir los nombres de las condiciones queserán usadas en una base de datos dada y que significa cada una.

Comúnmente, el nombre de una condición notify es el mismo que el de algunatabla en la base de datos, y el evento notify esencialmente significa "Hecambiado ésta tabla, échale un vistazo para ver los cambios". Pero dichaasociación no es obligada por lo comandos NOTIFY y LISTEN. Por ejemplo, undiseñador de bases de datos podría usar varios nombres de condicióndiferentes para señalar diferentes tipos de cambios en una misma tabla.

Cuando se usa NOTIFY para señalar la ocurrencia de cambios en una tabla enparticular, una técnica útil de programación es poner NOTIFY en una normaque es disparada por actualizaciones de la tabla. De esta manera, lanotificación es automática cuando la tabla cambia, y el programador de laaplicación no puede olvidarse de ello de forma accidental.

NOTIFY interactúa con transacciones SQL de una manera importante. Primero,si se ejecuta un NOTIFY dentro de una transacción, lo eventos notify no sonrepartidos hasta y a menos que la transacción se haya hecho. Esto esadecuado, dado que si una transacción se aborta nos gustaría que todos loscomandos dentro de ella no hubieran tenido efecto, incluyendo NOTIFY. Peropuede ser desconcertante si uno está esperando que los eventos notify serepartan inmediatamente. Segundo, si un "backend" a la escucha recibe unaseñal notify mientras está en una transacción, el evento notify no se repartiráal "frontend" conectado hasta justo después de que la transacción se hayacompletado (tanto si se ejecuta como si se aborta). De nuevo, la razón es quesi un notify fuera repartido dentro de una transacción que después fueabortado, sería deseable que la notificación se deshiciera de alguna manera,pero el "backend" no puede echar marcha atrás un notify una vez que ha sido

43

enviado al "frontend". Por tanto los eventos notify son sólo repartidos entretransacciones. El resultado de esto es que las aplicaciones que usan NOTIFYpara señalar en tiempo real deberían tratar de mantener cortas sustransacciones.

NOTIFY se comporta como las señales Unix en un aspecto importante: si unamisma condición es señalada varias veces en una sucesión rápida, losreceptores puede que sólo recibieran un evento notify para varias ejecucionesde NOTIFY. Por ello es mala idea depender del número de notificacionesrecibidas. En cambio, usaremos NOTIFY para "despertar" a las aplicacionesque necesitan prestar atención a algo, y usaremos un objeto de base de datos(tal como una secuencia) para mantener un registro de lo que ha ocurrido ocuantas veces ha ocurrido.

Es usual para un "frontend" que envía NOTIFY estar él mismo a la escucha delmismo nombre notify. En ese caso recibirá un evento notify , justo igual que losotros "frontends" a la escucha. Dependiendo de la lógica de la aplicación, estopodría acarrear un trabajo inútil, por ejemplo, releyendo una tabla de una basede datos para encontrar la misma actualización que ése mismo frontendacababa de escribir. En Postgres 6.4 y posteriores , es posible evitar dichotrabajo extra notificando si el PID del proceso de notificación del "backend"(suministrado en el mensaje del evento notify) es el mismo que el PID delbackend de uno mismo (valga la redundancia) (disponible en libpq). Cuandoson el mismo, el evento notificación es la recuperación del propio trabajo deuno mismo, y puede ser ignorado. (A pesar de lo que se dijo en el párrafoprecedente, esto es una técnica segura. Postgres mantiene las auto-notificaciones separadas de las notificaciones que llegan de otros "backends",de manera que no puedes perder una notificación de fuera por ignorar tuspropias notificaciones.)

3.6 Diseño y definición de la base de datos del proyecto SMVE

En el diseño de la base de datos del sistema SVME las tablas y las relaciones entre las mismas que se destacan, y valen la pena mencionar en esta tesis, para que el lector comprenda el contexto en el que se trabajó son:

Tablas

mara_ai = Es la tabla donde se resguardan los elementos de entradaanalógicos, de las señales provenientes de las estaciones de energía.

44

mara_di = Es la tabla donde se resguardan los elementos que emiten señalesdigitales provenientes de las estaciones de energía.

hmi_svgelement = Cada elemento de esta tabla representa un objeto en elgráfico SVG de las estaciones. Cada uno tiene un nombre y un tag con el cualse hace referencia. Cada elemento tiene diferentes atributos que vancambiando según el tipo de elemento. Los gráficos SVG de la página web senutren de ésta tabla.

hmi_formula = Como su nombre lo indica, cada elemento de ésta tabla indicacómo se calcula y modifica cada uno de los elementos de la tablahmi_svgelement. Cada fórmula indica como cambia un atributo de un elementográfico en particular.

La confección de cada fórmula se realizo con mucho cuidado ya que setuvieron que tener en cuenta en muchos casos para aplicar una coloración a unobjeto, el estado de un elemento gráfico anterior, viendo su dependencia en elesquema unifilar.

Problemas detectados y soluciones propuestas

En el proyecto SMVE el comportamiento de la base de datos era por demásdinámico. Los registros de las tablas mara_ai y mara_di se actualizanconstantemente dado que en ellas se registran los estados provenientes decampo, según como los elementos del circuito eléctrico modifican susvariables.

Por este motivo la tabla hmi_svgelement se actualizaba constantemente. Y elacceso a la tabla de fórmulas para tomar conocimiento de cómo seactualizaban las mismas también era muy recurrente. Cada vez que unelemento modificaba su valor, se ejecutaban todas las fórmulas y seactualizaban todos los elementos correspondientes a los resultados en la tablahmi_svgelement. Esto generaba un gran número de accesos a la base dedatos, sumándose la actualización innecesaria de valores de elementos que nohabían sido modificados.

Detectamos que se podía mejorar la performance de los accesos a la base dedatos implementando la combinación de dos de las herramientas que nosbrinda PostgreSql: El uso de Triggers y el uso de notificaciones asíncronascomo son Notify / listen.

La solución consiste en:

- Implementar un trigger en cada una de las tablas mara_ai, mara_di, yhmi_svgelement, que al momento en que dichas tablas se actualicen condatos provenientes de los elementos de campo, provoquen una reacciónen cadena de actualizaciones de otros elementos de la misma u otratabla, según sus dependencias (ésto se ve en las fórmulas de cadaelemento).

45

- Dentro de cada trigger creamos canales de comunicación entre la BDD yun proceso que será el encargado actualizar los elementos dependientesdel mismo, ejecutando las fórmulas en que el elemento actualizadoparticipe. Esta comunicación se logró utilizando la herramienta decomunicación Notify.

Detallaremos a continuación lo implementado dentro de la base de datospostgresql, dejando para el próximo capítulo el detalle de implementación delproceso que escucha del otro lado del canal de comunicación. Solomencionaremos que dicho proceso recibe la notificación de que un elemento esactualizado y se encarga de hacer update en las tablas que correspondan. Lamanera en que lo hace se detallará en el capítulo 4 (programación reactiva).

Figura 9: Esquema de actualización y notificación de eventos.

Triggers implementados

Cada trigger implementado verifica cuál de los atributos de su tabla es el que cambió e informa a través de Notify los cambios al canal de comunicación con el proceso de escucha.

Trigger de ejecución en tabla de eventos analógicos llamada mara_ai:

CREATE OR REPLACE FUNCTION update_ai() RETURNS trigger AS$BODY$DECLAREBEGIN if (NEW.value <> OLD.value) THEN PERFORM pg_notify('canal_smve', 'ai.' || NEW.tag || '.value '|| NEW.value);END IF;if (NEW.q <> OLD.q) THEN PERFORM pg_notify('canal_smve', 'ai.' || NEW.tag || '.q ' || NEW.q);END IF;if (NEW.escala <> OLD.escala) THEN

46

Canal de comunicación

Update DB

Base de Datos Proceso FrontEnd

PERFORM pg_notify('canal_smve', 'ai.' || NEW.tag || '.escala ' || NEW.escala);END IF;RETURN NEW;END;$BODY$ LANGUAGE plpgsql VOLATILE COST 100;ALTER FUNCTION update_ai() OWNER TO postgres;

Trigger de ejecución en tabla de eventos analógicos llamada mara_di:

CREATE OR REPLACE FUNCTION update_di() RETURNS trigger AS$BODY$DECLAREBEGIN if (NEW.value <> OLD.value) THEN PERFORM pg_notify('canal_smve', 'di.' || NEW.tag || '.value '|| NEW.value); END IF; RETURN NEW;END;$BODY$ LANGUAGE plpgsql VOLATILE COST 100;ALTER FUNCTION update_di() OWNER TO postgres;

Trigger de ejecución en tabla donde se almacenan los elementos y propiedades gráficas hmi_svgelement:

CREATE OR REPLACE FUNCTION update_svg() RETURNS trigger AS$BODY$DECLAREBEGINif (NEW.text <> OLD.text) AND ((NEW.text = '1') OR (NEW.text = '0')) THEN PERFORM pg_notify('canal_smve', 'eg.' || NEW.tag || '.text ' || NEW.text);END IF;if (NEW.fill <> OLD.fill) THEN PERFORM pg_notify('canal_smve', 'eg.' || NEW.tag || '.fill '|| NEW.fill);END IF;

if (NEW.stroke <> OLD.stroke) THEN PERFORM pg_notify('canal_smve', 'eg.' || NEW.tag || '.stroke ' || NEW.stroke);

47

END IF;

RETURN NEW;END;

Dentro del código de los trigger se observa la comparación del dato Nuevoentrante y el dato Viejo (old) que se va a actualizar en la tabla.

Si estas dos variables son iguales, el trigger no envía ninguna notificación,porque de hecho nada cambió. Sólo se enviarán notificaciones cuando el valornuevo de la variable sea distinto al valor contenido en la base.

Con ésta implementación logramos comunicar cuál es la actualización que serealizó en cada dato en estas tablas. También se da información de quéatributo es el que se modificó y cuál es su nuevo valor. Con esta información, elproceso FrontEnd puede identificar cuáles son los demás elementos de la basede datos que se deberán actualizar. Al solo comunicar éste dato, la cantidad deaccesos a la base de datos se reducen, ya que se pasa de recorrer toda la tablade fórmulas para ejecutarlas y actualizar todos los elementos de las tablas, asolo consultar las fórmulas correspondientes a los elementos que cambiaron suvalor.

3.7 Conclusiones

Hemos visto que PostgreSQL posee una potencialidad muy grande para el usode bases de datos relacionales brindando estabilidad y robustez.

Observamos que es el único motor de bases de datos que posee funciones quenos facilitan el envío de notificaciones asíncronas hacia el exterior, a todos losprocesos conectados con la base de datos lo que nos permitió tener un controlsobre los cambios y actualizaciones generadas por eventos producidos en lassubestaciones transformadoras del sistema. Ésto ayudó mucho a obtenermayor fluidez y eficiencia en la respuesta que el sistema debe brindar entiempo real y que precisa un sistema SCADA como el que hemos trabajado enesta tesis.

48

CAPÍTULO 4: Programación Reactiva.

4.1 Resumen

En el capítulo anterior vimos como desde la base de datos, se informa a travésde herramientas postrgresql a una aplicación frontend, los eventos que vansucediendo y modificando la misma. En este capítulo veremos como se atrapanesas notificaciones y que acciones se realizan a posteriori. Haremos una introducción al patrón de diseño Observer, en el cuál tiene susfundamentos la programación reactiva, para luego centrarnos en este nuevoparadigma.

Daremos un detalle de la aplicación frontend y su implementación en ellenguaje Python.

Concluiremos con una comparación entre lo que se realizaba con anterioridaden el proyecto SMVE y lo propuesto en esta tesina.

4.2 Introducción - Patrón de diseño Observer

“Es un patrón de diseño que define una dependencia del tipo uno-a-muchosentre objetos, de manera que cuando uno de los objetos cambia su estado,notifica este cambio a todos los dependientes. Se trata de un patrón decomportamiento (existen de 3 tipos: Creación, Estructurales y deComportamiento), es decir, está relacionado con algoritmos de funcionamientoy asignación de responsabilidades a clases y objetos. Los patrones decomportamiento describen no solamente estructuras de relación entre objetoso clases, sino también esquemas de comunicación entre ellos y se puedenclasificar en función de que trabajen con clases (Método Plantilla) uobjetos(Cadena de Responsabilidad, Comando, Iterador, Recuerdo,Observador, Estado, Estrategia, Visitante). "

Estructura

Figura 10: Estructura del patrón Observador.

49

Básicamente debemos saber que el patrón Observer es un patrón decomportamiento que permite relacionar diferentes objetos entre si en torno auno Principal, así cada vez que este último cambie su estado, los demástambién cambiarán en forma automática. Podemos decir que éste patrón secompone de un objeto observable u observado y objetos observadores.

Un Objeto Observable puede tener uno o mas Observadores. El Observadorinforma sobre los cambios a los objetos observables mediante algún método.Éste patrón de diseño también es conocido como Publicador – Subscriptor.

Dependencias.

La motivación del patrón de diseño Observer es la de mantener unaconsistencia entre objetos relacionados, pero sin aumentar el acoplamientoentre clases.

Aplicabilidad.

La aplicabilidad del patrón puede pensarse cuando un objeto debe ser capaz denotificar algo a otros sin hacer suposiciones sobre quiénes son dichos objetos.Esto es, cuando se quiere bajo acoplamiento. También cuando cambiar unobjeto implicar cambiar otros, pero no sabemos exactamente cuántos hay quecambiar.

Características

• Permite modificar sujetos y observadores de manera independiente.

• Permite reutilizar un sujeto sin reutilizar sus observadores, y viceversa.

• Permite añadir observadores sin tener que cambiar el sujeto ni losdemás observadores.

• Acoplamiento abstracto entre el sujeto y el observador. El sujeto nosabe la clase concreta de sus observadores (acoplamiento mínimo).

• Soporte para broadcast. El sujeto envía la notificación a todos losobservadores suscritos. Se pueden añadir/quitar observadores.

• Actualizaciones inesperadas. Una operación en el sujeto puededesencadenar una cascada de cambios en sus observadores.

El patrón de diseño Observer es clave del patrón de arquitectura Model View Control (MVC), como así también en la Programación Reactiva, de la cual a continuación daremos una referencia.

4.3 Programación Reactiva

Definición: “La programación reactiva es un paradigma deprogramación orientado a flujos de datos y a la propagación decambios.”

50

Vivimos en un entorno tremendamente cambiante donde los requerimientos delas aplicaciones varían constantemente. Hace unos pocos años una aplicacióngrande tenía decenas de servidores, con tiempos de respuesta en segundos ygigabytes de datos. Hoy en día las aplicaciones están desplegadas en todo tipode dispositivos, desde móviles a clusters basados en la nube, que corren conmiles de procesadores multinúcleo. En el lado del cliente, la rápida proliferaciónde los teléfonos inteligentes y el auge de la llamada “Internet de las cosas”incrementan el número de usuarios concurrentes y se espera que los sistemassean capaces de soportarlo y manejarlo adecuadamente [17].

Los usuarios en la actualidad esperan que los tiempos de respuesta sean demilisegundos o microsegundos y de un 100% de disponibilidad. La necesidadde almacenamiento de datos está creciendo considerablemente expandiéndosehacia los petabytes.

En este contexto se espera que nuestras aplicaciones sean “reactivas”, esdecir tener componentes activos y listos para recibir eventos.

Características de una aplicación reactiva:

Dirigida por Eventos: Permitir el procesamiento paralelo , asíncrono demensajes y eventos con facilidad.

Escalable: Poder escalar dentro y a través de los nodos elásticamentepara proporcionar potencia de computación bajo demanda cuando seanecesario .

Resistente: La capacidad para recuperarse y repararse a sí mismo deforma automática con el fin de asegurar la continuidad aplicación sinfallas.

Sensible: Respuestas en tiempo real que proporcionen informacióninstantánea sobre la base de las interacciones del usuario y de otrosestímulos.

Es evidente que debemos considerar usar nuevas tecnologías y nuevosparadigmas de programación para poder satisfacer estos niveles desofisticación para poder tener aplicaciones reactivas. Los sistemas construidoscomo sistemas reactivos son más flexibles, de acoplamiento flexible yescalable. Esto hace que sean más fáciles de desarrollar y susceptibles decambio. Ellos son significativamente más tolerantes al fracaso.

Los Sistemas reactivos son muy sensibles, dando a los usuariosretroalimentación interactiva eficaz.

51

Los Sistemas Reactivos se centran en ofrecer tiempos de respuesta rápidos yconsistentes, estableciendo límites superiores fiables por lo que ofrecen unacalidad de servicio consistente. Este comportamiento consistente a su vez,simplifica el manejo de errores, aumenta la confianza del usuario final, yalienta una mayor interacción.

Un ejemplo práctico

Imaginemos un contexto de programación secuencial tradicional.

Como vemos, una vez asignamos el valor de la variable ‘a’ como una suma de‘b’ más ‘c’, se evalúa esa suma. Y aunque cambiemos el valor de ‘b’ o ‘c’, elvalor de ‘a’ ya ha sido evaluado y sigue siendo el mismo que la primera vez(12).

La programación reactiva propone un comportamiento diferente. Algoparecido a una tabla de excel donde nosotros asignamos a la celda ‘A1′ paraque calcule el valor de ‘B1′ más ‘C1′. Aquí, si cambiamos el valor de la columna‘B1′ o ‘C1′ el valor de ‘A1′ se actualiza (evalúa) automáticamente.

La palabra reactiva hace referencia a la reacción, al comportamiento que va arealizar nuestra aplicación en base a un dato y a partir de los cambiosrealizados en este dato, cambia también el comportamiento. Esto quiere decirque nos centramos en que los componentes reaccionen bien al usuario y querespondan a las interacciones que hace con el sistema.

Los datos que utilizamos en nuestras aplicaciones pueden ser muy variadosdesde un flujo de datos desde un archivo local, de una página web,notificaciones del sistema o hasta una serie de eventos tales como entradasdel usuario. En la programación reactiva se representan todos estos datoscomo secuencias de observables y la aplicación puede suscribirse a estassecuencias para recibir notificaciones a medida que llegan nuevos datos.

52