Cosme Xavier Gálvez Sánchez - Repositorio Digital ...
200
UNIVERSIDAD NACIONAL DE LOJA FACULTAD DE LA ENERGÍA, LAS INDUSTRIAS Y LOS RECURSOS NATURALES NO RENOVABLES CARRERA DE INGENIERÍA EN ELECTRÓNICA Y TELECOMUNICACIONES Autor: Cosme Xavier Gálvez Sánchez Director: Ing. Ángel José Ordóñez Mendieta, Mg. Sc. Loja - Ecuador 2019 TESIS DE GRADO PREVIA A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN ELECTRÓNICA Y TELECOMUNICACIONES.
-
Upload
khangminh22 -
Category
Documents
-
view
4 -
download
0
Transcript of Cosme Xavier Gálvez Sánchez - Repositorio Digital ...
UNIVERSIDAD NACIONAL DE LOJA
FACULTAD DE LA ENERGÍA, LAS INDUSTRIAS Y LOS RECURSOS
NATURALES NO RENOVABLES
CARRERA DE INGENIERÍA EN ELECTRÓNICA Y
TELECOMUNICACIONES
Autor:
Cosme Xavier Gálvez Sánchez Director:
Ing. Ángel José Ordóñez Mendieta, Mg. Sc.
Loja - Ecuador
2019
TESIS DE GRADO PREVIA A LA OBTENCIÓN
DEL TÍTULO DE INGENIERO EN
ELECTRÓNICA Y TELECOMUNICACIONES.
II
CERTIFICACIÓN
Ing. Ángel José Ordóñez Mendieta, Mg. Sc.
DIRECTOR DE TESIS
CERTIFICA:
Haber dirigido, asesorado, revisado y corregido el presente trabajo de tesis de grado, en
su proceso de investigación, cuyo tema versa en “DISEÑO E IMPLEMENTACIÓN
DE UN SISTEMA DE MONITOREO EN TIEMPO REAL DE LOS
PARÁMETROS DE VARIABLES ELECTRO ENERGÉTICAS DE LOS
EQUIPOS DE CONTROL Y RESPALDO DE ENERGÍA ELÉCTRICA DEL
SISTEMA INTEGRADO DE SEGURIDAD ECU 911 LOJA”, previa a la obtención
del título de Ingeniero en Electrónica y Telecomunicaciones, realizado por el señor
egresado: Cosme Xavier Gálvez Sánchez, la misma que cumple con la reglamentación
y políticas de investigación, por lo que autorizo su presentación y posterior sustentación
y defensa.
Loja, 10 de junio de 2019
Ing. Ángel José Ordóñez Mendieta Mg. Sc
DIRECTOR DEL TRABAJO DE TESIS
III
AUTORÍA
Yo, COSME XAVIER GÁLVEZ SÁNCHEZ, declaro ser autor del presente trabajo de
tesis y eximo expresamente a la Universidad Nacional de Loja y a sus representantes
jurídicos de posibles reclamos o acciones legales, por el contenido de la misma.
Adicionalmente acepto y autorizo a la Universidad Nacional de Loja, la publicación de
mi tesis en el Repositorio Institucional – Biblioteca Virtual.
Firma: ………………………….
Cédula: 1105442261
Fecha: 26/07/2019
IV
CARTA DE AUTORIZACIÓN DE TESIS POR PARTE DEL AUTOR, PARA LA
CONSULTA, REPRODUCCIÓN PARCIAL O TOTAL Y PUBLICACIÓN
ELECTRÓNICA DEL TEXTO COMPLETO.
Yo, COSME XAVIER GÁLVEZ SÁNCHEZ declaro ser autor de la tesis titulada:
“DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE MONITOREO EN
TIEMPO REAL DE LOS PARÁMETROS DE VARIABLES ELECTRO
ENERGÉTICAS DE LOS EQUIPOS DE CONTROL Y RESPALDO DE
ENERGÍA ELÉCTRICA DEL SISTEMA INTEGRADO DE SEGURIDAD ECU
911 LOJA”, como requisito para obtener el grado de INGENIERO EN
ELECTRÓNICA Y TELECOMUNICACIONES; autorizo al Sistema Bibliotecario de
la Universidad Nacional de Loja para que con fines académicos, muestre al mundo la
producción intelectual de la Universidad, a través de la visibilidad de su contenido de la
siguiente manera en el Repositorio Digital Institucional:
Los usuarios pueden consultar el contenido de este trabajo en RDI, en redes de
información del país y del exterior, con las cuales tenga convenio la Universidad.
La Universidad Nacional de Loja, no se responsabiliza por el plagio o copia de la tesis
que realice un tercero.
Para constancia de esta autorización, en la ciudad de Loja a los veinte y seis días del mes
de julio del dos mil diecinueve.
Firma: ________________________
Autor: Cosme Xavier Gálvez Sánchez.
Cédula: 1105442261
Dirección: Loja (Av. Eloy Alfaro y La Condamine)
Correo electrónico: [email protected]
Teléfono: 07-2112080 Celular: 0982896583
Director de Tesis: Ing. Ángel José Ordóñez Mendieta Mg. Sc
Tribunal de Grado: Ing. Manuel Augusto Pesantez González. Mg. Sc.
Ing. Christian Campoverde Ramírez. Mg. Sc.
Ing. Kleber Morillo Aguilar. Mg. Sc.
V
DEDICATORIA
A Dios
Por darme la vida y estar siempre conmigo,
guiándome en mi camino.
A mis Padres
El esfuerzo y las metas alcanzadas, refleja la
dedicación y el amor que invierten los padres en sus
hijos. Gracias a mis padres soy quien soy,
orgullosamente dedico este trabajo de investigación
a Cosme Dumani Gálvez Sánchez y Anita Mariela
Sánchez Ávila, mi mayor inspiración, gracias a
ellos he concluido con una de mis mayores metas.
A mis hermanas
Britney y Daniela, gracias por no solo ayudarme en
gran manera a concluir el desarrollo de esta tesis,
sino por todos los bonitos momentos que pasamos
en el proceso.
A mi abuelita
Puedo decir plenamente que eres además de mi
abuela, mi segunda madre, y los valores y los
aportes que has realizado para mi vida son
simplemente invaluables. Gracias por tus
enseñanzas pude superar con toda clase de
obstáculos en mi vida.
A mis seres queridos
Familia, amigos, y personas especiales en mi vida.
No podría sentirme más ameno con la confianza
puesta sobre mi persona, especialmente cuando he
contado con su mejor apoyo desde el comienzo de
este largo camino. Quisiera dedicar mi tesis a
ustedes, personas de bien, seres que ofrecen amor,
bienestar, y los finos deleites de la vida.
Cosme Xavier Gálvez Sánchez
VI
AGRADECIMIENTO
Agradezco profundamente al personal que
conforma el Departamento de Dirección
Tecnológica del SIS ECU 911 Loja, especialmente
al Ing. Juan Pablo Cabrera Samaniego, por sus
grandes aportes y compromiso, que el día de hoy se
ve reflejado en la culminación exitosa de mi
proyecto de tesis.
Quiero expresar mi total agradecimiento a la
Universidad Nacional de Loja y a la Carrera de
Ingeniería en Electrónica y Telecomunicaciones,
por brindarme una excelente formación académica.
Agradezco de manera especial al Ing. Ángel José
Ordóñez Mendieta, por su compromiso con el
presente proyecto de tesis, y por supuesto, por su
excelente trabajo como guía de esta investigación
hasta su finalización
Gracias a Dios por permitirme tener y disfrutar a
mi familia, gracias a mi familia por apoyarme en
cada decisión y proyecto, por permitirme cumplir
con excelencia en el desarrollo de esta tesis.
Gracias por creer en mí y gracias a Dios por
permitirme vivir y disfrutar de cada día.
A todos mis compañeros y amigos, les agradezco, y
hago presente mi gran afecto hacia ustedes, por
estar presentes durante la realización y el
desarrollo de esta tesis, gracias a ustedes que con
respeto y decencia realizaron aportes a este
trabajo, gracias a todos y espero que estos lazos de
amistad, perdure siempre en el tiempo.
VII
ÍNDICE DE CONTENIDOS
CERTIFICACIÓN ............................................................................................................ II
AUTORÍA ...................................................................................................................... III
CARTA DE AUTORIZACIÓN ..................................................................................... IV
DEDICATORIA ...............................................................................................................V
AGRADECIMIENTO .................................................................................................... VI
ÍNDICE DE CONTENIDOS ......................................................................................... VII
ÍNDICE DE FIGURAS .................................................................................................. XI
ÍNDICE DE TABLAS ................................................................................................... XV
1. TÍTULO .................................................................................................................... 1
2. RESUMEN .............................................................................................................. 2
3. INTRODUCCIÓN .................................................................................................... 4
4. REVISIÓN DE LITERATURA ............................................................................... 6
4.1. Sistemas de Control Industrial ........................................................................... 6
4.1.1. Clasificación de Sistemas de Control Industrial ......................................... 7
4.1.2. Sistemas de Control de Supervisión y Adquisión de Datos ..................... 10
4.1.3. Red de Comunicación Industrial .............................................................. 15
4.1.4. Sistema de Gestión de Bases de Datos ..................................................... 15
4.1.5. Sistemas de Visualización de Datos: Interfaces Hombre Máquina (HMI:
Human Machine Interface). .................................................................................... 16
4.1.6. Estándares de Interfaz de Comunicación Aplicados en la Industria ........ 17
4.1.7. Protocolos de Comunicación Aplicados a la Industria ............................. 23
4.2. Desarrollo de Aplicaciones HMI ..................................................................... 35
4.2.1. Software de Desarrollo de Sistemas HMI/SCADA .................................. 35
4.2.2. Funciones del Software de Desarrollo de Sistemas HMI/SCADA .......... 36
4.2.3. Python ....................................................................................................... 37
VIII
4.2.4. Qt .............................................................................................................. 44
4.2.5. Sistemas de Gestión de Base de Datos ..................................................... 46
4.2.6. Elastic Stack (Interfaz Web) ..................................................................... 51
4.3. Ubicación de los Equipos de la Planta Electro-Energética. ............................. 54
4.3.1. Cuarto de Generadores ............................................................................. 58
4.3.2. Cuarto de Distribución Eléctrica .............................................................. 60
4.3.3. Cuarto de Energía Regular ....................................................................... 61
4.3.4. Equipos de Control de Suministro y Respaldo de Energía Eléctrica ....... 62
5. MATERIALES Y MÉTODOS ............................................................................... 83
5.1. Materiales ......................................................................................................... 83
5.2. Métodos............................................................................................................ 84
6. RESULTADOS ...................................................................................................... 87
6.1. Diseño .............................................................................................................. 88
6.1.1. Hardware de Adquisión de Datos: Unidades de Terminal Remota. ......... 88
6.1.2. Red de Comunicación Industrial: Infraestructura de Comunicación. ....... 88
6.1.3. Sistema de Visualización Local de Datos................................................. 91
6.1.4. Almacenamiento de la Información. ...................................................... 109
6.1.5. Sistema de Visualización Remota de Datos: Interfaz Web. ................... 110
6.2. Implementación del Sistema de Monitoreo. .................................................. 114
6.3. Funcionamiento Integral del Sistema de Monitoreo. ..................................... 117
6.3.1. Validación de los Datos Obtenidos con el Software de Monitoreo. ....... 121
7. DISCUSIÓN ......................................................................................................... 125
8. CONCLUSIONES ................................................................................................ 131
9. RECOMENDACIONES ...................................................................................... 133
10. BIBLIOGRAFÍA ............................................................................................... 135
11. ANEXOS ........................................................................................................... 138
IX
11.1. Anexo 1: Manual de usuario del Analizador de Red DUCA-LCD96. ....... 139
11.1.1. Características Técnicas. ..................................................................... 139
11.1.2. Conexiones. ......................................................................................... 144
11.1.3. Funcionamiento................................................................................... 148
11.2. Anexo 2: Manual de Operación Sistema de Control e Instrumentación DSE
Series 7200 / 7300. ................................................................................................... 152
11.2.1. Especificaciones. ................................................................................. 152
11.2.2. Instalación. .......................................................................................... 157
11.2.3. Descripción de Controles: Puerto Serial. ............................................ 160
11.2.4. PIN de Seguridad. ............................................................................... 162
11.3. Anexo 3: Datasheet EATON 9390. ............................................................ 163
11.3.1. Opciones de conectividad del UPS EATON 9390. ............................ 163
11.3.2. Especificaciones técnicas. ................................................................... 164
11.3.3. Eaton Power Xpert Gateway (PXGX) UPS Card: Guía de Usuario. .. 165
11.4. Anexo 4: Especificaciones generales del protocolo Modbus - RTU Rev. 12.
(Mach Smart/Smart Più/ Duca47(-72)-SP/Duca-LCD/ Duca-LCD96). ................... 168
11.5. Anexo 5: Protocolo de comunicaciones GenComm para uso con 550, 555,
5210 y 5220 controladores (DSE7320). ................................................................... 173
11.6. Anexo 6: Mapa de registros Modbus TCP del UPS EATON 9390. .......... 178
11.7. Anexo Digital 7: Código fuente del controlador DUCA-LCD96
“duca_lcd_96.py”. .................................................................................................... 179
11.8. Anexo Digital 8: Código fuente del controlador DSE7320 “dse7320.py”. 179
11.9. Anexo Digital 9: Código fuente del controlador UPS9390 “ups_ecu.py”. 179
11.10. Anexo Digital 10: Código fuente de la clase “Dialogo_Correo”. .............. 179
11.11. Anexo Digital 11: Código fuente de la clase “Dialogo_DB”..................... 179
11.12. Anexo Digital 12: Código fuente de la clase “Dialogo_alarmas”. ............. 179
11.13. Anexo Digital 13: Código fuente de la clase “Dialodo_ConfigScada”. .... 179
X
11.14. Anexo Digital 14: Código fuente de la clase “Ventana”. ........................... 179
11.15. Anexo 15: Guía de Usuario del Software de Monitoreo del Sistema Eléctrico
del SIS ECU 911 Loja. ............................................................................................. 180
11.16. Anexo 16: Certificado de Funcionamiento del Sistema de Propuesto. ...... 184
XI
ÍNDICE DE FIGURAS
Figura 1. Tipos de Sistemas de Control Industrial. ......................................................... 7
Figura 2. Arquitectura Centralizada. ............................................................................... 8
Figura 3. Esquema de Control Industrial Distribuido. .................................................... 9
Figura 4. Arquitectura interna de un autómata programable. ........................................ 14
Figura 5. Ciclo de funcionamiento de un Autómata...................................................... 14
Figura 6. Transmisor y Receptor Diferencial. ............................................................... 21
Figura 7. Modos de transmisión del estándar de interfaz RS-485. ................................ 22
Figura 8. Bus de Configuración Half-Dúplex RS-485. ................................................. 22
Figura 9. Bus de Comunicación Full-Dúplex RS-485................................................... 23
Figura 10. Arquitectura de Modbus según el modelo OSI. ........................................... 25
Figura 11. Formato de las tramas Modbus. ................................................................... 26
Figura 12. Petición de solicitud de lectura de datos Modbus. ....................................... 27
Figura 13. Petición de escritura simple de valor binario. .............................................. 27
Figura 14. Petición de escritura de múltiples valores binarios. ..................................... 27
Figura 15. Petición de escritura simple de registros. ..................................................... 27
Figura 16. Petición de escritura de múltiples de registros. ............................................ 27
Figura 17. Modelo de direcciones Modbus. .................................................................. 29
Figura 18. Diagrama de flujo de una transacción Modbus en el lado del servidor. ...... 30
Figura 19. LA ADU de TCP/IP. .................................................................................... 32
Figura 20. La ADU de RTU. ......................................................................................... 33
Figura 21. La ADU de ASCII........................................................................................ 33
Figura 22. Entornos de Desarrollo Integrado IDE......................................................... 39
Figura 23. Mapa del paquete pyModbusTCP. ............................................................... 42
Figura 24. Características de Qt. ................................................................................... 44
Figura 25. Interfaz gráfica de la herramienta Qt Designer. ........................................... 45
Figura 26. Productos de la Pila Elastic. ......................................................................... 51
Figura 27. Ubicación geográfica del SIS ECU 911 Loja. ............................................. 54
Figura 28. Planta Baja del SIS ECU 911 Loja. ............................................................. 55
Figura 29. Diagrama Unifilar del Sistema Eléctrico del SIS ECU 911 Loja. ............... 56
Figura 30. Simbología del Diagrama Unifilar del Sistema Eléctrico del SIS ECU 911
Loja. ................................................................................................................................ 57
XII
Figura 31. Cuarto de Generadores. ................................................................................ 58
Figura 32. Generador 1 de operaciones controlado por el módulo DSE7320. .............. 59
Figura 33. Generador 2 controlado por el módulo DSE7320. ....................................... 59
Figura 34. Cuarto de Distribución Eléctrica del SIS ECU911 Loja. ............................. 60
Figura 35. Analizadores de red DUCA-LCD96 485-RELÉ del cuarto de distribución
eléctrica del ECU911 Loja. ............................................................................................ 61
Figura 36. UPS EATON 9390 del cuarto de energía regular del SIS ECU911 Loja. ... 62
Figura 37. Paneles de control de los UPS EATON 9390. a) UPS 1 se encuentra en estado
activo; b) UPS 2 se encuentra en estado Stand-by. ........................................................ 62
Figura 38. Analizador de red DUCA-LCD96. .............................................................. 63
Figura 39. Dimensiones del dispositivo DUCA-LCD96. .............................................. 64
Figura 40. Duca-LCD96 (vista posterior). .................................................................... 66
Figura 41. Conexión de la salida RS485 (BSAT) del Duca-LCD96. ............................ 66
Figura 42. Ventana principal del software WinSmart – Ducati Energía. ...................... 69
Figura 43. Ventana de configuración del WinSmart – Ducati Energía. ........................ 69
Figura 44. Módulo DSE7320. ....................................................................................... 70
Figura 45. Dimensiones del módulo DSE7320. ............................................................ 72
Figura 46. Modelos de la serie DSE7000. ..................................................................... 72
Figura 47. Terminales del módulo DSE7320. ............................................................... 73
Figura 48. Software DSE Configuration Suite. ............................................................. 77
Figura 49. EATON9390 UPS de 100-160 kVA. ........................................................... 78
Figura 50. Tarjeta de comunicación de UPS Power Xpert® Gateway. ........................ 80
Figura 51. Modelo del proceso incremental para el desarrollo de software. ................. 85
Figura 52. Esquema de la Estructura Funcional de los Sistemas SCADA. ................... 87
Figura 53. Implementación del sistema de monitoreo en tiempo real de las variables
electro-energéticas del SIS ECU911 Loja. ..................................................................... 88
Figura 54. STM485-C. Convertidor pasivo RS-232 a RS-485. .................................... 90
Figura 55. Esquema general de conexión física del sistema de monitoreo. .................. 91
Figura 56. Diagrama de flujo del controlador DSE7320. .............................................. 93
Figura 57. Diagrama de flujo del controlador DucaLCD96 485-RELÉ. ...................... 94
Figura 58. Diagrama de flujo del controlador del Eaton9390 UPS. .............................. 95
XIII
Figura 59. Esquema de la GUI del software de monitoreo del sistema eléctrico del ECU
911 Loja: Ventana secundaria de “configuración general del sistema”. ....................... 96
Figura 60. Esquema de la GUI del software de monitoreo del sistema eléctrico del ECU
911 Loja: Ventana secundaria de “configuración de la base de datos”. ....................... 97
Figura 61. Esquema de la GUI del software de monitoreo del sistema eléctrico del ECU
911 Loja: Ventana secundaria de “configuración de alertas”......................................... 97
Figura 62. Esquema de la GUI del software de monitoreo del sistema eléctrico del ECU
911 Loja: Ventana secundaria de “configuración del correo de alerta”. ...................... 97
Figura 63. Esquema de la GUI del software de monitoreo del sistema eléctrico del ECU
911 Loja: Ventana principal del “sistema de monitoreo del sistema eléctrico del ECU 911
Loja”. .............................................................................................................................. 98
Figura 64. Ventana principal del software de monitoreo del sistema electro-energético
del SIS ECU911 Loja. .................................................................................................... 98
Figura 65. Ventana secundaria de configuración general del software de monitoreo... 99
Figura 66. Ventana secundaria de configuración de la conexión a la base de datos. .. 100
Figura 67. Ventana secundaria de configuración de alertas. ....................................... 100
Figura 68. Ventana secundaria de configuración del correo de alerta. ....................... 101
Figura 69. Código fuente de la ventana principal del software de monitoreo escrito en
Python. .......................................................................................................................... 102
Figura 70. Diagrama de flujo de la clase Dialogo_Correo. ......................................... 104
Figura 71. Diagrama de flujo de la clase Dalogo_DB................................................. 105
Figura 72. Diagrama de flujo de la clase Dialogo_alarmas......................................... 106
Figura 73. Diagrama de flujo de la clase Dialogo_Scada. .......................................... 107
Figura 74. Diagrama de flujo de la clase Ventana....................................................... 108
Figura 75. Diagrama de gestión de información mediante pila ELK para la creación de
la interfaz web. ............................................................................................................. 110
Figura 76. Funcionamiento de la herramienta Logstash. ............................................ 111
Figura 77. Configuración del tipo de visualización para presentación de las variables
electro-energéticas. ....................................................................................................... 113
Figura 78. Configuración del Goal para la presentación de los datos mediante Kibana.
...................................................................................................................................... 114
Figura 79. Conexión de los módulos DSE7320 del generador 1 y 2. ......................... 114
XIV
Figura 80. Conexión de los tableros de medición DucaLCD96 485-RELÉ................ 115
Figura 81. Configuración exitosa de la conexión a la base de datos. .......................... 115
Figura 82. Configuración exitosa de las Alertas del sistema de monitoreo. ............... 115
Figura 83. Configuración exitosa del correo de alerta. ............................................... 116
Figura 84. Configuración exitosa de los equipos de control y respaldo de energía eléctrica
del ECU 911 Loja. ........................................................................................................ 116
Figura 85. Esquema general del funcionamiento del sistema de monitoreo de los equipos
de control y respaldo de energía eléctrica del ECU 911 Loja. ..................................... 117
Figura 86. Lectura de variables electro-energéticas obtenidas con el software de
monitoreo en tiempo real. ............................................................................................. 120
Figura 87. Datos almacenados en la base de datos PostgreSQL. ................................ 120
Figura 88. Interfaz Web desarrollada en Kibana. ........................................................ 121
XV
ÍNDICE DE TABLAS
Tabla 1: Niveles de voltaje del receptor en el estándar de comunicación RS-232…….17
Tabla 2: Distribución de pines conectores DB9 y DB25. ............................................. 18
Tabla 3: Topología y ventajas de protocolos de comunicación industriales. ................ 24
Tabla 4: Modelo de datos en el protocolo Modbus. ...................................................... 28
Tabla 5: Códigos de función publicos Modbus ............................................................. 31
Tabla 6: Funciones ModbusTCP.Client de la librería pyModbusTCP….……………..43
Tabla 7: Gestores de base de datos ................................................................................ 48
Tabla 8: Funciones de PostgreSQL ............................................................................... 50
Tabla 9: Especificaciones Técnicas de los Generadores 1 y 2 ...................................... 60
Tabla 10: Modelos del Duca-LCD96 ............................................................................ 65
Tabla 11: Interfaz de comunicación RS485 del DUCA-LCD96 485-RELÉ ................ 65
Tabla 12: Variables Electro-Energéticas del DUCA-LCD96 485-RELÉ ..................... 66
Tabla 13: Modelos de la serie DSE7000. ...................................................................... 72
Tabla 14: Interfaz y protocolos de comunicación soportados por el módulo DSE7320.
........................................................................................................................................ 73
Tabla 15: Descripción de las terminales RS485 y RS232 del DSE7320 ...................... 74
Tabla 16: Variables Electro-Energéticas del módulo DSE7320 ................................... 75
Tabla 17: Valores de Centinela del módulo DSE7320 .................................................. 75
Tabla 18: Especificaciones técnicas del EATON 9390 UPS. ....................................... 78
Tabla 19: Dimensiones y peso del EATON 9390 UPS. ................................................ 79
Tabla 20: Interfaz y protocolos de comunicaciones del EATON 9390 UPS ................ 79
Tabla 21: Variables Electro-Energéticas del EATON 9390 UPS ................................. 80
Tabla 22: Estados de las Alarmas y Test del EATON 9390 UPS. ................................ 81
Tabla 23: Tabla de verificación y validación de los datos obtenidos con el software de
monitoreo. ....................................................................................................................... 83
Tabla 24: Configuración de las interfaces y protocolos de comunicación de los módulos
DSE7320 y los tableros DUCALCD96 .......................................................................... 89
Tabla 25: Clases declaradas para el funcionamiento del software de monitoreo. ....... 103
Tabla 26: Validación de los datos obtenidos de los analizadores de red DucaLCD96.
...................................................................................................................................... 121
Tabla 27: Validación de los datos obtenidos de los módulos DSE7320. .................... 123
XVI
Tabla 28: Validación de los datos obtenidos de los UPS Eaton9390 .......................... 124
1
1. TÍTULO
“DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE
MONITOREO EN TIEMPO REAL DE LOS PARÁMETROS
DE VARIABLES ELECTRO ENERGÉTICAS DE LOS
EQUIPOS DE CONTROL Y RESPALDO DE ENERGÍA
ELÉCTRICA DEL SISTEMA INTEGRADO DE SEGURIDAD
ECU 911 LOJA.”
2
2. RESUMEN
El presente proyecto de investigación tiene como finalidad el desarrollo de un sistema de
monitoreo en tiempo real, que permita visualizar los parámetros electro-energéticos de la
red eléctrica interna del edificio ECU 911 Loja.
El sistema eléctrico del ECU 911 Loja, se encuentra actualmente integrado con equipos
de control y respaldo de energía eléctrica, los cuales se encargan de la supervisión y
control de dicho sistema. La propuesta de esta tesis, dispone desarrollar un software que
permita acceder a las variables electro-energéticas medidas por estos equipos, a través de
una interfaz humano-máquina o HMI, por sus siglas en inglés human machine-interface.
La presente tesis, inicia con un breve estudio de los sistemas de monitoreo y control
utilizados en la industria, más conocidos como sistemas SCADA, por sus siglas en inglés
Supervisory Control And Data Acquisition, adquiriendo así los conocimientos para
diseñar e implementar el sistema de monitoreo propuesto. Luego, se procede a la
recopilación de información del campo de trabajo, así como de los que equipos que
intervienen en él. Finalmente, haciendo uso de herramientas de software libre, que se
detallan más adelante, se desarrolla e implementa el sistema de monitoreo del cual versa
el presente proyecto.
3
ABSTRACT
The purpose of this research project is to develop a real-time monitoring system that
allows visualizing the electro-energetic parameters of the internal electrical network of
the SIS ECU 911 Loja building.
The electrical system of the ECU 911 Loja, is currently integrated with electric power
control and backup equipment, which is in charge of the supervision and control of said
system. The proposal of this thesis, has to develop a software that allows access to the
electro-energetic variables measured by these equipments, through a human-machine
interface or HMI, by its acronym in English human machine-interface.
This thesis begins with a brief study of the monitoring and control systems used in the
industry, better known as SCADA systems, by acquiring the knowledge to design and
implement the proposed monitoring system. Then, it proceeds to the collection of
information from the work field, as well as the equipment that intervenes in it. Finally,
making use of free software tools, which are detailed below, the monitoring system is
developed and implemented, which deals with the present project.
4
3. INTRODUCCIÓN
El Sistema Integrado de Seguridad ECU 911 tiene como objetivo primordial el brindar a
las autoridades una herramienta tecnológica que les permita integrar todos los recursos
dedicados a la seguridad pública y prestación de servicios a la comunidad. De este modo,
se le ofrece a la sociedad un método sencillo y eficiente para canalizar sus situaciones de
emergencia. En este sentido y con la premisa de cumplir dicho objetivo primordial, es de
particular importancia que la tecnología provista permita procesar de manera eficiente
todos y cada uno de los eventos implicados en una situación de emergencia.
Por esta razón los sistemas de control y respaldo de energía eléctrica de toda la
infraestructura tecnológica es parte fundamental en la prestación y aseguramiento de los
servicios antes mencionados. Sin embargo, hasta el momento no cuentan con un sistema
de monitoreo en tiempo real las veinticuatro horas del día los trecientos sesenta y cinco
días del año de los parámetros electro-energéticos de la red eléctrica que alimenta al SIS
ECU 911 Loja y ya que, en la actualidad la energía eléctrica encara una creciente demanda
y, cada vez más estrés en la red de suministro es propenso a ocasionar un aumento
importante en las caídas de tensión y en los daños ocasionados por problemas eléctricos.
Es así como los problemas más frecuentes relacionados con la distribución eléctrica son
transitorios de tensión, ruido eléctrico, altibajos de voltaje y apagones, pueden afectar de
manera muy perjudicial a todos los sistemas que conforman el Sistema Integrado de
Seguridad ECU 911 LOJA si no existe una adecuada y eficaz respuesta por parte de los
equipos de control y respaldo del suministro eléctrico.
Para poder lograr aquello es de fundamental importancia que el suministro eléctrico del
SIS ECU 911 Loja nunca se vea interrumpido bajo ninguna circunstancia y se mantenga
operativo el mayor tiempo posible y en óptimas condiciones, de tal forma los equipos
electro-energéticos encargados de supervisar y controlar el suministro eléctrico deben ser
monitoreados constantemente y en tiempo real para determinar su estado y correcto
funcionamiento. Los equipos electro-energéticos se dividen en cuatro grupos: el grupo de
corriente alterna, el de corriente directa, sistema puesta a tierra y el de climatización.
Dentro del grupo de corriente alterna, se encuentra un subgrupo llamado grupo
electrógeno, que se refiere al sistema de la planta de emergencia, en el cual se centrará el
desarrollo de este proyecto. Este subgrupo está constituido por generadores de corriente
5
alterna, sistemas de alimentación ininterrupible y un grupo de sistemas auxiliares. Este
grupo es una fuente de energía de respaldo que entra a funcionar en caso de que falle la
red de distribución pública de energía eléctrica.
6
4. REVISIÓN DE LITERATURA
CAPÍTULO 1: SISTEMAS DE CONTROL Y PROTOCOLOS DE
COMUNICACIÓN INDUSTRIAL
4.1. Sistemas de Control Industrial
La función primordial de la automatización industrial a través de los sistemas control, se
basan en regir la actividad y la evolución de los procesos industriales sin la intervención
continua de un operador humano.
En los últimos años, se han desarrollado los sistemas de control y adquisión de datos
denominados SCADA, por sus siglas en inglés (Supervisor Control & Data Adquisition),
los cuales permiten supervisar y controlar, las distintas variables que se encuentran en un
proceso o planta determinada. Para ello, se deben utilizar distintos periféricos, software
de aplicación, unidades terminales remotas (UTR), y sistemas de comunicación, los
cuales permiten al operador (mediante la visualización en una pantalla de computador)
tener el completo acceso al proceso (Suarez Pinzon, 2015).
Con la evolución de estos sistemas, se puede supervisar el proceso y tener acceso al
historial de las alarmas y variables de medición y control con mayor eficacia y claridad,
además, se puede agregar bases de datos relacionadas y representar toda esta información
en un computador de forma gráfica, ya sea de forma local o desde cualquier lugar a través
de la red, siendo así todo el sistema más amigable.
Gracias a los avances en la electrónica y la informática, aparece en los años 80 los
controladores lógicos programables o PLC, por sus siglas en inglés (Programmable Logic
Controller) que permiten realizar controles modulares que se adaptan a las necesidades
del momento, provistos de sistemas de programación, lo que resulto en un éxito en el
ámbito industrial. En la década siguiente surge una versión de Visual Basic que permite
crear con facilidad, controles gráficos e interfaces de usuario (Suarez Pinzon, 2015).
Las modernas tecnologías de comunicación, fueron modificando las arquitecturas de las
redes de automatización, llegando hasta las actuales arquitecturas híbridas que combinan
redes cableadas e inalámbricas. Estos sistemas como ya se mencionó anteriormente
permiten en cualquier momento y en cualquier lugar, conocer el estado del proceso con
solo contar con un computador y conexión a la red.
7
4.1.1. Clasificación de Sistemas de Control Industrial
Podemos nombrar tres tipos de sistemas de control industrial según su topología, la cual
define la disposición de los diferentes equipos alrededor del medio de transmisión de
datos, determinando una estructura de red característica. Estos tres tipos son: control
centralizado, control híbrido y control distribuido. Para determinar qué tipo de sistema de
control se debe aplicar a un proceso en concreto debemos tener en cuenta algunas de las
características del proceso, las cuales pueden ser: la importancia de las tareas a realizar,
la posibilidad de subdividir la tarea de control del proceso o conjunto de máquinas en
funciones autónomas, entre otras (Toledo Torres & Urgilés Cárdenas, 2017). En la Figura
1, se observa los tipos de sistemas de control industrial anteriormente citados.
Figura 1. Tipos de Sistemas de Control Industrial.
Fuente: Autor.
4.1.1.1. Control Centralizado
Este tipo de control es usado en el caso de sistemas poco complejos donde los procesos
pueden ser gestionados mediante un único elemento de control encargado de realizar
todas las tareas del proceso de producción y que puede incluir un sistema de
monitorización y supervisión. A medida que las necesidades de producción requieren
mayor complejidad, la tendencia ha sido emplear elementos de control más complejos y
potentes, manteniendo un único elemento de control en todo el proceso.
8
Figura 2. Arquitectura Centralizada.
Fuente: Autor.
En la Figura 2, se indica la arquitectura centralizada de este tipo de sistemas de control.
La ventaja principal de esta metodología es que no se necesita planificar un sistema de
intercomunicación entre procesos, ya que todas las señales están gestionadas por el
mismo sistema. Así mismo, el sistema tiene varias desventajas, ya que si el sistema
principal falla, se paralizan todas las comunicaciones, esto se podría resolver con un
sistema redundante. También es necesario el empleo de unidades de control
(generalmente autómatas programables) de mayor capacidad de proceso dada la
complejidad de los problemas que debe abordar y con las restricciones de tiempo límite
que son habituales en los procesos industriales debido a la sincronización necesaria;
pueden existir problemas de tiempos de ciclo en el caso de procesos muy complejos. Por
último, el cableado aumenta notablemente debido a las distancias que existen entre los
sensores, actuadores y la unidad de control, este problema se puede simplificar de cierta
forma con el uso de buses de campo (Toledo Torres & Urgilés Cárdenas, 2017).
4.1.1.2. Control Distribuido
El control distribuido requiere que puedan considerarse procesos, grupos de procesos o
áreas funcionales, susceptibles de ser definidas por un algoritmo de control que pueda
realizarse de forma autómata. Cada unidad contará con un elemento de control (o
autómata) de acuerdo con los requerimientos del proceso. Debido a la interdependencia
que existe entre las operaciones, es necesario, interconectar los elementos de control entre
sí, mediante entradas y salidas digitales o, a través de una red de comunicaciones para
intercambio de datos y estados, por lo tanto, el elemento de control debe permitir las
Controlador
Actuador
Actuador
Sensor
Sensor
9
comunicaciones. En la Figura 3, se muestra el esquema de un control industrial
distribuido.
Figura 3. Esquema de Control Industrial Distribuido.
Fuente: (RM Automatizacion, 2018).
Con esta metodología de control, es posible que cada unidad funcional consista en un
proceso relativamente sencillo comparado con el proceso global, reduciendo la
posibilidad de errores en la programación y permitiendo el empleo de unidades de control
más sencillas, y, por lo tanto, más económicas. Si existiera un fallo en las diferentes
unidades de control, no implicaría que el proceso global deba detenerse ni tampoco
interrumpir los otros procesos. La desventaja de esta metodología es, que se necesita
realizar un estudio de implantación previo, ya que se deben identificar los procesos
autónomos, asignar elementos a cada proceso y diseñar el modelo de intercomunicación
para responder a las necesidades del proceso planteado (Toledo Torres & Urgilés
Cárdenas, 2017).
4.1.1.3. Control Híbrido
El control híbrido no está muy bien definido, ya que, este tipo de gestión puede
considerarse a la estrategia de distribución de elementos de control que esté en medio del
control distribuido y el control centralizado. En ciertas ocasiones no es sencillo separar
los procesos de manera completamente autónoma, por lo que, se debe recurrir a la gestión
de varios procesos desde una misma unidad de control, pues la complejidad de la
separación, es mayor que la complejidad que supone su gestión continua.
Una estrategia de este tipo también conduce a una gestión estructurada, de modo que,
existen elementos de control de nivel superior que supervisan e intercomunican los
procesos autónomos más sencillos, siendo los encargados de gestionar la información.
10
Para este tipo de gestión, también, es necesario el uso de redes de comunicación (Toledo
Torres & Urgilés Cárdenas, 2017).
4.1.2. Sistemas de Control de Supervisión y Adquisión de Datos
Los sistemas SCADA, basan su funcionamiento en la combinación de la telemetría
(medición remota de magnitudes físicas), con la adquisición de datos. Estos sistemas
abarcan una colección de información a través de las UTR, transfiriéndola a un servidor
central, realizando el análisis y control necesario, para luego desplegar la información en
un número de pantallas de operación o despliegues. Las acciones de control son
transmitidas de vuelta hacia el proceso que se esté supervisando (Moya Calderón, 2009).
4.1.2.1. Antecedentes y Evolución de los Sistemas SCADA
En sus inicios, los primeros sistemas SCADA solo se configuraban para transmitir el
estado de determinadas variables y condiciones de la planta, sin realizar ninguna actividad
de control sobre el proceso. Además, se presentaban los datos en paneles de control
industrial, usando señales visuales. La capacidad de control y supervisión de estos
sistemas eran limitadas. Sin embargo, con el desarrollo tecnológico de los años
posteriores, fueron los ordenadores y hardware específico los encargados del
almacenamiento y adquisición de los datos de la planta. Estos ordenadores incorporan
comandos de control, así como, la función de presentar los datos de la planta en tiempo
real y de manera visual en el ordenador. Finalmente, mientras la velocidad de
procesamiento de información de los ordenadores aumentaba, de la misma manera
aumentó la capacidad de programar el sistema para que realice funciones de control.
4.1.2.2. Características Generales de los Sistemas SCADA
Entre las principales características de los sistemas SCADA tenemos:
• Emplean computadores y protocolos de comunicación industrial para automatizar
el monitoreo y control de diversos procesos industriales.
• Permiten obtener la representación de los datos de una planta en tiempo real.
Actualmente, los sistemas SCADA tienen la capacidad de ejecutar algoritmos de
control que modifican la respuesta de la planta.
• Fueron desarrollados para sustituir sistemas de control obsoletos en industrias.
11
• Permiten optimizar la energía utilizada en el proceso.
• Constituyen una ventana del proceso. Permiten conocer el estado actual del
mismo.
• Permiten maximizar la producción.
• Buscan reducir los costos de personal.
• A partir de los sistemas SCADA, se pueden realizar análisis basados en datos
actuales y pasados, gracias a la gran capacidad de almacenamiento que poseen.
4.1.2.3. Características Operativas de los Sistemas SCADA
Los sistemas SCADA en la actualidad se están convirtiendo en parte integral de la
estructura de gerenciamiento de información corporativa de la industria, dado que a través
de estos sistemas se adquiere la información necesaria para la toma de decisiones, por lo
que constituyen más que una herramienta operacional. Por lo tanto, los sistemas SCADA
constituyen el núcleo de la parte operacional de la planta, pero a su vez, presentan datos
a los sistemas o usuarios fuera del ambiente del operador. Estos datos se usan para tomar
decisiones, por lo que, es necesario que los mismos sean confiables y seguros.
4.1.2.4. Estructura Funcional de los Sistemas SCADA
Los sistemas SCADA son estructurados de manera que se garanticen en todos sus niveles
escalabilidad, seguridad, fiabilidad y rendimiento óptimo del sistema. Como resultado,
estos sistemas han sido divididos en los siguientes bloques funcionales:
• Hardware de adquisición de datos (UTR’s, PLC’s).
• Red de comunicación industrial (Modbus RTU, Profibus).
• Sistema de gestión de datos.
• Software HMI/SCADA.
Hardware de Adquisición de Datos
Un sistema SCADA presenta un número determinado de unidades terminales remotas o
controladores lógicos programables, adquiriendo los datos provenientes de los elementos
de campo(sensores), y enviándolos al servidor central a través del sistema de
comunicación (Moya Calderón, 2009).
12
Los elementos de campo permiten conocer en cada instante de tiempo, el estado del
sistema o proceso. Es decir, proveen la información necesaria al operador para determinar
el estado actual y las condiciones operativas del sistema o proceso que se esté
supervisando. En conclusión, los elementos de campo son todos los sensores y actuadores
que adquieren los datos y actúan sobre el sistema.
a) Unidades Terminales Remotas (UTR)
Para que los elementos de campo puedan enviar los datos hacia el servidor SCADA, es
necesario, que se envíen a través de un sistema de comunicación compatible. Para que se
logre enviar la información en el formato correcto, se usa las UTR’s (unidades terminales
remotas), que proveen la interfaz necesaria. Las UTR’s son usadas fundamentalmente
para convertir las señales electrónicas recibidas por un elemento de campo (por ejemplo,
una señal de 4 a 20 mA), a un lenguaje o protocolo de comunicación (por ejemplo:
Modbus); y así lograr la transmisión adecuada de los datos obtenidos por los elementos
de campo (Moya Calderón, 2009).
Las Unidades Terminales Remotas de un sistema SCADA, son equipos ubicados en el
campo, los cual se encargan de procesar la información y de la interacción entre el
servidor SCADA y los distintos elementos de campo (Sensores, Actuadores). Las UTR’s
son unidades independientes, encargadas de la adquisición de datos y en la actualidad,
también poseen la capacidad de realizar algoritmos de control.
Características de la UTR
• Tienen una unidad de procesamiento y en ocasiones unidad de procesamiento de
respaldo.
• Poseen una memoria de programa, datos y de acceso aleatorio.
• Dispone de puertos de comunicación (Serial, Ethernet, etc).
• Contienen una fuente de alimentación y en ocasiones fuente de alimentación de
respaldo.
• Presentan diversas protecciones necesarias para garantizar el funcionamiento
correcto y confiable de la UTR.
• Cuentan con un driver para la comunicación con el servidor SCADA (Por
ejemplo: Driver Modbus).
13
Operación de la UTR
La Unidad Terminal Remota, se encarga de escanear sus entradas, cada cierto tiempo,
definido como el tiempo de acceso o adquisición. Puede realizar ciertas operaciones, que
incluyen el procesamiento de los datos adquiridos, o el cambio de estado de una
determinada variable. Generalmente utilizan la forma de comunicación pedido/respuesta,
es decir, el servidor SCADA es el que inicia la comunicación para la obtención de un
determinado valor. Ciertas UTR’s, en la actualidad, contienen dentro de su programación
algoritmos de control, y procesamiento de alarmas, tal como un PLC, por lo que, en
ocasiones la nomenclatura es intercambiable.
b) Autómatas Programables
“Un autómata programable o PLC, es un equipo electrónico diseñado para ser utilizado
en un entorno industrial y destinado al control de procesos industriales con un hardware
independiente del proceso a controlar. Dicho hardware se adapta al proceso mediante
un programa (software), que contiene las instrucciones a realizar. Esta secuencia de
operaciones se define sobre una serie de entradas-salidas cableadas directamente al
autómata y con las que este interactúa con el proceso” (Cerezuela Martínez, 2014). Es
decir, un autómata programable es un dispositivo electrónico cuya función principal es
controlar diversos procesos de forma autónoma para los cuales fue programado.
Estructura de un autómata programable
En la actualidad, existen infinidad de equipos en el mercado de diferentes fabricantes;
pero, en cuanto a al hardware que los conforman, se da por hecho que un autómata consta
básicamente, de los siguientes bloques:
• Unidad central de proceso (CPU)
• Memorias internas
• Memoria de programa
• Interfaces de entrada/salida
• Fuente de alimentación
En la siguiente Figura 4, se presenta la arquitectura interna de un autómata
programable.
14
Figura 4. Arquitectura interna de un autómata programable.
Fuente: Autor.
Ciclo de funcionamiento de un Autómata
Los autómatas programables son máquinas que ejecutan las instrucciones de sus
programas de forma secuencial, generan las señales de salida dirigidas al proceso a partir
de las señales de entrada que reciben del mismo. Esta secuencia puede dividirse en tres
ciclos de funcionamiento, como se detalla en la Figura 5.
Figura 5. Ciclo de funcionamiento de un Autómata.
Fuente: Autor.
Lectura de las señales de entrada
Procesado o ejecución del programa para la
obtención de las señales de salida
Escritura de señales de salida
15
c) Sensores y actuadores
“Se utiliza la palabra sensor para definir al dispositivo o elemento que convierte una
variable física no eléctrica en otra eléctrica, que en alguno de sus parámetros (nivel de
tensión, nivel de corriente, frecuencia, etc.), contiene información correspondiente a la
primera” (Cerezuela Martínez, 2014).
Para que en un entorno industrial el sistema de automatización pueda funcionar, necesita
conocer el valor de numerosas variables físicas, que en su gran mayoría no son eléctricas.
Es necesario, por lo tanto, la utilización de elementos que conviertan dichas variables en
señales eléctricas proporcionales en alguna de sus características, como tensión, corriente
o frecuencia.
4.1.3. Red de Comunicación Industrial
La red de comunicación industrial otorga los medios mediante los cuales, los datos son
transmitidos entre el sistema SCADA y las UTR’s ubicadas en el campo. La red de
comunicación industrial, se refiere al equipo necesario para transferir datos desde y hacia
diferentes lugares. Los medios usados pueden ser cable, radio, entre otros. El cable como
medio de propagación de datos es el más usado a nivel industrial; sin embargo, cuando el
sistema cubre grandes áreas geográficas no es recomendable. Durante los últimos años,
los sistemas SCADA han aumentado el uso de las redes LAN y WAN, para el desarrollo
de redes de computadores (Moya Calderón, 2009).
En la sección 4.1.6 y 4.1.7, se entrará en más detalle acerca de los modos de transmisión
de datos y protocolos de comunicación industrial.
4.1.4. Sistema de Gestión de Bases de Datos
En los sistemas SCADA actuales existe cada vez más una mayor demanda de datos. Esto
se debe a que estos sistemas hoy en día, no solo controlan la operatividad del proceso,
sino también, son usados para tomar decisiones tanto operativas como administrativas.
Como resultado, los sistemas actuales deben tener la capacidad de acceso y
administración de los datos del proceso, no solo a nivel de planta, sino también a nivel
administrativo. Los sistemas de gestión de bases de datos en los procesos industriales
tienen su origen en carpetas y fichas en las que se almacenaban los datos de manera
16
manual (un operador tomaba los datos que presentaban los instrumentos analógicos
ubicados en el campo en un determinado intervalo de tiempo). En la actualidad los
sistemas de gestión de bases de datos son sistemas de información integrales (almacenan
y administran la información de un proceso), esto debido a la necesidad de gestionar las
acciones que realiza una determinada industria. (Moya Calderón, 2009).
En la sección 4.2.5, se entrará en más detalle acerca de los sistemas de gestión de bases
de datos.
4.1.5. Sistemas de Visualización de Datos: Interfaces Hombre Máquina (HMI:
Human Machine Interface).
La interfaz HMI puede describirse como una ventana o una descripción gráfica de un
proceso. Esta interfaz recibe las señales de las variables involucradas en un proceso a
través de un servidor o grupo de servidores SCADA, los cuales se encargan de la
obtención y almacenamiento de los datos provenientes de los dispositivos de campo
(Moya Calderón, 2009).
Las aplicaciones HMI presentan las siguientes funciones:
• Monitorear el proceso: La HMI tiene la capacidad de obtener y mostrar datos de
las variables de un determinado proceso en tiempo real. La presentación de estos
datos puede ser mediante gráficas, texto, o valores numéricos.
• Generar históricos y gráficas de tendencia: La HMI permite mostrar gráficas
del comportamiento pasado de la planta, y así verificar las condiciones operativas
del proceso en cualquier instante de tiempo. Además, tiene la capacidad de
generar gráficas en tiempo real, para verificar el comportamiento de una
determinada variable del proceso.
• Mostrar alarmas y generar reportes: La aplicación HMI muestra gráficamente
(mediante tablas y señales visuales) alarmas generadas por condiciones fuera de
los rangos preestablecidos de las variables del proceso o por errores dentro del
sistema. Además, presentan al operador reportes del comportamiento del sistema,
resaltando eventos importantes encontrados (Moya Calderón, 2009).
17
4.1.6. Estándares de Interfaz de Comunicación Aplicados en la Industria
Los estándares de interfaces de comunicación más comúnmente usados a nivel industrial
son:
• Estándar de Interfaz EIA-232 (Serial).
• Estándar de Interfaz EIA-422.
• Estándar de Interfaz EIA-485.
4.1.6.1. EIA/TIA-232
El estándar de comunicación serial RS-232C define la interfaz entre un equipo terminal
de datos DTE (por sus siglas en inglés Data Terminal Equipment) y un equipo de
comunicación de datos DCE (por sus siglas en inglés Data Communication Equipment)
empleando un intercambio de datos binarios de manera serial (Moya Calderón, 2009).
El estándar RS-232 está compuesto de tres componentes, los cuales definen:
• Las características eléctricas de las señales: Definen los niveles de voltaje y la
referencia entre las señales que se intercambian y sus circuitos asociados.
• Las características mecánicas de la interface entre el DTE y el DCE.
• La descripción funcional de los circuitos de intercambio de información, por
ejemplo, las señales de control de flujo, la función de los datos, y el tiempo de
transmisión y recepción usado en la interfaz entre el DTE y el DCE.
El estándar de comunicación serial RS-232 está diseñado como un sistema de
comunicación entre dos dispositivos conocidos como:
• DTE: Equipo terminal de datos.
• DCE: Equipo de comunicación de datos
Estos dispositivos entienden datos binarios (1 o 0) definidos mediante rangos de voltaje,
observe la Tabla 1: (Moya Calderón, 2009).
Tabla 1:
Niveles de voltaje del receptor en el estándar de comunicación RS-232.
Nivel Lógico Rango de Voltajes
0 lógico De +3V a +25V
1 lógico De -3V a -25V
No definido De +3V a -3V
Fuente: (Moya Calderón, 2009)
18
Para que la transmisión sea efectiva, se debe generar una señal de voltaje en el rango de
+5V a +25V y entre -5V a -25V, esto debido a que el nivel de voltaje puede entrar en la
zona no definida debido a la atenuación de la señal provocada por pérdidas. Por ejemplo,
el circuito Integrado Max 232 opera con valores de +7 V y -7 V.
a) Características Mecánicas de la Interfaz
Aunque, no se especifica en el estándar de Comunicación Serial RS-232, los conectores
DB-25 y DB- 9 han sido popularmente asociados de manera cercana con el estándar RS-
232 (Moya Calderón, 2009). En la Tabla 2:, se presenta la distribución de los pines más
importantes en los dos tipos de conectores.
Tabla 2:
Distribución de pines conectores DB9 y DB25.
DB-9 DB-25
PIN Descripción PIN Descripción
1 DCD: Detector de Transmisión 1 Shield: Protección
2 RXD: Recibir datos 2 TXD: Transmitir Datos
3 TXD: Transmitir Datos 3 RXD: Recibir Datos
4 DTR: Terminal de datos listo 4 RTS: Permiso para transmitir
5 GND: Señal de Tierra (Común) 5 CTS: Libre para enviar
6 DSR: Conjunto de datos listo 6 DSR: Conjunto de datos listo
7 RTS: Permiso para transmitir 7 GND: Señal de Tierra (Común)
8 CTS: Libre para enviar 8 DCD: Detector de Transmisión
9 RI: Indicador de llamada 20 DTR: Terminal de datos listo
22 RI: Indicador de llamada
Fuente: (Moya Calderón, 2009).
b) Desventajas del estándar de Comunicación serial RS-232
El estándar de comunicación serial RS-232 presenta ciertas desventajas entre las cuales
tenemos:
• La interfaz de comunicación RS-232 solo permite comunicación punto a punto,
lo cual es un problema cuando se tienen varios dispositivos y se quiere generar
una red con los mismos.
• La interfaz de comunicación RS-232 tiene una limitación de distancia
(generalmente 50 metros), lo cual es un problema cuando los dispositivos están
separados por distancias mayores.
• La velocidad de transmisión para la interfaz de comunicación RS-232 (por
ejemplo:19200 bps), es demasiado lenta para diversas aplicaciones.
19
• El estándar presenta alta susceptibilidad al ruido, ya que se trata de un estándar
no balanceado.
Todas estas desventajas han obligado a los diseñadores de sistemas de comunicación a
buscar alternativas, como, por ejemplo: los estándares RS-422, RS-485, entre otros, los
cuales superan las limitaciones antes descritas para la interfaz de comunicación RS-232
(Moya Calderón, 2009).
4.1.6.2. EIA/TIA-422
La norma EIA/TIA-422 está soportado sobre una interfaz equilibrada diferencial que
especifica un único controlador unidireccional y hasta 32 receptores. Teóricamente el
estándar EIA/TIA-422 permite velocidades de transmisión de hasta 10 Mbps en distancias
de hasta 12 metros (Samboya, 2012).
El EIA/TIA-422 tiene compatibilidad con el RS-232 así como con la norma EIA/TIA-
485. Los estándares RS-422 y RS-485 son mucho más compatibles con características
similares, esto es, que los dispositivos estandarizados con RS-485 pueden funcionar
correctamente con dispositivos normalizados en RS-422, sin embargo, hay una limitante
cuando se requieren utilizar dispositivos con RS-422 en redes RS-485 debido al
controlador o múltiples controladores que operan en esta última norma. (Samboya, 2012)
En la norma se definen conexiones con cable par trenzado y conectores RJ lo que produce
mayor resistencia al ruido y a la interferencia electromagnética en comparación con el
estándar RS-232. La comunicación es asíncrona en el estándar EIA/TIA-422 (Martínez,
2014).
4.1.6.3. EIA/TIA -485-A
Conocido en la industria como RS-485, el título que define oficialmente al estándar es
TIA/EIA-485-A “Características eléctricas de los generadores y receptores para uso en
sistemas multipunto digitales balanceados”. Esta norma específica las características
eléctricas de los transmisores y receptores, que pueden emplearse para el intercambio de
señales binarias en la interconexión multipunto de equipos digitales. Cuando se
implementa dentro de las pautas de este estándar, se pueden conectar múltiples
transmisores y receptores a un cable de interconexión común (Telecommunications
Industry Association, Marzo, 1998).
20
Un sistema de intercambio de señales binarias, incluye uno o más transmisores
conectados por un cable de interconexión equilibrado a uno o más receptores y
resistencias de terminación. Las características eléctricas del circuito se especifican en
términos de los valores requeridos de voltaje, corriente y resistencia obtenidos por las
mediciones en los puntos de interconexión del equipo.
Esta norma no especifica otras características, como la calidad de la señal, la
sincronización, el protocolo, las asignaciones de patillas, la tensión de alimentación, el
rango de temperatura de funcionamiento, etc; que son esenciales para el funcionamiento
correcto de los equipos interconectados. Cualquier dispositivo que cumpla con este
estándar, deberá hacerlo dentro de los rangos de los factores apropiados para la operación
del dispositivo, como los voltajes de alimentación y la temperatura ambiente. Se pretende
que este modelo sea referenciado por otras normas que especifiquen las características
adicionales necesarias para asegurar la interoperación satisfactoria del equipo.
TIA / EIA-485-A, el estándar de línea de transmisión más utilizado en la industria de las
telecomunicaciones, describe la capa física del Modelo de Referencia de Interconexión
de Sistemas Abiertos (OSI) de la interfaz RS-485 y se usa normalmente con un protocolo
de nivel superior, como Profibus, Interbus, Modbus o BACnet. Esto permite una
transmisión de datos robusta en distancias relativamente largas (Marais, 2018).
Esta norma es compatible con ISO/IEC 8482: 1993 Tecnología de la información -
Telecomunicaciones e intercambio de información entre sistemas - Interconexiones
multipunto de par trenzado (Telecommunications Industry Association, Marzo, 1998).
La característica fundamental por la que el RS-485 puede comunicarse a través de largas
distancias es el uso de líneas diferenciales o balanceadas, es decir, el voltaje en una línea
es igual a la inversa del voltaje en la otra línea. TIA / EIA-485-A designa las dos líneas
en este par diferencial como A y B. La línea A presenta un mayor voltaje que la línea B
(𝑉𝑂𝐴 > 𝑉𝑂𝐵) en la salida del controlador, si se recibe una lógica alta en la entrada del
transmisor (DI = 1). Si se recibe una baja lógica en la entrada del transmisor (DI = 0), el
transmisor hace que el voltaje en la línea B sea mayor que en la línea A(𝑉𝑂𝐵 > 𝑉𝑂𝐴),
observe la Figura 6.
21
Figura 6. Transmisor y Receptor Diferencial.
Fuente: (Marais, 2018)
Si el voltaje en la línea A es mayor que en la línea B (𝑉𝐼𝐴 − 𝑉𝐼𝐵 > 200 𝑚𝑉) en la
entrada del receptor, la salida del receptor es una lógica alta (RO = 1). Si la línea B es
mayor que la línea A (𝑉𝐼𝐵 − 𝑉𝐼𝐴 > 200 𝑚𝑉) en la entrada del receptor, la salida del
receptor es una lógica baja (RO = 0) (Marais, 2018).
La Figura 6 muestra que un circuito de interfaz de señalización diferencial consiste en un
controlador con salidas diferenciales y un receptor con entradas diferenciales. Este
circuito ha aumentado el rendimiento de ruido porque el acoplamiento de ruido en el
sistema es igual en ambas señales. Una señal emite lo contrario de la otra y los campos
electromagnéticos se cancelan entre sí. Esto reduce la interferencia electromagnética
(EMI) del sistema (Marais, 2018).
EIA-485, es básicamente, una especificación para los controladores, receptores y
transceptores conectados a la red. En concreto, un controlador debe ser capaz de generar
al menos 1.5 voltios de manera diferencial en 60 ohmios (dos terminadores de 120 ohmios
en paralelo junto con 32 cargas unitarias) en un rango de voltaje de modo común de –7 a
+12 Vcc (Marais, 2018).
Se debe tener en cuenta varios aspectos importantes al implementar redes EIA-485 como
la unidad de carga, modo de transmisión, terminación, la protección contra fallas, sesgos,
conectores, puesta a tierra, cableado y repetidores. En la Figura 7, se describe los modos
de transmisión del estándar RS-485, los demás aspectos de este estándar, no son descritos
en esta investigación debido a que no fueron relevantes para el desarrollo de este proyecto.
22
Figura 7. Modos de transmisión del estándar de interfaz RS-485.
Fuente: Autor.
Figura 8. Bus de Configuración Half-Dúplex RS-485.
Fuente: (Marais, 2018).
23
Figura 9. Bus de Comunicación Full-Dúplex RS-485.
Fuente: (Marais, 2018).
4.1.7. Protocolos de Comunicación Aplicados a la Industria
El significado de los mensajes que contiene la información dentro de un sistema SCADA,
está definido por los protocolos de comunicación industrial, que a su vez definen la forma
de detectar errores en la información que se transmite. Entre los principales protocolos de
comunicación industrial tenemos:
• Modbus
• Porfibus
• Fieldbus
• Lonworks
• Interbus
• DeviceNet
• Hart
• ControlNet
• CAN
En la Tabla 3: se indica la topología y ventajas al momento de usar cualquier protocolo
de comunicación industrial antes mencionados.
24
Tabla 3:
Topología y ventajas de protocolos de comunicación industriales.
Protocolo Topología Ventajas
Modbus
Lineal, estrella,
árbol, red con
segmentos.
Conexión sencilla a sistemas Modicon, adecuado para cantidades de
datos pequeñas (menores o iguales a 255 Bytes) y transferencia de
datos con acuse.
Profibus Lineal, estrella,
anillo.
Transmite pequeñas cantidades de datos, cubre necesidades en
tiempo real, fácil configuración.
Fieldbus Estrella. Costo de instalación y mantenimiento reducido, mejoramiento de
desempeño.
Lonworks Bus, anillo,
estrella, lazo. Diseñado para un amplio rango de aplicaciones.
Interbus Segmentado Costos reducidos de instalación, fácil detección de errores.
DeviceNet
Troncal,
puntual,
bifurcación.
Reducción en el cableado de la planta, capacidad de tener un puente
sobre las redes de un nivel más alto.
Hart Bus, lineal. Permite soportar hasta 256 variables, entrega una alternativa
económica en comunicación digital.
ControlNet Árbol, estrella,
bus.
Permite que los reguladores múltiples controles I/O en el mismo
conductor.
CAN Bus lineal. Minimiza el tiempo fuera de servicio del bus y aumenta al máximo
el uso eficaz de ancho de banda disponible.
Fuente: (Toledo Torres & Urgilés Cárdenas, 2017).
La disponibilidad y variedad de protocolos de comunicación industriales, que pueden ser
utilizados en diversos sistemas de control y supervisión, es muy amplia. De tal manera
que, en el presente proyecto se utilizó el protocolo Modbus, debido a su alta integración
en los equipos de control y adquisión de datos, como son, los equipos que integran la
planta de suministro eléctrico del SIS ECU911 Loja y forman parte del sistema de
monitoreo en tiempo real del que versa el presente proyecto, además de sus múltiples
ventajas como ser un protocolo de código abierto, su facilidad y bajo costo de
implementación. A continuación, se describe con más detalle el protocolo Modbus.
4.1.7.1. MODBUS
Modbus es un protocolo de mensajería de capa de aplicación, ubicado en el nivel 7 del
modelo OSI, que proporciona comunicación cliente/servidor o maestro/esclavo entre
dispositivos conectados en diferentes tipos de buses o redes, utilizando mensajes de
solicitud/respuesta que permiten servicios especificados por códigos de función. Los
códigos de función Modbus son elementos de las PDU de solicitud/respuesta Modbus
(Modbus-IDA, 2006).
En la actualidad, Modbus es uno de los protocolos de comunicación industrial más
utilizados gracias a su sencillez y su carácter abierto, su uso está ampliamente extendido
25
entre múltiples fabricantes de dispositivos. A continuación, se describe sus aspectos más
importantes que ayudaron a realizar la presente investigación.
a) Arquitectura Protocolar
Modbus en un protocolo que ocupa el nivel 7 (aplicación) dentro del modelo de referencia
OSI. Se implementa de las siguientes tres formas:
• TCP: Utilizando Ethernet como enlace de datos y acceso al medio.
• Transmisión serie asíncrona sobre diversos medios: RS232/422/485.
• Modbus Plus: Red de alta velocidad con paso de testigo. Utiliza HDLC como nivel
de enlace de datos.
Figura 10. Arquitectura de Modbus según el modelo OSI.
Fuente: (Cerezuela Martínez, 2014)
En la Figura 10 se indica la arquitectura del protocolo de comunicación Modbus según el
modelo de referencia OSI.
b) Formato de las Tramas
El protocolo Modbus define una unidad de datos de protocolo (PDU) muy sencilla y
totalmente independiente de las capas de comunicación adyacentes. El mapeo de
protocolo MODBUS, en buses o redes específicos, puede introducir algunos campos
adicionales en la unidad de datos de la aplicación (ADU) (Cerezuela Martínez, 2014).
La PDU es la unidad de datos básica del protocolo Modbus, formada por dos campos:
26
• Código de Función: especifica el tipo de acción a realizar por parte del servidor.
Ocupa un Byte.
• Campo de Datos: tiene que ver con el mensaje. Si este ha sido enviado por el
cliente hacia el servidor, contendrá información que el servidor necesita para
ejecutar la acción indicada por el código de función. Si, por el contrario, el
mensaje ha sido enviado por el servidor podrá contener, los datos solicitados por
el cliente o un código de error, que indicará que la acción solicitada no se ha
podido llevar a cabo y la causa.
La ADU es la unidad de datos del protocolo en la práctica. Tiene un campo adicional que
depende del tipo de red o bus sobre el que se use el protocolo. En el caso de Modbus RTU
este campo ocupa un Byte y se emplea para identificar al esclavo origen o destino de los
datos. Si se emplea Modbus TCP este campo es algo más complejo, por lo que se detallará
con mayor profundidad en el apartado dedicado a esta versión del protocolo. En la Figura
11 se indica la trama general del protocolo Modbus, así como las tramas de este protocolo
sobre diferentes tipos de redes.
Figura 11. Formato de las tramas Modbus.
Fuente: (Cerezuela Martínez, 2014)
Los mensajes de tipo petición o solicitud, que viajan desde el esclavo hacia el maestro,
están compuestos por el código de función y los datos. La composición de los datos
depende del tipo de petición, que puede ser de lectura o escritura:
• Lectura. En el caso expuesto el campo de datos está compuesto por una
dirección de inicio –a partir de la cual leer– y un número de datos a leer.
27
Ambos campos tienen una longitud de dos Bytes, observe la figura a
continuación:
Código de función
(1 Bytes)
Dirección
(2 Bytes)
Numero de datos
(2 Bytes)
Figura 12. Petición de solicitud de lectura de datos Modbus.
Fuente: Autor.
• Escritura. El campo de datos tiene diferentes estructuras según el tipo y el
número de datos que se desee escribir. En las siguientes figuras se describen
los diferentes tipos de peticiones de escritura según el tipo y número de datos
a escribir.
Código de función
(1 Bytes)
Dirección
(2 Bytes)
Datos a escribir
(2 Bytes)
Figura 13. Petición de escritura simple de valor binario.
Fuente: Autor.
Código de
función
(1 Bytes)
Dirección
(2 Bytes)
Numero de
valores
(2 Bytes)
Número de
bytes
Datos a
escribir
Figura 14. Petición de escritura de múltiples valores binarios.
Fuente: Autor.
Código de función
(1 Bytes)
Dirección
(2 Bytes)
Datos a escribir
(2 Bytes)
Figura 15. Petición de escritura simple de registros.
Fuente: Autor.
Código de
función
(1 Bytes)
Dirección
(2 Bytes)
Numero de
valores
(2 Bytes)
Número de
bytes
Datos a
escribir
Figura 16. Petición de escritura de múltiples de registros.
Fuente: Autor.
El tamaño de la PDU Modbus está limitado por la restricción de tamaño, heredado de la
primera aplicación Modbus en red de línea serie (máx. RS485 ADU = 256 bytes). Por lo
tanto, Modbus PDU comunicación serie = 256 – Dirección servidor (1 byte) - CRC (2
bytes) = 253 bytes, y, en consecuencia:
28
• RS232 / RS485 ADU = 253 bytes + dirección de esclavo (1 byte) + CRC (2
bytes) = 256 bytes.
• TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.
Con respecto a la codificación de los datos, Modbus usa una representación big-endian
para direcciones e ítems de datos. Esto significa que cuando se transmite un dato más
largo de un byte, el byte más significativo es enviado primero.
Tamaño del Registro Valor
16 - bits 0x1234 El primer byte en enviar es 0x12 y luego 0x34
c) Modelo de Datos
El modelo de datos en Modbus distingue entre entradas digitales, salidas digitales (coils),
registros de entrada (input registers) y registros de retención (holding registers). Las
entradas y salidas digitales ocupan, evidentemente, un bit; mientras que los registros,
tanto de entrada como de retención, ocupan dos Bytes (Martinez, 2014). En la Tabla 4:,
se indica el modelo de datos del protocolo Modbus.
Tabla 4:
Modelo de datos en el protocolo Modbus.
Bloque de Memoria Tipo de Dato Acceso de Maestro
Entradas Discretas (Discretes Input) Booleano Solo lectura
Bobinas (Coils) Booleano Lectura y escritura
Registros de entrada (Input Registers) Palabra sin signo Solo lectura
Registros de retención (Holding Registers) Palabra sin signo Lectura y escritura
Fuente: (Martinez, 2014).
Para cada una de los tipos de datos, el protocolo permite la selección individual de 65.536
elementos. Las operaciones de lectura o escritura de estos están diseñadas para abarcar
varios elementos de datos consecutivos hasta un límite de tamaño de datos que es
dependiente del código de función.
d) Modelo de Direcciones
Todos los datos que se manejan a través de Modbus han de estar en la memoria del
dispositivo, pero es muy importante no confundir la dirección física con la referencia de
los datos. Esto significa que el dispositivo, en su implementación del protocolo, debe
relacionar las direcciones físicas de los datos con referencias Modbus válidas. Dichas
29
referencias son índices enteros a partir de cero y su especificación depende,
exclusivamente, del fabricante del dispositivo. En la Figura 17 se observa el modelo de
direcciones Modbus.
Figura 17. Modelo de direcciones Modbus.
Fuente: (Modbus-IDA, 2006)
e) Intercambio de mensajes
Como se ha expuesto en los apartados anteriores, existen tres tipos básicos de mensajes
en el protocolo Modbus: solicitud, respuesta y error. A continuación, se detalla cómo se
produce el intercambio de dichos mensajes y el formato con el que se construyen según
la función del protocolo que se emplee.
f) Transacción Modbus
El siguiente diagrama, muestra como el servidor procesa la petición respondiendo con el
mismo código de función, si la operación ha sido satisfactoria o en el caso de que la
petición sea inválida, se envía el código de función de error (0X08) seguido de un código
de excepción que codifica el tipo de problema que se ha producido.
30
Figura 18. Diagrama de flujo de una transacción Modbus en el lado del servidor.
Fuente: (Modbus-IDA, 2006)
g) Códigos de Función Modbus
Los códigos de función del protocolo Modbus se dividen en tres categorías:
• Códigos de función públicos: Estos códigos están completamente definidos,
tienen la garantía de ser únicos; están validados y documentados por la comunidad
MODBUS.org e incluyen una serie de códigos reservados para un posible futuro
uso.
• Códigos de función definidos por el usuario: Existen dos rangos de códigos de
función definibles por el usuario, de forma que es posible implementar funciones
que no están soportadas por las especificaciones. No existen garantías de que la
nueva función creada sea única.
• Códigos de función reservados: Son códigos utilizados por algunas empresas
para productos antiguos y que no están disponibles para el uso público.
En la Tabla 5:, se describen los códigos de función públicos del protocolo de
comunicación Modbus, que fueron utilizados en el presente proyecto de investigación.
31
Tabla 5:
Códigos de función publicos Modbus.
Bit Acceso
Entradas físicas discretas Lectura de entradas discretas 02
Bits internos o salidas
físicas
Lectura de salidas discretas 01
Escritura de un bit de salida 05
Escritura de múltiples salidas 15
16 bit Acceso
Registros físicos de
entrada
Lectura de registro de entrada 04
Lectura de registro de retención 03
Registros internos o
registros de salida físicos
Escritura de un registro 06
Escritura de múltiples registros 16
Lectura/escritura de múltiples registros 23
Acceso a ficheros Leer fichero 20
Escribir fichero 21
Fuente: (Cerezuela Martínez, 2014).
h) Formatos estándares de la unidad de datos de aplicación
Para llevar los datos de la PDU de Modbus, se puede usar varios protocolos de red, entre
los más comunes tenemos el serial y TCP/IP. De tal manera, Modbus integra un conjunto
de variantes ADU que son diseñadas para cada protocolo de red.
Modbus requiere ciertas características para proporcionar una comunicación confiable.
El número de Unidad o de Dirección es usado en cada formato de ADU para proporcionar
información de enrutado a la capa de la aplicación. Cada ADU se vende con una PDU
completa, la cual incluye el código de función y los datos asociados para una solicitud
determinada. Para mayor fiabilidad, cada mensaje incluye la información de
comprobación de errores. Finalmente, todas las ADUs proporcionan un mecanismo para
determinar el comienzo y el final de un marco de solicitud, pero los implementa de
manera diferente.
Los tres formatos ADU estándares son TCP, unidad terminal remota (RTU), y ASCII.
RTU y ASCII ADUs normalmente son usados a través de una línea serial, mientras que,
el TCP es usado a través de redes TCP/IP o UDP/IP modernas.
TCP/IP
Las ADUs de TCP consisten en el “Encabezado de Protocolo de Aplicación Modbus” o
MBAP, por sus siglas en inglés Modbus Application Protocol Header, combinado con la
PDU de Modbus. El MBAP, es un encabezado de uso general que depende de una capa
de red confiable. El formato de esta ADU, incluyendo el encabezado, se muestra en la
Figura 19.
32
Transacción Protocolo Longitud Unidad
ID Modbus PDU
Figura 19. LA ADU de TCP/IP.
Fuente: (National Instruments, 2018)
Los campos de datos del encabezado indican su uso. Primero, incluye un identificador de
transacción. Esto es valioso en una red en la que se pueden soportar múltiples solicitudes
simultáneamente. Es decir, un maestro puede enviar solicitudes 1, 2, y 3. En algún punto,
un esclavo puede responder en el orden 2, 1, 3, y el maestro puede igualar las solicitudes
con las respuestas y analizar los datos con precisión. Esto es útil para redes Ethernet.
El identificador de protocolo, es normalmente cero, pero se puede utilizar para ampliar el
comportamiento del protocolo. El campo de longitud es usado por el protocolo para
delinear la longitud del resto del paquete. La ubicación de este elemento también indica
la dependencia de este formato encabezado en una capa de red confiable. Dado que, los
paquetes TCP tienen verificación de errores integrada y garantizan la coherencia de los
datos y la entrega, la longitud del paquete puede ser ubicado en cualquier parte del
encabezado. En una red inherentemente menos confiable como una red serial, un paquete
podría perderse, teniendo el efecto de que incluso si la escritura de datos leída por la
aplicación incluía información válida de transacción y del protocolo, la información de
longitud alterada volvería inválido al encabezado. TCP proporciona una cantidad
razonable de protección contra esta situación.
El ID de unidad generalmente no es usado por los dispositivos TCP/IP. Sin embargo,
Modbus es un protocolo común en el que se implementan muchos gateways, lo cual
convierte al protocolo Modbus en otro protocolo. En el caso original de uso, un gateway
Modbus TCP/IP a serial podría ser usado para permitir la conexión entre las nuevas redes
TCP/IP y redes seriales anteriores. En dicho entorno, el ID de Unidad es usado para
determinar la dirección del dispositivo esclavo para la que la PDU está destinada.
Finalmente, la ADU incluye una PDU. La longitud de esta PDU está aún limitada a 253
bytes para el protocolo estándar.
33
RTU
La ADU de RTU es más simple que la de TCP, observe la Figura 20.
Dirección Modbus PDU CRC
Silencio
(3.5
caracteres)
Silencio
(3.5
caracteres)
Figura 20. La ADU de RTU.
Fuente: (National Instruments, 2018).
Esta ADU incluye solamente dos piezas de información, además de la PDU principal.
Primero, una dirección es usada para definir para qué esclavo está diseñada una PDU. En
la mayoría de las redes, una dirección 0 define la dirección de "broadcast". Es decir, un
maestro puede enviar un comando de salida a la dirección 0 y todos los esclavos deben
procesar la solicitud, pero ningún esclavo debe responder. Además de esta dirección, un
CRC es usado para asegurar la integridad de los datos.
Sin embargo, la realidad es que la situación en las implementaciones más modernas está
lejos de ser simple. Al momento de encapsular el paquete Modbus, hay tiempos en
silencio, es decir, periodos en los que no hay comunicación en el bus. Para una velocidad
de transferencia de 9,600 (este tiempo es alrededor de 4 ms). El estándar define una
longitud mínima de silencio, independientemente de la velocidad de transferencia, de un
poco menos de 2 ms.
ASCII
La ADU de ASCII es más compleja que la de RTU como se muestra en la Figura 21.
0X3A
“:”
Dirección
(ASCII)
Modbus PDU
(ASCII)
LCR
(ASCII)
0x0D
CR
0x0A
LF
Figura 21. La ADU de ASCII.
Fuente: (National Instruments, 2018).
La ADU de ASCII, tiene un inicio y final bien definido y único para cada paquete. Es
decir, cada paquete comienza con ":" y termina con un “retorno de carro” o CR, por sus
siglas en inglés Carriage Return, y alimentación de línea (LF). La ADU de ASCII
transfiere todos los datos como caracteres hexadecimales codificados en ASCII. Es decir,
34
en lugar de enviar un solo byte para el código de función 3, 0x03, envía los caracteres
ASCII "0" y "3" o 0x30 / 0x33. Esto hace que el protocolo sea más legible, pero también
significa que el doble de datos debe ser transferidos a través de la red en serie y que las
aplicaciones que envían y reciben deben ser capaces de analizar los valores ASCII.
35
CAPÍTULO 2: SOFTWARE DE DESARROLLO DE SISTEMAS HMI/SCADA,
BASE DE DATOS E INTERFAZ WEB.
4.2. Desarrollo de Aplicaciones HMI
Las aplicaciones HMI, son un conjunto de despliegues que le permiten al operador
determinar el comportamiento en tiempo real del proceso. El software de desarrollo de
sistemas HMI/Scada presentan módulos que permiten generar despliegues. Estos
despliegues son generados y caracterizados de acuerdo al proceso que representan. Sin
embargo, existen organizaciones que desarrollan estándares con el objetivo de normalizar
el desarrollo de interfaces Hombre-Máquina dentro de sistemas de control distribuido. El
objetivo de estas organizaciones es que los desarrolladores de despliegues sigan ciertas
reglas a la hora de representar a las variables de manera gráfica o mediante
identificaciones (Tags).
Además, intentan normalizar el uso de colores y los significados de los mismos. Como
resultado, se tiene una normalización en la presentación del proceso desde el punto de
vista estructural, pero no así desde el punto de vista funcional, que depende de las
características del proceso (Moya Calderón, 2009).
4.2.1. Software de Desarrollo de Sistemas HMI/SCADA
Las primeras herramientas para la creación de sistemas SCADA fueron desarrolladas para
aplicaciones específicas, dependiendo de las características del proceso a supervisar y
controlar. Por esta razón, los sistemas SCADA eran adaptados a las necesidades de un
proceso específico. Como resultado, los proveedores de software de desarrollo de estos
sistemas adaptaron su trabajo previo en aplicaciones específicas, para que el software
pueda ser utilizado en otro tipo de industria. Con el tiempo, varios fabricantes
desarrollaron paquetes de software capaces de comunicarse con los sistemas y
dispositivos de control de una determinada planta, y le dieron al sistema en general
escalabilidad y flexibilidad. Sin embargo, ciertos procesos requerían de aplicaciones
adicionales, las cuales fueron desarrolladas como módulos específicos.
En la actualidad, el objetivo de los proveedores de software para sistemas HMI/SCADA
es desarrollar una arquitectura abierta que permita su utilización en diversos procesos
industriales, con la adición de módulos específicos para determinadas industrias. No
36
obstante, los proveedores mantienen todavía la preferencia hacia determinados procesos,
por lo que, si se quiere desarrollar un sistema SCADA sobre un proceso no muy común,
los ingenieros deben estar preparados para generar los sistemas adicionales que dicho
proceso pueda necesitar. Por esta razón, las industrias escogen a sus proveedores en
función al conocimiento que tienen los mismos sobre el proceso.
En conclusión, si se contacta con un proveedor con conocimientos amplios sobre el
proceso, el desarrollo de sistemas adicionales será mínimo, pero el costo será mayor, en
cambio, sí se contacta con un proveedor con conocimientos limitados, el costo será
menor, pero el sistema requerirá del desarrollo de sistemas adicionales.
Actualmente, existen numerosas opciones de fabricantes de software para el desarrollo
de sistemas HMI/Scada. Entre los más conocidos tenemos:
• Intellution: IFIX.
• Wonderware: InTouch.
• Siemens: WinCC.
• Rockwell Automation: RS-View.
• GE-Fanuc: Cimplicity.
Estas aplicaciones son de tipo propietario y tienen un determinado costo. Como resultado,
en ocasiones industrias medianas y pequeñas no pueden acceder a este software para su
proceso debido al alto costo de la Licencia de distribución de la aplicación (Moya
Calderón, 2009).
4.2.2. Funciones del Software de Desarrollo de Sistemas HMI/SCADA
• Supervisar el proceso: El sistema HMI/SCADA genera aplicaciones que
permiten modificar el estado de una determinada variable de manera remota, a
partir del análisis del proceso en un determinado instante de tiempo.
• Generar Reportes y Alarmas: El Sistema HMI/SCADA permite configurar el
sistema para determinar si ha ocurrido un evento no deseado dentro del sistema
para después generar la alarma y el reporte respectivo. Estas alarmas se
determinan a partir de límites establecidos por el supervisor del sistema.
37
• Generar Algoritmos de Control: Actualmente el software para desarrollo de
HMIs permite generar algoritmos de control. Es decir, permite modificar o ajustar
el valor de una determinada variable (variable manipulada) del proceso a partir de
los valores de ciertas señales de entrada, con el objetivo de mantener una variable
(variable controlada) del proceso dentro de valores preestablecidos.
• Configura el sistema de Comunicación: Mediante el software de desarrollo de
sistemas HMI/SCADA, se configura los canales de comunicación con los diversos
dispositivos de campo.
• Desarrollar despliegues: El software de desarrollo de sistemas SCADA tiene
módulos que permiten generar los despliegues que describen gráficamente el
proceso.
• Configurar los sistemas de Gestión de Base de datos: El software de desarrollo
de sistemas HMI/SCADA permite configurar la base de datos del proceso y las
funciones específicas a realizar con los datos almacenados. Mediante este módulo
se estructura el sistema de control y supervisión del proceso, ya que define el
grupo de variables involucradas en el sistema.
Como se mencionó anteriormente, el alto costo de las licencias de distribución de las
aplicaciones de tipo propietario crea la necesidad de buscar otras opciones más
económicas y de software libre que nos permitan crear o desarrollar nuestra propia
aplicación HMI que se adapte específicamente a los requerimientos de nuestro sistema.
Para ello, hoy en día existe una gran variedad de software de programación de alto nivel
que nos permiten crear este tipo de aplicación de una manera relativamente sencilla, razón
por lo cual, para el presente proyecto se utilizó el lenguaje de programación “Python”, ya
que, con sus múltiples librerías ya implementadas y con las desarrolladas por terceros,
fueron de mucha ayuda, reduciendo muchas horas de programación al momento de
desarrollar el sistema HMI/SCADA del que versa el presente proyecto. A continuación,
se describe de manera general el lenguaje de programación Python.
4.2.3. Python
Python es un lenguaje de programación interpretado o también denominado “script”,
básicamente un lenguaje interpretado es aquel en el cual sus instrucciones son traducidas
por medio de un intérprete a un lenguaje entendible y esto es realizado en la ejecución de
38
cada instrucción. Fue creado por Guido van Rossum alrededor de los años 90. Este
lenguaje tiene una sintaxis limpia facilitando un código legible, evitando el punto y coma
en cada sentencia y en lugar de llaves hace uso de la identación o también llamado bloque
de espacio.
Es un lenguaje multiparadigma al momento de realizar el uso de la programación
orientada a objetos, de forma imperativa y funcional. Este lenguaje presenta las siguientes
características:
• Tipado dinámico: el tipo de dato se determina en tiempo de ejecución según el
valor que se le asigne a la variable.
• Fuertemente tipado: no se permite tratar a una variable como si fuera de un tipo
distinto al que tiene, para ello es necesario convertirla de forma explícita dicha
variable al nuevo tipo previamente.
• Multiplataforma: está disponible en plataformas como Windows, Mac y
distribuciones Linux
• Proyectos basados en Python: entre ellos tenemos algunos ejemplos como los
sitios de búsqueda como Google y YouTube, aplicaciones para compartir archivos
como uTorrent y Dropbox, distribuciones de paquetes para Linux desarrollados
en Python, Frameworks entre los más populares Django, Tornado, Flask. Entornos
de programación como: Sublime text, PyCharm, Ninja-IDE todos ellos
desarrollados en Python.
El lenguaje de programación Python presenta las siguientes ventajas:
• Sencillo y rápido para el desarrollo de proyectos.
• Sintaxis fácil de entender, puesto que es cercana al lenguaje natural y los
programas elaborados en Python se asemejan aun seudocódigo lo cual ayuda
mucho en su mantenimiento.
• Open source, libre acceso para todo el mundo.
• Código organizado debido al uso de la identación o bloques de espacio que por lo
general está basado en cuatro espacios.
• Utiliza menos líneas de código.
• Tiene una gran comunidad que puede ser de gran ayuda al momento de resolver
cualquier error que se presente en el código con el que se esté trabajando.
39
Existen diferentes entornos de programación (IDE) para Python, los cuales facilitan la
escritura del código fuente, detección de errores y compilación en un entorno virtual
controlado. En la Figura 22, se indica algunos de los más resaltantes IDE y sus principales
características.
Editor de texto que soporta diferentes lenguajes.
Amigable.
Dispone de diferentes plugings que ayudan en la programación.
IDE: permite crear proyectos en Python.
Corrige eventuales errores mientras se ejecuta el código.
IDE: usado para programar en Python.
Proporciona análisis de código.
Depuración gráfica.
Probador de unidad integrada, entre otros.
Figura 22. Entornos de Desarrollo Integrado IDE.
Fuente: Autor
Las múltiples características y funciones avanzadas que presenta el IDE PyCharm,
permiten un manejo muy eficiente de las librerías y sus versiones tanto propias como de
terceros desarrolladas en Python, también presenta la facilidad de poder referenciar tanto
los objetos, con sus atributos y métodos, variables y funciones, desde cualquier parte del
programa gracias a que este IDE implementa un análisis del código muy eficaz durante
la escritura del código fuente lo cual sirve de gran ayuda ya que nos ayuda a evitar errores
de tipeo al no llamar de forma adecuada a las diferentes instancias que se hayan creado
anteriormente en el código. Con estas importantes ventajas que nos proporciona este IDE
y debido a que el código desarrollado implementa muchos objetos, con sus atributos y
métodos, así como el manejo de varias librerías, se utilizó este IDE para llevar a cabo el
desarrollo del programa del cual versa este proyecto.
40
4.2.3.1. MinimalModbus 0.7
MinimalModbus es un módulo de Python que presenta facilidades para la comunicación
con instrumentos (esclavos) desde un computador (maestro) utilizando el protocolo
Modbus, y está destinada a estar en ejecución en el maestro. La única dependencia es el
módulo PySerial. Este software soporta las versiones de comunicación serial Modbus
RTU y Modbus ASCII, está diseñado para su uso en Linux, OS X y para Windows. Es de
código abierto. Funciona en las versiones de Python 2.7, 3.2, 3.3 y 3.4 (Berg, 2019).
MinimalModbus es un controlador creado en Python para los protocolos Modbus RTU y
Modbus ASCCII a través del puerto serie RS485 o RS232. Esta librería presenta los
valores por defecto para configurar la comunicación serial del módulo pyserial como se
muestra a continuación:
BAUDRATE = 19200
""" Valor predeterminado para la velocidad de transmisión en baudios (int)"""
PARITY = serial.PARITY_NONE
""" Valor por defecto para la paridad. Consulte el módulo pySerial para la documentación.
El valor predeterminado es serial.PARITY_NONE"""
BYTESIZE = 8
""" Valor predeterminado para el tamaño de bytes (int)"""
STOPBITS = 1
""" Valor predeterminado para el número de stopbits (int)."""
TIMEOUT = 0.5
""" Valor predeterminado para la configuración de cierre de puerto"""
CLOSE_PORT_AFTER_EACH_CALL = True
""" Valor predeterminado para la configuración de cierre de puerto."""
Esta librería presenta la clase Instrument la cual se utilizó para hablar con los
instrumentos (esclavos) a través de los protocolos Modbus RTU a través de RS485 o
RS232.
class minimalmodbus.Instrument( port , slaveaddress , mode = 'rtu' )
"""Args:
port (str): el nombre del puerto serie, por ejemplo /dev/ttyUSB0(Linux),
/dev/tty.usbserial(OS X) o COM4(Windows).
slaveaddress (int): Dirección de esclavo en el rango de 1 a 247 (use números decimales,
no hexadecimales).
mode (str): selección de modo. Puede ser MODE_RTU o MODE_ASCII. """
41
Ahora se indica los métodos read_register y read_long usados para leer los registros
donde se almacenan las variables electro-energéticas de interés en los esclavos de la red
Modbus RTU.
read_register():
def read_register( registeraddress , numberOfDecimals = 0 , functioncode = 3 , signed
= False )
"""Lea un entero de un registro de 16 bits en el esclavo, posiblemente escalando.
El registro esclavo puede contener valores enteros en el rango de 0 a 65535 ("INT16 sin
signo").
Args:
registeraddress (int): la dirección del registro esclavo (use números decimales, no
hexadecimales).
numberOfDecimals (int): el número de decimales para la conversión de contenido.
functioncode (int): código de función Modbus. Puede ser 3 o 4.
signed (bool): si los datos deben interpretarse con signo o sin signo.
Devuelve:
Los datos de registro en valor numérico (int o float).
Plantea:
ValueError, TypeError, IOError"""
read_long():
def read_long(registeraddress, functioncode=3, signed=False):
"""Lee un entero largo (32 bits) del esclavo.
Los enteros largos (32 bits = 4 bytes) se almacenan en dos registros de 16 bits consecutivos
en el esclavo.
Args:
registeraddress (int): la dirección de inicio del registro esclavo (use números decimales,
no hexadecimales).
functioncode (int): código de función Modbus. Puede ser 3 o 4.
signed (bool): si los datos deben interpretarse como no firmados o firmados.
Devoluciones:
El valor numérico (int).
Plantea: ValueError, TypeError, IOError"""
4.2.3.2. pyModbusTCP
La librería pyModbusTCP creada para Python permite el acceso al servidor Modbus/TCP
a través del objeto ModbusClient. Esta se define en el módulo cliente. Para hacer frente
a la necesidad frecuente de la modulación de datos ModBus (por ejemplo, convertir
flotante IEEE de 32 bits en palabras de 2X16 bits), un módulo especial llamado utils
proporciona algunas funciones útiles que se necesitaron emplear para el desarrollo
42
satisfactorio del presente proyecto. En la Figura 23, se presentan los módulos soportados
del paquete pyModbusTCP.
Figura 23. Mapa del paquete pyModbusTCP.
Fuente: (Lefebvre, 2019)
Para llevar a cabo el presente proyecto se usaron solamente los módulos client y utils. La
clase ModbusClient del módulo client se inicia desde el constructor con sus respectivos
argumentos como se muestra a continuación.
from pyModbusTCP.client import ModbusClient
objeto1 = ModbusClient(host = “localhost”, port = 502 )
Args:
host (str): dirección IP del servidor ModbusTCP
port (int): número del puerto TCP
Una vez creador nuestro objeto1 que es en realidad el cliente ModbusTCP procedemos a
establecer el enlace TCP para posteriormente iniciar las consultas al servidor TCP de la
siguiente manera.
if objeto1.open():
registros = objeto1.read_holding_registers(0, 10)
objeto1.close()
Una vez establecida de forma correcta la conexión TCP a través del método open() de
nuestro objeto1 (cliente ModbusTCP) se procede a enviar la solicitudes ModBus
disponibles. En este caso se usaron las funciones que se muestran a continuación para leer
los registros del UPS EATON 9390.
pyModbusTCP
Módulo client
Clase
ModbusClient
Módulo server
Clase
ModbusServer
Módulo utils
Funciones de manipulacion de
los datos
Módulo
constants
Todas las constantes del
paquete
43
Tabla 6:
Funciones ModbusTCP.Client de la librería pyModbusTCP.
Nombre de la función Código de función Función ModbusClient
Leer entradas discretas 2 read_discrete_inputs()
Leer registros de entrada 4 read_input_registers()
Fuente: (Lefebvre, 2019).
Las funciones mostradas en la Tabla 6: admiten los siguientes parámetros para ser
llamadas adecuadamente.
read_discrete_inputs():
read_discrete_inputs( bit_addr , bit_nb = 1 )
Parámetros:
bit_addr ( int ) - dirección de bit (0 a 65535)
bit_nb ( int ) - número de bits para leer (1 a 2000)
Devoluciones:
lista de bits o Ninguno si error
Tipo de devolución:
lista de bool o None
read_input_registers():
read_input_registers( reg_addr , reg_nb = 1 )
Parámetros:
reg_addr ( int ) - dirección de registro (0 a 65535)
reg_nb ( int ) - número de registros para leer (1 a 125)
Devoluciones:
Lista de registros o Ninguna si falla
Tipo de devolución:
lista de enteros (int) o none
Ahora vamos a indicar la función que se utilizó del módulo utils. Para hacer uso de ella
realizamos la siguiente declaración:
from pyModbusTCP import utils
la función que accedemos del módulo utils es la siguiente:
pyModbusTCP.utils.decode_ieee( val_int )
“Descifre Python int (32 bits entero) como un formato de precisión simple IEEE”
Parámetros:
val_int ( int ) - un entero de 32 bits como un valor de Python int
Devoluciones:
resultado flotante
44
4.2.4. Qt
Qt es una amplia plataforma de desarrollo que incluye clases, librerías y herramientas
para la producción de aplicaciones de interfaces gráficas en C++ de forma nativa y
también puede utilizarse con otros lenguajes de programación a través de bindings. Qt
puede trabajar en plataformas como Windows y en las derivadas de Unix. Este Sofwre
permite desarrollar ricas aplicaciones gráficas incluyendo soporte de nuevas tecnologías
como OpenGL, XML, Base de Datos, programación para redes, internacionalización
entre otros. Qt es completamente gratuito para aplicación de código abierto, además posee
una gran documentación de librerías y manejo de clases.
Figura 24. Características de Qt.
Fuente: (Company, The Qt, 2018)
Las características de Qt se muestran en la Figura 24. Una de las herramientas más
utilizadas que presenta Qt Creator, es la herramienta de Qt Designer la cual es utilizada
en el presente proyecto para el diseño de la interfaz gráfica de usuario del software de
monitoreo del que se trata en el presente proyecto.
Qt Designer es la herramienta de Qt usada para diseñar y construir interfaces gráficas de
usuario (GUI) con Qt Widgets. Permite componer y personalizar ventanas o cuadros de
diálogo de manera que se ve lo que obtiene y los prueba utilizando diferentes estilos y
resoluciones. Los widgets y formularios creados con Qt Designer se integran a la
perfección con el código programado, utilizando el mecanismo de ranuras y señales de
Qt, para que pueda asignar fácilmente el comportamiento a elementos gráficos. Todas las
•Qt Creator viene con una amplia gama deherramientas integradas para desarrolladores ydiseñadores. Permite diseñar la UI, escribir código ymucho más en un IDE multiplataforma.
Herramientas e IDE
•Permite desarrollar de forma más rápida einteligente con las bibliotecas y API intuitivas ycompletas de Qt.
Bibliotecas y APIs
•Qt tiene una amplia comunidad activa que sirvede apoyo con cualquier incoveniente que sepresente durante la ejecucion de cualquierproyecto.
1M + comunidad de desarrolladores
45
propiedades establecidas en Qt Designer pueden cambiarse dinámicamente dentro del
código. Además, las funciones como la promoción de widgets y los complementos
personalizados le permiten usar sus propios componentes con Qt Designer (Company,
The Qt, 2018).
Figura 25. Interfaz gráfica de la herramienta Qt Designer.
Fuente: Autor.
La interfaz gráfica de la aplicación Qt Designer se observa en la Figura 25, en la cual se
muestra una ventana secundaria al momento de abrir la aplicación indicando que se elija
una ventana para la forma del proyecto; en ella se puede elegir entre ventana principal
(main window), cuadro de diálogo con botones o sin botones entre otros widgets. Los
widgets son los elementos principales para la creación de interfaces gráficas en Qt. En la
parte izquierda se puede visualizar la caja de widgets en la cual se presentan los botones,
las etiquetas entre otros. En la parte derecha se encuentra el inspector de objetos el cual
es el encargado de describir la estructura de los widgets de quien contiene a quien y en
qué nivel se encuentran; más abajo se ubica el editor de propiedades de los widgets los
cuales son un objeto y podemos editar sus atributos y finalmente en la parte inferior
derecha se encuentra el Editor de señales/slot el cual nos muestra las señales y los slot de
los widgets, las señales se refiere al evento que ocurre sobre un objeto como puede ser
dar un click sobre un botón y el slot llama a la función que se realiza luego de ocurrir el
evento en dicho objeto.
Como ya se indicó anteriormente, Qt Designer está diseñado para aplicaciones gráficas
basadas en C++, es por ello que se utilizó PyQt el cual es un binding de la biblioteca
46
gráfica de Qt para el lenguaje de programación con Python, esta biblioteca está
desarrollada por la firma británica Riverbank Computing y está disponible para Windows
Linux y Mac bajo diferentes licencias.
4.2.5. Sistemas de Gestión de Base de Datos
Los sistemas de gestión de bases de datos son sistemas de información integrales
(almacenan y administran la información de un proceso), esto debido a la necesidad de
gestionar las acciones que realiza una determinada industria. El objetivo principal de un
sistema de gestión de base de datos, es que las aplicaciones puedan acceder a los datos
sin necesidad de conocer la forma en la que están almacenados los mismos.
4.2.5.1. Elementos en un Sistema de Base de Datos
Los elementos que integra un sistema de base de datos son los siguientes:
• Datos: Constituyen toda la información que se necesita almacenar de un
determinado proceso o sistema.
• Hardware: Dispositivo físico (Servidor) en el cual se almacenan las bases de
datos.
• Software: Es el sistema que permite gestionar las bases de datos (ejemplo:
MySQL).
• Usuarios: Son las personas o aplicaciones que hacen uso de los datos del sistema.
4.2.5.2. Tipos de Datos
Las bases de datos están compuestas por los siguientes tipos de datos:
Datos almacenados: Son los datos obtenidos del sistema y los cuales son
administrados por el usuario mediante el sistema de gestión de base de datos.
Datos complementarios: Son los datos que especifican la estructura de la base
de datos; por ejemplo, el tipo de datos almacenados (si son texto, números, entre
otros), o el nombre del campo al que pertenece cada dato (nombre de la variable,
valor, entre otros) (Moya Calderón, 2009).
4.2.5.3. Administración y Funciones dentro de una Base de Datos
El usuario o aplicación puede realizar las siguientes acciones:
47
• Buscar datos: Los sistemas de gestión de bases de datos permiten al usuario o
aplicación obtener datos, a partir de condiciones de búsqueda establecidas
(consultas).
• Añadir datos: El usuario puede añadir o ingresar datos en el instante que sea
necesario.
• Modificar datos: Los sistemas de gestión de bases de datos permiten al usuario
modificar los datos y los campos que definen los tipos de datos almacenados,
cuando sea necesario.
• Eliminar datos: El usuario puede eliminar los datos que no están siendo
utilizados en cualquier instante de tiempo.
4.2.5.4. Aplicaciones y Ventajas de las Bases de Datos
Hoy en día las bases de datos están inmersas en diversos campos de nuestra vida diaria.
Las aplicaciones de las bases de datos van desde bases de datos que almacenan una
pequeña empresa familiar, hasta bases de datos que almacenan la información de miles
de millones de personas por todo el mundo que están registradas en una red social.
Por otro lado, la necesidad de intercambiar información a altas velocidades y de manera
fiable en el mundo actual, ha hecho de las bases de datos elementos indispensables (Moya
Calderón, 2009). Entre las principales ventajas que tiene el usuario al implementar una
base de datos tenemos:
• Generación de reportes: Las bases de datos permiten a los usuarios obtener
información sobre el sistema de manera flexible.
• Velocidad: Las bases de datos permiten a usuarios y aplicaciones almacenar y
obtener de manera asíncrona y rápida la información.
• Precisión: Las bases de datos administran de manera adecuada y con mucho
cuidado los datos de entrada; en consecuencia, proveen resultados precisos y
consistentes de sus datos.
• Reportes detallados: Las bases de datos pueden almacenar y generar resultados
completos y detallados a altas velocidades.
48
4.2.5.5. Bases de Datos Relacionales
Las bases de datos relacionales son un tipo de bases de datos basado en relaciones o tablas
(Moya Calderón, 2009). Las características principales de una base de datos relacional
son las siguientes:
• Una base de datos relacional se compone de varias tablas o relaciones
(interconexiones).
• Las tablas que componen una base de datos relacional son un conjunto de
registros, filas o tuplas.
• No puede existir dos tablas con el mismo nombre (no permite la interconexión).
• El lenguaje estándar para generar consultas a bases de datos relacionales es SQL
(Structured Query Language).
• Garantiza una integridad referencial. Si se elimina un registro, se eliminan todos
los registros dependientes.
En la actualidad, existen multitud de sistemas gestores de base de datos o SGBD, la
mayoría relacionales. Los gestores de bases de datos más usados se indican en la Tabla
7:.
Tabla 7:
Gestores de base de datos.
SGBD Descripción Ventajas
MySQL
Es un sistema de gestión de base de datos
relacional, multihilo y multiusuario
seguramente el más usado en
aplicaciones creadas como software
libre. Por un lado, se ofrece bajo la GNU
GPL, pero, empresas que quieran
incorporarlo en productos privativos
pueden comprar a la empresa una
licencia que les permita ese uso.
-Velocidad al realizar las operaciones.
-Bajo costo en requerimientos para la
elaboración de bases de datos.
-Facilidad de configuración e instalación.
Microsoft
SQL Server
Es un sistema de gestión de bases de
datos relacionales basado en el lenguaje
Transact-SQL, capaz de poner a
disposición de muchos usuarios grandes
cantidades de datos de manera
simultánea.
-Soporte de transacciones.
-Escalabilidad, estabilidad y seguridad.
-Soporta procedimientos almacenados.
-Incluye también un potente entorno
gráfico de administración.
-Permite administrar información de otros
servidores de datos
Oracle
Es un sistema de gestión de base de datos
relacional, fabricado por Oracle
Corporation. Tradicionalmente Oracle ha
sido el SGBS por excelencia,
considerado siempre como el más
completo y robusto.
-Soporte de transacciones.
-Estabilidad.
-Escalabilidad.
-Es multiplataforma.
49
Microsoft
Access
Es un sistema de gestión de bases de
datos Relacional creado por Microsoft
(DBMS) para uso personal de pequeñas
organizaciones. Se ha ofrecido siempre
como un componente de la suite
Microsoft Office, aunque no se incluye
en el paquete “básico”.
-Permite crear tablas de datos indexadas.
-Creación de consultas y vistas.
-Consultas referencias cruzadas.
-Consultas de acción (INSERT,
DELETE, UPDATE).
-Formularios e Informes.
-Llamadas a la API de windows.
PostgreSQL
Es un sistema de gestión de base de datos
relacional orientada a objetos y libre,
publicado bajo la licencia BSD. El
desarrollo de PostgreSQL es dirigido por
una comunidad PGDG (PostgreSQL
Global Development Group) de
desarrolladores que trabajan de forma
desinteresada, altruista, libre y/o apoyada
por organizaciones comerciales.
-Alta concurrencia: mediante un sistema
denominado MVCC (Acceso concurrente
multiversión)
-Amplia variedad de tipos nativos: provee
nativamente varios soportes
-Ahorros considerables de costos de
operación
-Estabilidad y confiabilidad
DB2
Este SGBD es propiedad de IBM, bajo la
cual se comercializa el sistema de gestión
de base de datos. Utiliza XML como
motor, además el modelo que utiliza es el
jerárquico en lugar del modelo relacional
que utilizan otros gestores de bases de
datos. Es el único de los gestores que
hemos comentado que no es relacional.
-Permite el manejo de objetos grandes
(hasta 2 GB)
-Permite agilizar el tiempo de respuestas
de esta consulta
-Recuperación utilizando accesos de sólo
índices.
-Predicados correlacionados.
-Tablas de resumes y replicadas.
Fuente: (Iruela, 2018).
El almacenamiento de las variables electro-energéticas las cuales son obtenidas con el
software de monitoreo desarrollado en el presente proyecto se lo realiza con el gestor de
base de datos PostgreSQL, por lo que a continuación se describe con detalle este SGBD.
a) PostgreSQL
PostgreSQL es un potente sistema de base de datos relacional de objetos de código abierto
que utiliza y amplía el lenguaje SQL combinado con muchas características que
almacenan y escalan de forma segura las cargas de trabajo de datos más complicadas. Los
orígenes de PostgreSQL se remontan a 1986 como parte del proyecto POSTGRES en la
Universidad de California en Berkeley y tiene más de 30 años de desarrollo activo en la
plataforma central (PDGD. Grupo de Desarrollo Global de PostgreSQL, 2018).
PostgreSQL se ha ganado una sólida reputación por su arquitectura probada,
confiabilidad, integridad de datos, conjunto de características sólidas, extensibilidad y la
dedicación de la comunidad de código abierto detrás del software para ofrecer
constantemente soluciones innovadoras y de alto rendimiento. PostgreSQL se ejecuta en
todos los sistemas operativos principales, ha sido compatible con ACID desde 2001 y
tiene complementos poderosos como el popular extensor de base de datos geoespacial
50
PostGIS. A continuación, se muestra en la Tabla 8: las diversas funciones que se
encuentran en PostgreSQL (PDGD. Grupo de Desarrollo Global de PostgreSQL, 2018).
Tabla 8:
Funciones de PostgreSQL.
Tipos de datos
Primitivas: entero, numérico, cadena, booleano
Estructurado: fecha / hora, matriz, rango, UUID
Documento: JSON / JSONB, XML, valor-clave (Hstore)
Geometría: Punto, Línea, Círculo, Polígono
Personalizaciones: Compuestas, Tipos Personalizados.
Integridad de los datos
ÚNICO, NO NULO
Llaves primarias
Llaves extranjeras
Restricciones de exclusión
Cerraduras explícitas, cerraduras consultivas
Concurrencia,
rendimiento
Indexación: B-tree, Multicolumn, Expresiones, Parcial
Indexación avanzada: GiST, SP-Gist, KNN Gist, GIN, BRIN, índices de
cobertura, filtros Bloom
Planificador / optimizador de consultas sofisticado, análisis de solo índice,
estadísticas de varias columnas
Transacciones, transacciones anidadas (a través de puntos guardados)
Control de concurrencia multi-versión (MVCC)
Paralelización de consultas de lectura y creación de índices de árbol B
Particionamiento de tablas
Todos los niveles de aislamiento de transacciones definidos en el estándar
SQL, incluido Serializable
Recopilación de expresiones Just-in-time (JIT)
Confiabilidad,
Recuperación de
Desastres
Registro de escritura anticipada (WAL)
Replicación: asíncrona, síncrona, lógica
Recuperación de punto en el tiempo (PITR), recursos activos
Espacios de tabla
Seguridad
Autenticación: GSSAPI, SSPI, LDAP, SCRAM-SHA-256, certificado y
más
Sistema robusto de control de acceso
Seguridad de columnas y filas
Extensibilidad
Funciones y procedimientos almacenados.
Lenguajes de procedimiento: PL / PGSQL, Perl, Python (y muchos más)
Contenedores de datos externos: conéctese a otras bases de datos o flujos
con una interfaz SQL estándar
Muchas extensiones que proporcionan funcionalidad adicional, incluyendo
PostGIS
Internacionalización,
Búsqueda de texto
Soporte para conjuntos de caracteres internacionales, por ejemplo, a través
de colaciones de UCI.
Búsqueda de texto completo
Fuente: (PDGD. Grupo de Desarrollo Global de PostgreSQL, 2018)
Según (PDGD. Grupo de Desarrollo Global de PostgreSQL, 2018), PostgreSQL es
altamente escalable tanto por la gran cantidad de datos que puede administrar como por
la cantidad de usuarios concurrentes que puede acomodar. Por tal razón y gracias a sus
múltiples funciones descritas anteriormente como es la compatibilidad e integración con
el lenguaje Python se elige PostgreSQL, ya que el monitoreo en tiempo real almacenará
51
una gran cantidad de datos enviados desde el software de monitoreo escrita en dicho
lenguaje de programación.
4.2.6. Elastic Stack (Interfaz Web)
Elastic Stack es un grupo de productos de código abierto de Elastic, observe la Figura 26,
diseñado para ayudar a los usuarios a tomar datos de cualquier tipo de fuente (cualquier
base de datos) y en cualquier formato (tabla relacional o no relacional) y buscar, analizar
y visualizar esos datos en tiempo real. El grupo de productos era conocido anteriormente
como Pila ELK, en el que las letras en el nombre representaban los productos del grupo:
Elasticsearch, Logstash y Kibana. Un cuarto producto, Beats, se agregó posteriormente a
la pila, lo que hace que el acrónimo potencial sea impronunciable (Rouse, 2018).
Figura 26. Productos de la Pila Elastic.
Fuente: Unixmen.
Elastic Stack presenta una curva de aprendizaje más pronunciada que algunos productos
comparables, así como, más configuraciones debido en parte a su naturaleza de código
abierto. Sin embargo, a cambio del trabajo adicional, el administrador del sistema es
recompensado con una comprensión más profunda de la estructura subyacente del
software. Elastic se fundó en Ámsterdam en 2012 para apoyar el desarrollo de
Elasticsearch y productos y servicios comerciales relacionados (Rouse, 2018).
En el presente proyecto se utilizó tres productos del Elastic Stack como Elasticsearch,
Logstash y Kibana para gestionar, almacenar y representar los datos en tiempo real
obtenidos de nuestra base de datos implementada con PostgreSQL. En los siguientes
apartados se describen estas herramientas.
52
4.2.6.1. Elasticsearch
Elasticsearch es un motor de búsqueda y análisis RESTful distribuido, capaz de resolver
un número creciente de casos de uso. Como el corazón de Elastic Stack, almacena de
forma centralizada los datos. Elasticsearch es un motor de búsqueda RESTful de código
abierto construido sobre Apache Lucene y lanzado bajo una licencia de Apache. Está
basado en Java y puede buscar e indexar archivos de documentos en diversos formatos
(Rouse, 2018).
Elasticsearch presenta las siguientes características notables:
• Proporciona una solución de búsqueda escalable.
• Realiza búsquedas casi en tiempo real.
• Proporciona soporte para multi-tenancy.
• Agiliza los procesos de copia de seguridad y garantiza la integridad de los datos.
• Un índice se puede recuperar fácilmente en un caso de una falla del servidor.
• Utiliza la notación de objetos Javascript (JSON) y las interfaces del programa de
aplicación Java (API).
• Automáticamente indexa documentos JSON.
• La indexación utiliza identificadores únicos de nivel de tipo.
• Cada índice puede tener su propia configuración.
• Las búsquedas se pueden hacer con cadenas de consulta basadas en Lucene
(Rouse, 2018).
Este producto se utilizó en el presente proyecto para el almacenamiento de los datos de
manera no relacional en el formato JSON obtenidos a través del Logstash, para luego
transmitir los datos a la herramienta de Kibana.
4.2.6.2. Logstash
Logstash es una fuente de procesamiento de datos del lado del servidor de código abierto
que ingiere datos de una multitud de fuentes simultáneamente, la transforma y luego la
envía a Elasticsearch para ser almacenados. Los datos a menudo se encuentran dispersos
o en silos en muchos sistemas en muchos formatos. Logstash admite una variedad de
entradas que extraen eventos de una multitud de fuentes comunes, todas al mismo tiempo.
53
A medida que los datos viajan de la fuente a la tienda, los filtros de Logstash analizan
cada evento, identifican los campos con nombre para construir la estructura y los
transforman para converger en un formato común para un análisis y valor empresarial
más fáciles y acelerados. Logstash transforma y prepara dinámicamente sus datos sin
importar el formato o la complejidad (Elasticsearch , 2018).
En el proyecto en desarrollo se utilizó Logstash gracias a la conversión de formatos de
entrada en otro formato de salida que acepte nuestro motor de búsqueda Elasticsearch, la
conversión de los formatos de salida y los filtros que se emplean para procesar eventos
los cuales sirven para la detección de fallas del sistema.
4.2.6.3. Kibana
Kibana es una plataforma que permite visualizar los datos de búsqueda de Elasticsearch
y navegar por el Elastic Stack. Kibana da la libertad de seleccionar la forma en que da
forma a sus datos. Esta herramienta presenta los datos haciendo uso de: histogramas,
gráficos de líneas, gráficos circulares, rayos solares y más. Kibana da forma a los datos
con elementos visuales que pueden combinarse en paneles personalizados que permiten
compartir información (a partir de sus datos), en cualquier equipo terminal conectado a
internet
Kibana permite la visualización y el manejo de toda la información que se encuentra
almacenada en Elasticsearch, posibilita la configuración de uno o varios dashboard
(representación gráfica de principales métricas) con la información útil para el usuario,
aplicación de filtros para búsqueda, presentación de datos y también faculta la exportación
de resultados. (Elasticsearch , 2018).
La herramienta Kibana se usó en el presente proyecto para el diseño de la interfaz web
haciendo uso de los “dashboard” para que el usuario de forma intuitiva, visualice los
parámetros electro-energéticos más relevantes de los equipos de control y respaldo de
energía eléctrica en tiempo real.
54
CAPÍTULO 3: PLANTA DE SUMINISTRO ELÉCTRICO DEL SIS ECU911
LOJA.
4.3. Ubicación de los Equipos de la Planta Electro-Energética.
El edificio en donde se encuentra operando el SIS ECU 911 Loja se encuentra ubicado en
la parroquia Sucre, sector Turunuma en la avenida Barcelona, como se indica en la Figura
27.
Figura 27. Ubicación geográfica del SIS ECU 911 Loja.
Fuente: Google Maps.
La infraestructura del SIS ECU 911 Loja cuenta con dos plantas. La planta baja, está
destinada a llevarse a cabo todas las operaciones de control, coordinación y
videovigilancia, además, de ubicarse los sectores críticos (“cargas críticas”) del ECU 911
como son: data center, bases de datos, sistema de control y respaldo de energía eléctrica,
circuitos cerrados de televisión (CCTV), sala de operación y control, y la sala de video-
vigilancia. En la primera planta, se llevan a cabo todas las gestiones administrativas del
ECU 911.
El presente proyecto, se centra específicamente en los equipos que integran el sistema de
control y respaldo del suministro eléctrico del edificio, los cuales deben llevar un
constante monitoreo debido a que alimentan a las cargas críticas del SIS ECU 911 antes
55
mencionadas. Es por ello que, la presenta investigación se centra en la planta electro-
energética del edificio en donde los equipos de control y respaldo de energía eléctrica
forman una parte integral y fundamental en todo el sistema eléctrico que alimenta al
mismo.
El grupo electrógeno que integran la planta de suministro eléctrico del SIS ECU 911 Loja
en el cual se desarrolló el presente problema de investigación se encuentra dividido en las
siguientes zonas:
• Cuarto de Generadores
• Cuarto de Energía Regular
• Cuarto de Distribución Eléctrica
Figura 28. Planta Baja del SIS ECU 911 Loja.
Fuente: Autor.
En la Figura 28 se observa la ubicación de los distintos cuartos donde se encuentran los
equipos de control y respaldo de energía eléctrica del edificio SIS ECU 911 Loja, así
como la oficina correspondiente a la Dirección Tecnológica, donde se ubica el equipo
maestro del software de monitoreo del presente proyecto. Es importante mencionar que
la imagen que se muestra en la Figura 28, no muestra toda la planta baja, si no la parte en
donde se enfoca las secciones de interés y relevancia para el presente proyecto.
56
Para entender como está relacionado todos estos cuartos correspondientes al sistema
eléctrico, se presenta a continuación el diagrama unifilar eléctrico simplificado de toda la
infraestructura del ECU 911 Loja.
Figura 29. Diagrama Unifilar del Sistema Eléctrico del SIS ECU 911 Loja.
Fuente: Autor.
57
Figura 30. Simbología del Diagrama Unifilar del Sistema Eléctrico del SIS ECU 911 Loja.
Fuente: Autor.
En este diagrama no se especifica o detalla todos los componentes que intervienen en el
sistema eléctrico por cuestiones de seguridad y políticas de privacidad que maneja la
institución, es por ello, que como información adicional el sistema eléctrico cuenta con
disyuntores diferenciales los cuales están diseñados para proteger a las personas en caso
de que alguna persona sufra una descarga eléctrica, los cuales, por las razones antes
mencionadas, no se detallan en el esquema antes indicado.
58
4.3.1. Cuarto de Generadores
El cuarto de generadores está conformado por dos generadores eléctricos como se indica
en la Figura 31.
Figura 31. Cuarto de Generadores.
Fuente: Autor.
Cada uno de estos generadores son controlados y puestos en marcha automáticamente por
los módulos DSE7320 en caso de algún corte o falla del suministro eléctrico proveniente
de la red. El Generador 1 se encarga de abastecer de energía eléctrica a las cargas críticas
las cuales hacen referencia al centro de datos (Data Center), la sala de operaciones y la
sala de video y vigilancia. EL generador 2 se encarga de proporcionar el suministro
eléctrico a las cargas no críticas, es decir las correspondientes a la planta administrativa
del SIS ECU 911 Loja.
Básicamente, el funcionamiento o puesta en marcha de estos generadores se da cuando al
momento de presentarse una falla o corte del suministro eléctrico proveniente de la red
del proveedor, se inician los generadores pero no se conectan inmediatamente a la red
eléctrica interna del edificio, ya que primero deben normalizarse los valores o parámetro
eléctricos para soportar la carga, por lo que, inmediatamente después de algún corte de
energía se conectan los UPS ya que estos proporcionan un suministro eléctrico estable
proveniente de sus baterías. Una vez normalizado los valores de voltaje y frecuencia
producidos por los generadores, estos se conectan a la red interna del edificio SIS ECU
911 Loja.
59
Figura 32. Generador 1 de operaciones controlado por el módulo DSE7320.
Fuente: Autor.
En las Figura 32 y Figura 33 se muestran los módulos de control DSE7320 que ponen en
marcha ya sea de manera manual o automática los generadores eléctricos 1 y 2 que
controlan las diferentes zonas del edifico del SIS ECU 911 Loja. Por razones prácticas se
procede a indicar que se hace referencia a los módulos DSE7320 por cada generador que
controla, es decir que en el software de monitoreo se identifica por generador 1 y
generador 2 a cada uno de estos módulos automáticos que los monitorea y controla.
Figura 33. Generador 2 controlado por el módulo DSE7320.
Fuente: Autor.
A continuación, se indican las especificaciones técnicas de cada generador en la Tabla 9:.
Debido a que cada generador se trata del mismo modelo, se indica una sola tabla.
60
Tabla 9:
Especificaciones Técnicas de los Generadores 1 y 2.
MARCA: STAMFORD EXCITATION VOLTAGE 57.0
BASE RATING kVA 281.0(BR) EXCITATION CURRENT 2.5
BASE RATING kW 224.8 INSULATION CLASS CLASS H
AMPERES BR 737.5 AMBIENT TEMPERATURE 41 °C
FREQUENCY 60 HERTZ TEMPERATURE RISE 125 K
RPM 1800 THERMAL
CLASSIFICATION 100(H)
VOLTAGE 220 ENCLOSURE IP23
PHASE 3 STATOR WINDING 311
PF 0.80 STATOR CONNECTION PARALLEL STAR
Fuente: Autor.
4.3.2. Cuarto de Distribución Eléctrica
El cuarto de distribución eléctrica del SIS ECU911 Loja que se observa en la Figura 34,
como su nombre lo indica se encarga de distribuir la energía eléctrica de manera eficiente
a todas las cargas críticas y no críticas del edificio.
Figura 34. Cuarto de Distribución Eléctrica del SIS ECU911 Loja.
Fuente: Autor.
Analizador
de Red
DucaLCD96
485-RELÉ
Analizador
de Red
DucaLCD96
485-RELÉ
Analizador
de Red
DucaLCD96
485-RELÉ
61
Uno de los componentes que conforman el cuarto de distribución eléctrica, son los
analizadores de red DUCA-LCD96 485-RELÉ, los cuales cumplen las funciones de
monitorear y analizar las principales magnitudes eléctricas que indican la calidad de la
energía eléctrica que está entrando desde la red del proveedor, así como también indica
el consumo total de la red interna y sus principales medidas eléctricas.
Figura 35. Analizadores de red DUCA-LCD96 485-RELÉ del cuarto de distribución eléctrica del
ECU911 Loja.
Fuente: Autor.
En la Figura 35, se puede observar que cada analizador de red se encuentra identificado
por el sector que se encuentra supervisando, por lo que de izquierda a derecha se
encuentra el tablero 1 de servicios generales que se encargan de supervisar las cargas no
críticas, luego el tablero 2 de los UPS y finalmente el tablero 3 de operaciones encargado
de las cargas críticas.
4.3.3. Cuarto de Energía Regular
El cuarto de energía regular está conformado por dos sistemas de energía ininterrumpidos
EATON 9390 UPS, como lo indica la Figura 36. El UPS 1 cumple un rol muy importante
dentro de la planta de suministro eléctrico del Edificio del ECU911 Loja, ya que, es el
encargado de intervenir inmediatamente al momento de surgir un corte de energía
eléctrica de la red pública para abastecer de energía a través de sus baterías a las cargas
críticas antes mencionadas. El UPS 2 funciona como respaldo en caso de presentar alguna
falla o problema y no responda a cualquier percance que se presente con el UPS 1. De tal
manera el UPS 1 se encuentra activo mientras que el UPS 2 se encuentra en stand-by a la
espera de cualquier problema que pueda presentar el UPS 1, respondiendo de manera
automática. En la Figura 37 se observa los paneles de control de los UPS 1 y 2.
Tablero de Servicios
Generales
Tablero
UPS Tablero
Operaciones
62
Figura 36. UPS EATON 9390 del cuarto de energía regular del SIS ECU911 Loja.
Fuente: Autor.
Figura 37. Paneles de control de los UPS EATON 9390. a) UPS 1 se encuentra en estado activo; b) UPS
2 se encuentra en estado Stand-by.
Fuente: Autor.
4.3.4. Equipos de Control de Suministro y Respaldo de Energía Eléctrica
Los equipos que se encargan de la distribución, control y respaldo del sistema eléctrico
del SIS ECU911 Loja son los siguientes:
• Analizador de Red Duca-LCD96 485-RELÉ.
• Módulo DSE7320
• Eaton 9390 UPS
Estos equipos se encontraban ya instalados en la planta de suministro eléctrico antes de
empezar el desarrollo de este proyecto, por lo que, se partió de analizar las interfaces y
protocolos de comunicación en común para poder integrarlos al sistema de monitoreo en
tiempo real del cual versa el presente proyecto.
a) b)
63
4.3.4.1. DUCA-LCD96 485-RELÉ
El analizador de red DUCA-LCD96, mostrado en la Figura 38, es un instrumento de
medición de las principales magnitudes eléctricas, en redes trifásicas y monofásicas,
proyectado para la monitorización y el análisis en local o en remoto de parámetros
eléctricos de la instalación en cuadros de baja y media tensión; y consumos de energía de
la instalación.
Figura 38. Analizador de red DUCA-LCD96.
Fuente: (DUCATI Energia SpA., 2018).
Todos los modelos de la serie DUCA-LCD96 son capaces de medir y elaborar las
magnitudes abajo indicadas.
• Tensiones (fase-neutro y concatenadas) y sus correspondientes valores de pico.
• Corrientes y sus correspondientes valores de pico.
• Potencias activas, reactivas y aparentes de fase y del sistema trifásico en 2 y 4
cuadrantes.
• Factor de potencia o PF de fase y del sistema trifásico, con iconos de distinción
entre carga inductiva y carga capacitiva.
• Frecuencia (medida sobre la fase L1-N).
• Energías activas, reactivas y aparentes de fase y del sistema trifásico en 2
cuadrantes (con función de reconocimiento automático del sentido de los TA).
64
• Energías activas, reactivas y aparentes de fase y del sistema trifásico en 4
cuadrantes (monitorización de la energía absorbida y generada por el sistema).
• Valores medios de las potencias en un periodo de tiempo programado por el
usuario.
• Máxima demanda calculada sobre la potencia activa y aparente.
• THDF de tensión y corriente expresados en valor absoluto y porcentual.
• Cuenta horas de funcionamiento total con incremento T1 y cuenta horas parcial
con decremento T2.
• Saldo de las energías activa, reactiva y aparente del sistema trifásico, saldo =
energía absorbida - energía generada.
• Saldo de las energías activa, reactiva y aparente "parciales" del sistema trifásico
en 4 cuadrantes en un periodo programable por el usuario, saldo = energía
absorbida - energía generada.
A continuación, se describen las especificaciones técnicas de interés para el desarrollo de
este proyecto.
a) Dimensiones generales
Figura 39. Dimensiones del dispositivo DUCA-LCD96.
Fuente (DUCATI Energia SpA., 2018)
b) Modelos
65
Tabla 10:
Modelos del Duca-LCD96.
Modelos Salidas y entradas
Protocolo de
comunicación
serial
DUCA-LCD96 2 salidas programables como impulsos o alarma de
umbral
DUCA-LCD96 485 2 salidas programables como impulsos o alarma de
umbral Modbus RTU
DUCA-LCD96-ETH 2 salidas programables como impulsos o alarma de
umbral Modbus TCP/IP
DUCA-LCD96-PROFI 2 salidas programables como impulsos o alarma de
umbral Profibus DP
DUCA-LCD96 485-
RELE
2 salidas de relé electromecánicos 16A AC1 - 3A AC15
2 salidas programables como impulsos o alarma de
umbral
Modbus RTU
DUCA-LCD96 485-IO
2 salidas analógicas 4 -20 mA
3 entradas para lectura de impulsos externos
2 salidas programables como impulsos o alarma de
umbral
Modbus RTU
DUCA-LCD96 BASE 2 salidas programables como
impulsos o alarma de umbral.
Entradas de corriente a través de Shunt.
Fuente: (DUCATI Energia SpA., 2018)
Como se indicó anteriormente el modelo instalado en el sistema eléctrico del SIS ECU
911 Loja es el DUCA-LCD96 485-RELÉ, el cual presenta el protocolo de comunicación
Modbus RTU, como se indica en la Tabla 10:. Es importante aclarar la importancia que
tiene esta tabla, ya que ella podemos identificar el modelo del equipo con el que se está
trabajando y por ende saber que protocolos de comunicación utiliza para acceder a los
datos de estos dispositivos de manera remota, en este caso con el software de monitoreo
desarrollado en la presente investigación.
c) Datos técnicos
A continuación, se indican las características de la interfaz de comunicación relevantes
para el desarrollo del presente proyecto. Para visualizar todos los aspectos referentes a la
comunicación del equipo consulte el anexo 1.
Tabla 11:
Interfaz de comunicación RS485 del DUCA-LCD96 485-RELÉ.
Protocolo Modbus RTU o ASCII Ducati
Estándar eléctrico RS485 con opto aislamiento
Tasa de baudios 4.8, 9.6, 19.2 kbps
Número de paridad Pares, Impares, Ninguna (Odd, Even, None)
Bit de stop 1, 2
Dirección 1-247 para Modbus RTU; 1-98 para ASCII Ducati
Conector Borne de 4 polos (terminación de 120 Ohm integrada)
Fuente: (DUCATI Energia SpA., 2018).
66
d) Conexiones
Figura 40. Duca-LCD96 (vista posterior).
Fuente: (DUCATI Energia SpA., 2018)
Figura 41. Conexión de la salida RS485 (BSAT) del Duca-LCD96.
Fuente: (DUCATI Energia SpA., 2018)
e) Variables electro-energéticas del analizador de red DUCA-LCD96 485-
RELÉ
Las variables electro-energéticas, con sus respectivas direcciones Modbus del analizador
de red Duca-LCD96 485-RELE, consideradas para la monitorización en tiempo real por
requerimiento del SIS ECU911 Loja fueron las siguientes:
Tabla 12:
Variables Electro-Energéticas del DUCA-LCD96 485-RELÉ.
No.
Dirección
(registro
Modbus)
Tamaño
(Byte) Variable Unidad
Formato
(Long)
1 0002 2 Frecuencia Decenas
de Hz sin signo
2 0004 2 Voltaje Equivalente de Tres Fases V sin signo
3 0006 2 Voltaje de Línea (línea 1 - línea 2) V sin signo
4 0008 2 Voltaje de Línea (línea 2 - línea 3) V sin signo
5 0010 2 Voltaje de Línea (línea 3 - línea 1) V sin signo
67
6 0012 2 Voltaje entre la fase y la línea neutra 1 V sin signo
7 0014 2 Voltaje entre la fase y la línea neutra 2 V sin signo
8 0016 2 Voltaje entre la fase y la línea neutra 3 V sin signo
9 0018 2 Corriente equivalente trifásica Centenas
de A sin signo
10 0020 2 Corriente de Línea 1 Centenas
de A sin signo
11 0022 2 Corriente de Línea 2 Centenas
de A sin signo
12 0024 2 Corriente de Línea 3 Centenas
de A sin signo
13 0026 2 Factor de potencia trifásico equivalente Centenas signo/sin
signo
14 0028 2 Factor de potencia línea 1 Centenas signo
15 0030 2 Factor de potencia línea 2 Centenas signo
16 0032 2 Factor de potencia línea 3 Centenas signo
17 0034 2 Potencia activa equivalente trifásica W signo
18 0036 2 Potencia activa equivalente trifásica promedio W signo
19 0038 2 Máxima potencia activa equivalente trifásica W signo
20 0040 2 Línea de energía activa 1 W signo
21 0042 2 Línea de energía activa 2 W signo
22 0044 2 Línea de alimentación activa 3 W signo
23 0046 2 Promedio de la línea de energía activa 1 W signo
24 0048 2 Promedio de la línea de energía activa 2 W signo
25 0050 2 Promedio de la línea de potencia activa 3 W signo
26 0052 2 Línea de potencia máxima activa 1 W signo
27 0054 2 Línea de potencia máxima activa 2 W signo
28 0056 2 Línea de potencia máxima activa 3 W signo
29 0058 2 Potencia aparente equivalente trifásica VA signo
30 0060 2 Promedio de potencia aparente equivalente trifásica VA sin signo
31 0062 2 Máxima potencia aparente equivalente trifásica VA sin signo
32 0064 2 Línea de potencia aparente 1 VA sin signo
33 0066 2 Línea de potencia aparente 2 VA sin signo
34 0068 2 Línea de potencia aparente 3 VA sin signo
35 0070 2 Línea de potencia aparente promedio 1 VA sin signo
36 0072 2 Línea de potencia aparente promedio 2 VA sin signo
37 0074 2 Promedio de la línea de potencia aparente 3 VA sin signo
38 0076 2 Línea de potencia aparente máxima 1 VA sin signo
39 0078 2 Línea de potencia aparente máxima 2 VA sin signo
40 0080 2 Línea de potencia aparente máxima 3 VA sin signo
41 0082 2 Potencia reactiva equivalente trifásica VAr signo
68
42 0084 2 Potencia reactiva equivalente trifásica promedio VAr signo
43 0086 2 Máxima potencia reactiva equivalente trifásica VAr signo
44 0088 2 Línea de potencia reactiva 1 VAr signo
45 0090 2 Línea de potencia reactiva 2 VAr signo
46 0092 2 Línea de potencia reactiva 3 VAr signo
47 0094 2 Línea de potencia reactiva media 1 VAr signo
48 0096 2 Línea de potencia reactiva media 2 VAr signo
49 0098 2 Línea de potencia reactiva media 3 VAr signo
50 0100 2 Línea de potencia reactiva máxima 1 VAr signo
51 0102 2 Línea de potencia reactiva máxima 2 VAr signo
52 0104 2 Línea de potencia reactiva máxima 3 VAr signo
53 0106 2 Energía activa equivalente trifásica Decena
de Wh sin signo
54 0108 2 Línea de energía activa 1 Decena
de Wh sin signo
55 0110 2 Línea de energía activa 2 Decena
de Wh sin signo
56 0112 2 Línea de energía activa 3 Decena
de Wh sin signo
Fuente: (DUCATI Energia SpA., 2018).
Las variables electro-energéticas, mostradas en la tabla anterior, se escogieron mediante
una reunión con el ingeniero Juan Pablo Cabrera encargado de supervisar la planta de
suministro eléctrico del SIS ECU 911 Loja, bajo los criterios de calidad de energía
eléctrica y consumo de energía eléctrica. Bajo los mismos criterios se eligieron las
variables electro-energéticas para los demás equipos de control y respaldo de energía
eléctrica que se seleccionaron en la presente investigación.
Las variables electro-energéticas completas que este equipo permite medir se indican en
el anexo 4.
f) WinSmart – Ducati Energía
El programa WinSmart, es un paquete de software simple que le permite ver algunas de
las principales mediciones realizadas por los instrumentos Ducati, disponibles a través de
la interfaz RS485 en serie o Ethernet (DUCATI Energia SpA., 2018). Puede utilizar uno
de los siguientes instrumentos que tienen la interfaz Rs485 o Ethernet:
• Serie MACH30
• Serie MACH Smart
69
• Serie SMART Plus
• Serie DUCA47 (72-SP) modelo serial
• Serie DUCA-LCD96, DUCA-LCD
• Serie RMI / Rego
Figura 42. Ventana principal del software WinSmart – Ducati Energía.
Fuente: Autor.
Figura 43. Ventana de configuración del WinSmart – Ducati Energía.
Fuente: Autor.
Este software de visualización gratuito permite, mostrar solo un instrumento a la vez y
permite guardar los datos leídos en un archivo de texto en formato .csv. Para funciones
de red más avanzadas, almacenamiento de datos, gráficos, etc., debe utilizar el paquete
WarpNet Ducati. El programa WarpNet Ducati, es software privativo por lo que para su
uso se necesita adquirir una licencia de uso, el cual no permite modificar su código fuente
70
para poder agregar las funciones como en este proyecto se requieren, además de generar
gastos para el ECU 911.
4.3.4.2. Módulo DSE7320
Los tableros automáticos desarrollados para los generadores eléctricos, tienen la
capacidad de automatizar la puesta en marcha de los generadores eléctricos. El generador
eléctrico hoy en día, está diseñado para la adaptación de dichos tableros. Los generadores
eléctricos de emergencia brindan energía eléctrica cada vez que se presenta una falla en
el suministro de red.
Existen equipos, capaces de automatizar el trabajo de la puesta en marcha de los
generadores eléctricos ante un fallo en el suministro, se denominan tableros automáticos.
Estos, ponen en marcha un generador eléctrico, cada vez que, por cualquier motivo, se
corta la energía eléctrica. Algunos de ellos necesitan de una activación previa, y otros, lo
hacen de manera automática (Tecnoplus, 2018).
Figura 44. Módulo DSE7320.
Fuente: (Manton, 2009)
El DSE7320, observe la Figura 44, es un Módulo de Control de Fallo de Red (dispositivo)
idóneo para una amplia gama de aplicaciones de grupos electrógenos, con motor diesel o
de gas. Monitoriza un gran número de parámetros del motor, este módulo visualiza
advertencias, paradas e información sobre el estado del motor en la pantalla LCD
retroiluminada, mediante indicadores luminosos LED, mediante ordenador o enviando
mensajes SMS de alerta (con módem externo). Estos módulos pueden ser configurados
71
fácilmente utilizando el software para PC DSE Configuration Suite. La configuración
también se puede modificar en el panel frontal (Tecnoplus, 2018).
a) Características Generales
• Display Gráfico LCD con iluminación en verde
• Programación protegida mediante número PIN
• Idiomas configurables en pantalla
• 9 entradas + 8 salidas digitales configurables
• Alarmas y temporizadores configurables
• Registro de eventos configurables (250)
• Editor de PLC
• Página de diagnóstico de fácil acceso
• Monitor de uso de combustible y las alarmas de nivel bajo de combustible
• Alarma de fallo de cargador de batería
• Control de velocidad manual (en los motores “CAN compatible”)
• Control manual de la bomba de combustible
• LED de indicación de alarma vía LCD
• Soporte carga (kW h, kV Ar,kV A h, kV Ar h)
• Conmutación de carga (load shedding and dummy load outputs)
• Transferencia de carga automática
• Protección de carga desequilibrada (Tecnoplus, 2018).
Para visualizar las especificaciones técnicas completas del equipo consulte el anexo 2.
72
b) Dimensiones
Figura 45. Dimensiones del módulo DSE7320.
Fuente: (Manton, 2009).
c) Modelos
Tabla 13:
Modelos de la serie DSE7000.
Nombre corto Descripción
DSE7000 Todos los módulos en la serie DSE7000
DSE7x10 Todos los módulos de arranque automático en la serie DSE7000
DSE7x20 Todos los módulos con Falla de red en la serie DSE7000
DSE72x0 Todos los módulos en la serie DSE7200
DSE73x0 Todos los módulos en la serie DSE7300
Fuente: (Manton, 2009).
Figura 46. Modelos de la serie DSE7000.
Fuente: (Manton, 2009).
Como se indicó anteriormente el modelo instalado en el sistema eléctrico del SIS ECU
911 Loja es el módulo DSE7320.
d) Interfaz y Protocolos de Comunicación
73
Tabla 14:
Interfaz y protocolos de comunicación soportados por el módulo DSE7320.
Puerto Características Descripción
USB
Dispositivo USB2.0 para conexión a una PC ejecutando el
software DSE Configuration Suite. Distancia máxima 6m
(20 pies)
Cable USB Tipo A - Tipo B.
RS232
Puerto no aislado.
Máxima velocidad de comunicación 115Kbs sujeto a S/W
TX, RX, RTS, CTS, DSR, DTR, DCD
Conector macho de 9 pines.
Soporta el protocolo Modbus
RTU. RS232 es para
comunicación a corta distancia
(máximo 15m).
RS485
Aislado
Conexión de datos 2 hilos + común
Half Dúplex
Control de Dirección de datos (mediante protocolo s/w)
Máxima velocidad de comunicación 19200 Kbs
Terminación externa requerida (120Ω)
Máxima compensación modo común 70V (protección en
tarjeta)
Distancia máxima 1.2km (¾ de milla)
Soporta el protocolo Modbus
RTU. Conexión de cable punto
a punto de más de un
dispositivo (máximo 32
dispositivos) y permite la
conexión a
PC´s, PLC´s y sistemas de
gestión y adquisición de datos
(SCADA).
CAN
Puerto de Motor CAN
Implementación Standard de ‘Slow mode’, hasta 250Kbs
No aislado.
Terminación Interna proporcionada (120Ω)
Máxima distancia 40m (133 pies)
Transporta los datos
recopilados por la interface de
controlador de motor. Esto
permite a los módulos de la
serie DSE7000 acceder a los
parámetros del motor sin
conexión física con el
dispositivo sensor.
Fuente: (Manton, 2009).
e) Conexiones
Para la identificación y correcta conexión en las interfaces de comunicación se indica en
la Figura 47 los iconos de la parte trasera del módulo, así como también las funciones de
las demás terminales.
Figura 47. Terminales del módulo DSE7320.
Fuente: (Manton, 2009)
74
Tabla 15:
Descripción de las terminales RS485 y RS232 del DSE7320.
CONECTOR RS485
No. De Pin Notas
A (+) Par trenzado blindado.
120Ω de impedancia adecuado para uso RS485. B (-)
SCR (GND)
CONECTOR RS232
No. De Pin Notas
1 Detección de portadora (transmisión de datos)
2 Recibir
3 Transmitir
4 Terminal de datos lista
5 Señal de tierra
6 Ajuste de datos listo
7 Solicitud para transmitir
8 Listo para enviar
9 Indicador de llamada (solo modem)
Vista del conector macho RS232 en el módulo serie
7320.
Fuente (Manton, 2009).
La información mostrada en las Tabla 14: y Tabla 15:, indican las interfaces y protocolos
de comunicación que presentan estos módulos de control automático, gracias a ello, se
logró identificar que interfaces y protocolos utilizar para establecer la comunicación con
el software de monitoreo, junto con los demás equipos, en la misma infraestructura de
comunicación.
f) Variables electro-energéticas del módulo DSE7320.
Las variables electro-energéticas del módulo de control automático DSE7320
consideradas para la monitorización en tiempo real por requerimiento del SIS ECU911
Loja fueron las siguientes:
75
Tabla 16:
Variables Electro-Energéticas del módulo DSE7320.
No. Registro Variable Valor
mínimo
Valor
máximo
Factor
escala Unidad
Bits/
signo
1 1024 Presión del aceite 0 10 000 1 KPa 16
2 1025 Temperatura del refrigerante -50 150 1 DegC 16 S
3 1028 Voltaje del alternador de
carga 0 40 0.1 V 16
4 1029 Voltaje de la batería 0 40 0.1 V 16
5 1030 Velocidad del motor 0 6 000 1 RPM 16
6 1031 Frecuencia del generador 0 70 0.1 Hz 16
7 1032 Generador de voltaje L1-N 0 18 000 0.1 V 32
8 1034 Generador de voltaje L2-N 0 18 000 0.1 V 32
9 1036 Generador de voltaje L3-N 0 18 000 0.1 V 32
10 1038 Tensión del generador L1-L2 0 30 000 0.1 V 32
11 1040 Tensión del generador L2-L3 0 30 000 0.1 V 32
12 1042 Tensión del generador L3-L1 0 30 000 0.1 V 32
13 1044 Corriente del generador L1 0 99 999.9 0.1 A 32
14 1046 Corriente del generador L2 0 99 999.9 0.1 A 32
15 1048 Corriente del generador L3 0 99 999.9 0.1 A 32
16 1050 Corriente de tierra del
generador 0 99 999.9 0.1 A 32
17 1052 Generador L1 vatios -9 999
999
99 999
999 1 W 32 S
18 1054 Generador L2 vatios -9 999
999
99 999
999 1 W 32 S
19 1056 Generador L3 vatios -9 999
999
99 999
999 1 W 32 S
20 1057 Generador actual lag/lead -180 +180 1 Degrees 16 S
Fuente: (Manton, 2009).
La lectura de los registros del módulo DSE7320, generalmente devuelve los datos de
instrumentación que solicita. Sin embargo, a veces se devuelven otros valores, estos se
denominan valores “centinela” y se detallan en la Tabla 16:. Por ejemplo, si el transmisor
de presión de aceite es detectado como un circuito abierto por el módulo, la lectura de la
dirección 0x0400 (registro 1024) devolverá el valor de centinela 0xFFFC, que significa
"Fallo del transductor" (Manton, 2009).
Tabla 17:
Valores de Centinela del módulo DSE7320.
Tamaño del
registro
Valor Centinela (decimal) Descripción
16 bit sin
signo
0xFFFF (65 535) No implementado
0xFFFE (65 534) Sobre el rango medible
0xFFFD (65 533) Bajo el rango medible
0xFFFC (65 532) Falla del transductor
0xFFFB (65 531) Datos dañados
0xFFFA (65 530) Entrada digital alta
0xFFF9 (65 529) Entrada digital baja
0xFFF8 (65 528) Reservado
76
16 bit con
signo
0x7FFF (32 767) No implementado
0x7FFE (32 766) Sobre el rango medible
0x7FFD (32 765) Bajo el rango medible
0x7FFC (32 764) Falla del transductor
0x7FFB (32 763) Datos dañados
0x7FFA (32 762) Entrada digital alta
0x7FF9 ( 76132 ) Entrada digital baja
0x7FF8 (32 760) Reservado
32 bit sin
signo
0xFFFFFFFF ( 2954 294 967 ) No implementado
0xFFFFFFFE (4 294 967 294) Sobre el rango medible
0xFFFFFFFD ( 967 293)4 294 Bajo el rango medible
0xFFFFFFFC (4 294 967 292) Falla del transductor
0xFFFFFFFB (4 294 967 291) Datos dañados
0xFFFFFFFA (4 294 967 290) Entrada digital alta
0xFFFFFFF9 (4 294 967 289) Entrada digital baja
0xFFFFFFF8 (4 294 967 288) Reservado
32 bit con
signo
0x7FFFFFFF (2 147 483 647) No implementado
0x7FFFFFFE (2 147 483 646) Sobre el rango medible
0x7FFFFFFD (2 147 483 645) Bajo el rango medible
0x7FFFFFFC (2 147 483 644) Falla del transductor
0x7FFFFFFB (2 147 483 643) Datos dañados
0x7FFFFFFA (2 147 483 642) Entrada digital alta
0x7FFFFFF9 (2 147 483 641) Entrada digital baja
0x7FFFFFF8 (2 147 483 640) Reservado
Fuente: (Manton, 2009).
Las variables electro-energéticas y valores centinela completas que este equipo permite
medir se indican en el anexo 5.
g) DSE CONFIGURATION SUITE
Las unidades controladoras DSE, son configuradas y monitoreadas conectándolas a
computadoras personales a través de USB, accediendo a sus parámetros operativos. La
suite (Figura 48) detecta automáticamente los dispositivos compatibles y visualiza, edita
o restaura por defecto la configuración de los módulos de servicio activos.
77
Figura 48. Software DSE Configuration Suite.
Fuente: Autor.
Una vez conectados, los diversos parámetros operativos dentro del módulo se pueden ver
o editar según lo requiera el usuario. Esta herramienta permite un acceso controlado fácil
a estos valores y también cuenta con instalaciones de monitoreo de diagnóstico. Este
software es privativo por lo que para su uso se necesita haber adquirido un equipo de este
fabricante para poder acceder a dicho software, el cual no permite modificar su código
fuente para poder agregar las funciones como en este proyecto se requieren.
4.3.4.3. Eaton 9390 UPS
El Eaton 9390, es un sistema de potencia ininterrupible de doble conversión. El sistema
(UPS) resuelve todos los problemas de energía de la red pública y suministra energía
limpia, continua e ininterrumpida a los equipos conectados. Ya sea que, esté
seleccionando un UPS para una sucursal, planta de fabricación, instalación médica o
centro de datos, ofrece una combinación perfecta de rendimiento.
78
Figura 49. EATON9390 UPS de 100-160 kVA.
Fuente (EATON, 2018)
a) Especificaciones técnicas
Para visualizar las especificaciones técnicas completas del equipo consulte el anexo 3.
Tabla 18:
Especificaciones técnicas del EATON 9390 UPS.
Rango de energía 40-160 kVA
Voltaje 208-380-400-415-480-600V
Frecuencia 50/60 Hz
Configuración Torre
Serie del Producto Powerware
Fuente: (EATON, 2018).
b) Modelos
• Eaton 9390 (40-160 kVA) modelo americano.
• Eaton 9390 (40-160 kVA) modelo europeo.
El modelo instalado en la planta de suministro eléctrico del SIS ECU 911 Loja es el
americano.
c) Características generales
• Clasificación de alta eficiencia que baja considerablemente el costo total de
propiedad. El poco espacio que ocupa y el poco peso reducen los costos de
transporte e instalación.
79
• Gran rendimiento de energía con control de factor de energía activa (PFC)
proporciona un factor de energía de entrada de 0.99 inmejorable y minimiza
ITHD. Esto reduce en gran medida la interconexión con otro equipo y mejora la
compatibilidad 9390 UPS con generadores.
• Incorpora la tecnología de sincronización HotSync de Powerware que permite que
9390 UPS se sincronice tanto para redundancia como para capacidad. Las
opciones avanzadas de sincronización también aseguran que el sistema UPS
pueda adaptarse fácilmente a requisitos de energía cada vez mayores.
• Respaldo confiable con tiempos de ejecución modificables se mejoran con el
Advanced Battery Management (ABM™) y las opciones de auto-prueba de
batería UPS que prolongan la vida útil de la batería y ayudan a detectar cualquier
defecto en las baterías que ya están en fase preliminar.
• Capacidad sólida de administración se distribuye con control avanzado y opciones
de conectividad y con oferta de servicio superior (EATON, 2018).
d) Dimensiones
Tabla 19:
Dimensiones y peso del EATON 9390 UPS.
Módulos 40 - 80 kVA
Dimensiones (LxDxA) / Peso 8.9" x 31.6" x 73.7" / 600 lbs
Módulos 120 - 160 kVA
Dimensiones (LxDxA) / Peso 35.6" x 31.6" x 73.7" / 950 lbs
Fuente: (EATON, 2018).
e) Interfaz y protocolos de comunicaciones
Tabla 20:
Interfaz y protocolos de comunicaciones del EATON 9390 UPS.
Softwares compatibles PowerVision®, LanSafe™, FORESEER®
Tarjetas de
Comunicación
Dos X-Slots standard. Con la opción Mini-CSB: hasta 4 XSlots. Las
siguientes opciones de tarjetas de conectividad pueden ser instaladas en
cualquier momento:
Tarjeta ConnectUPS Web/SNMP/xHub
Tarjeta Modbus
Tarjeta Relay Interface (Para AS400 's)
Tarjeta Industrial Relay (5A@120V)
Tarjeta Paralelo proporciona comunicación CAN, porta aislada
RS-484
Censor de Monitoreo Ambiental (EMP)
Entradas/Salidas remotas Dos alarmas externas y un contacto de alarma general (5A@120V). Con la
opción Mini-CSB, cuatro alarmas externas adicionales disponibles
80
Panel de Monitoreo
Remoto
8 lámparas indicadoras más una señal de alarma acústica
Fuente: (EATON, 2018).
El UPS EATON 9390, instalado en el SIS ECU Loja, cuenta con la tarjeta de UPS Power
Xpert® Gateway (Figura 50) la cual permite conectar el UPS directamente a su red
Ethernet e Internet. Con su servidor web incorporado, la tarjeta UPS Power Xpert
Gateway proporciona información de UPS de forma remota, sin software adicional a
través de los protocolos de comunicación HTTPS y Modbus sobre TCP/IP.
Figura 50. Tarjeta de comunicación de UPS Power Xpert® Gateway.
Fuente: (EATON, 2018)
f) Variables electro-energéticas del EATON 9390 UPS
Las variables electro-energéticas del UPS EATON 9390, consideradas para la
monitorización en tiempo real por requerimiento del SIS ECU 911 Loja, fueron las
siguientes:
Tabla 21:
Variables Electro-Energéticas del EATON 9390 UPS.
No. Registro Variable Unidad Tipo Estados
1 1137 Check Battery Alarma Booleano (0, 1)
2 1148 UPS On Battery Alarma Booleano (0, 1)
3 2800 Battery Test in Progress Test Entero (0, 1)
4 2801 Battery Test Result Test Entero (0,1,2,3,4,5,6,7)
5 3000 System Status Test Entero (0,1,2,3,4,5,6,7,8)
6 3002 Output State Test Entero (0,1,2,3,4,5,6,7,8)
7 3005 Horn Status Test Entero (0, 1, 2, 3)
8 4040 Va-n Input V Flotante N/A
9 4042 Vb-n Input V Flotante N/A
81
10 4044 Vc-n Input V Flotante N/A
11 4046 Va-n Output V Flotante N/A
12 4048 Vb-n Output V Flotante N/A
13 4050 Vc-n Output V Flotante N/A
14 4058 Va-n Bypass V Flotante N/A
15 4060 Vb-n Bypass V Flotante N/A
16 4062 Vc-n Bypass V Flotante N/A
17 4377 Battery Voltage V Flotante N/A
18 5022 Ia Input A Flotante N/A
19 5024 Ib Input A Flotante N/A
20 5026 Ic Input A Flotante N/A
21 5028 Ia Output A Flotante N/A
22 5030 Ib Output A Flotante N/A
23 5032 Ic Output A Flotante N/A
24 6022 P-in W Flotante N/A
25 6024 P-out W Flotante N/A
26 6086 VA-in V-A Flotante N/A
27 6088 VA-out V-A Flotante N/A
28 6184 Full Load % Flotante N/A
29 6202 PF-in Power-factor Flotante N/A
30 6204 PF-out Power-factor Flotante N/A
31 7000 Capacity Remaining % Flotante N/A
32 7871 Input Demand KW Flotante N/A
33 7873 Output Demand KW Flotante N/A
34 11004 Frequency In Hz Flotante N/A
35 11002 Frequency Out Hz Flotante N/A
Fuente: (EATON, 2018).
Las variables electro-energéticas, que son de tipo Alarma y Test, presentan como
respuesta a la consulta realizada por el software maestro diferentes estados como lo indica
la Tabla 21:. A continuación, se describe el significado de cada estado que presentan las
alarmas y test del EATON 9390 UPS en la Tabla 22:. Las variables electro-energéticas y
valores centinela completas que este equipo permite medir se indican en el anexo 6.
Tabla 22:
Estados de las Alarmas y Test del EATON 9390 UPS.
Variable Estado Descripción
Check Battery 0 (Falso) Se ha detectado un problema de batería. Puede necesitar ser
reemplazado. 1 (Verdadero)
UPS On
Battery
0 (Falso) El UPS está extrayendo energía de la batería para alimentar
la carga. Esta alarma no se activa durante los eventos de
batería no alarmantes. 1 (Verdadero)
Battery Test in
Progress
0 (Falso) Una prueba de batería ha comenzado.
1 (Verdadero)
Battery Test
Result
0 (No Test)
Resultado de la última prueba de batería.
1 (In Progress)
2 (Passed)
3 (Aborted)
4 (Failed)
5 (Scheduled)
82
6 (Battery String
Removed)
7 (Battery String Not
Installed)
System Status
0 (Off)
Estado general del sistema.
1 (On)
2 (On Battery)
3 (On Buck)
4 (On Boost)
5 (On Bypass)
6 (Energy Saver
System)
7 (Output Overload)
8 (On Maintenance
Bypass)
9 (Variable Module
Management System)
Output State
0 (Unknown)
Estado de salida del sistema.
1 (On)
2 (Off)
3 (On with pending
Off)
4 (Off with pending
On)
5 (Unknown)
6 (Unknown)
7 (Failed and Closed)
8 (Failed and Open)
Horn Status
0 (Disabled)
Modo de bocina actual 1 (Enabled)
2 (Muted)
3 (Unknown)
Fuente: (EATON, 2018).
83
5. MATERIALES Y MÉTODOS
5.1. Materiales
El presente trabajo se enfoca en el desarrollo de un software que nos permite monitorear
los equipos de control y respaldo de energía eléctrica que integran la planta de suministro
eléctrico del SIS ECU 911 Loja, para lo cual, se interconectaron todos estos equipos entre
sí, para poder visualizar sus variables electro-energéticas en una sola interfaz HMI, para
luego almacenar esta información en una base de datos y finalmente presentarlos en una
interfaz web. Para llevar a cabo esta investigación se utilizaron los siguientes materiales:
• Software Python. Se utilizó el lenguaje de programación Python en su versión
3.6, para el desarrollo del código fuente del programa de monitoreo del cual versa
el presente trabajo, aprovechando sus múltiples librerías tanto propias como de
terceros para la programación de los controladores de cada equipo de control y
respaldo de energía eléctrica (MinimalModbus, pyModbusTCP), la interacción
(parte lógica) de las interfaces gráficas de usuario (PyQt), la conexión a las bases
de datos (psycopg2) entre las más relevantes.
• Qt Designer. Se usó la herramienta Qt Designer en su versión 5.9.5 para la
elaboración de las interfaces gráficas de usuario de manera más práctica y
eficiente, para una interacción más amigable con el usuario.
• PostgreSQL. Se utilizó el software de gestión de base de datos PostgreSQL 10
para la creación de la base de datos y almacenamiento de las variables electro-
energéticas medidas en cada uno de los equipos de control y respaldo de energía
eléctrica.
• Pila ELK. Estos servicios se emplearon para la comunicación con la base de datos
accediendo a los datos para luego procesarlos y presentarlos en una interfaz web.
La validación y verificación de los datos obtenidos con el software de monitoreo diseñado
e implementado en el presente proyecto se realizó a través de la siguiente tabla.
Tabla 23:
Tabla de verificación y validación de los datos obtenidos con el software de monitoreo.
Variable electro-energética Equipo 1
Software Equipo Error (%)
Nombre de la variable Valores alfanuméricos Valores alfanuméricos Error absoluto
porcentual
Fuente: Autor.
84
La Tabla 23:, se elaboró para la verificación y validación de los valores de cada variable
electro-energética entre: a) los valores obtenidos con el software de monitoreo en tiempo
real diseñado en la presente investigación (columna “Software”), b) los valores presentes
en cada equipo físico (columna “Equipo”) y c) cálculo del error absoluto porcentual
(columna “Error) entre a) y b). Esta tabla nos permite verificar si los valores obtenidos se
encuentran dentro del rango normal en la variable energética que se esté midiendo, esto
con el fin, de descartar que se esté presentando un dato de forma errónea. El error absoluto
porcentual, como en su definición lo indica, nos permite saber que tan lejos está un valor
aproximado de uno exacto a través de un porcentaje del valor exacto. Para el cálculo del
error relativo porcentual se utilizó la siguiente formula:
𝑒𝑟𝑟𝑜𝑟 (%) = |𝑣𝑎𝑙𝑜𝑟 𝑚𝑒𝑑𝑖𝑑𝑜 − 𝑣𝑎𝑙𝑜𝑟 𝑟𝑒𝑎𝑙
𝑣𝑎𝑙𝑜𝑟 𝑟𝑒𝑎𝑙| ∗ 100
𝑉𝑎𝑙𝑜𝑟 𝑚𝑒𝑑𝑖𝑑𝑜 = 𝑣𝑎𝑙𝑜𝑟 𝑜𝑏𝑡𝑒𝑛𝑖𝑑𝑜 𝑝𝑜𝑟 𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒. 𝑉𝑎𝑙𝑜𝑟 𝑟𝑒𝑎𝑙 = 𝑣𝑎𝑙𝑜𝑟 𝑜𝑏𝑡𝑒𝑛𝑖𝑑𝑜 𝑝𝑜𝑟 𝑒𝑞𝑢𝑖𝑝𝑜.
Recursos Bibliográficos. Se estudiaron los manuales de funcionamiento, data sheet y
direcciones de registros Modbus de las variables electro-energéticas de los equipos de
control y respaldo de energía eléctrica del SIS ECU 911 Loja. Así como los componentes
utilizados para interconectar dichos equipos (adaptadores de interfaz).
5.2. Métodos
Con respecto a la metodología utilizada para llevar a cabo la ejecución satisfactoria del
presente proyecto se tuvieron en cuenta los siguientes métodos:
Método Científico: Este método se utilizó para la investigación y recolección de datos,
como los data sheet y manuales de uso de los equipos de control y respaldo de energía
eléctrica, protocolos y medios de comunicación de manera confiable, sistemática y
organizada que permitieron el diseño del software de monitoreo de las variables electro-
energéticas que fueron solicitadas ser supervisadas dentro de la planta de suministro
eléctrico del Ecu 911.
Método Inductivo: Este método sirvió para establecer los medios y protocolos de
comunicación, comúnmente usados en la industria, para la recolección de los datos
proporcionados por sensores, actuadores, plc, etc. Además, de identificar los distintos
lenguajes de programación utilizados para desarrollar los sistemas SCADA con sus
85
respectivas HMI e interfaz web para la visualización de los datos de manera local y
remota.
Método Deductivo: Este método se aplicó para analizar la información recopilada y con
ello desarrollar los controladores (“drivers”) de cada modelo de equipo de control y
respaldo de energía eléctrica existente en la panta de suministro eléctrico del SIS ECU
911 Loja, llevando a cabo la tarea de deducir a través de código la representación válida
y exacta de los datos correspondientes a las lecturas de las variables electro-energéticas
almacenadas en cada equipo en mención. De igual manera este método sirvió para
establecer la interacción de las GUI (botones, etiquetas) con los controladores de cada
equipo del sistema eléctrico del ECU 911 a través de las distintas señales y slots descritas
en la sección 4.2.4 para facilitar el manejo del software de monitoreo y la visualización
de las variables electro-energéticas que se estén monitoreando.
Método Incremental(Desarrollo de Software): Con este método, destinado a la creación
de software, se logró analizar la información recopilada para poder desarrollar el código
fuente del software de monitoreo el cual fue evolucionando conforme lo indicaba el
técnico encargado del SIS ECU 911 Loja, permitiendo así, ir modificando, agregando o
eliminando componentes innecesarios que no se iban a utilizar logrando así almacenar y
presentar los datos obtenidos de la manera más clara y eficiente para su posterior análisis
según sean requeridos.
Figura 51. Modelo del proceso incremental para el desarrollo de software.
Fuente: (Aldás Alarcón, 2016).
En la Figura 51, se muestra el modelo incremental para el desarrollo de software, el cual
permite ejecutar progresivamente, en cada incremento una funcionalidad más al
programa, con un flujo lineal y en paralelo. El primer incremento da la funcionalidad
Entrega del
Incremento 1 Incremento
1 ANÁLISIS DISEÑO PROGRAMACIÓN PRUEBA
S
Entrega del
Incremento 2
Incremento
2 ANÁLISIS DISEÑO PROGRAMACIÓN PRUEBA
S
Entrega del
Incremento 3 Incremento
3 ANÁLISIS DISEÑO PROGRAMACIÓN PRUEBA
S
Entrega del
Incremento 4 Incremento
4 ANÁLISIS DISEÑO PROGRAMACIÓN PRUEBA
S
86
básica y los demás incrementos proveen cada vez más funciones avanzadas. (Aldás
Alarcón, 2016)
87
6. RESULTADOS
El desarrollo del sistema de monitoreo en tiempo de real, orientado a la supervisión de
las variables electro energéticas de los equipos de control y respaldo de energía eléctrica
del SIS ECU 911 Loja, se planteó bajo la estructura funcional de los sistemas SCADA
que se indica en la Figura 52.
Figura 52. Esquema de la Estructura Funcional de los Sistemas SCADA.
Fuente: Autor.
A partir de la investigación de los bloques funcionales que integran estos sistemas, se
logró identificar e integrar los equipos seleccionados en un solo sistema de monitoreo,
bajo diferentes buses y protocolos de comunicación, almacenando la información en una
base de datos y presentando al usuario las variables electro energéticas a través de una
HMI. Esto con la finalidad de optimizar recursos de software y hardware, reducir costos
de implementación al hacer uso de tecnologías libres, pero ante todo con la premisa de
hacer frente a la necesidad de monitorear la red eléctrica que alimenta a las cargas críticas
del SIS ECU 911 Loja. A continuación, se describen las diferentes etapas que se llevaron
a cabo para la culminación exitosa de esta investigación.
SISTEMAS SCADA
conjunto de software y hardware que sirven -
comunicar, controlar y supervisar diversos
dispositivos de campo - proceso de forma
remota.
basan su funcionamiento en la combinación de
la telemetría (medición remota de magnitudes
físicas), con las acciones de control.
CARACTERÍSTICAS GENERALES
Emplean computadores y
protocolos de comunicación
industrial – automatizar -
monitoreo y control - procesos
industriales.
Permiten obtener -
representación - datos - planta
- tiempo real.
Actualmente - sistemas SCADA –
capacidad - ejecutar algoritmos
de control - modifican la
respuesta de la planta.
Permiten optimizar la energía
utilizada en el proceso.
Permiten conocer el estado
actual del mismo.
Permiten maximizar producción.
Reducen costos de personal.
Análisis basados en datos
actuales y pasados - capacidad
de almacenamiento que poseen.
ESTRUCTURA FUNCIONAL
Hardware de Adquisión de
DatosRed de Comunicación Industrial Sistema de Gestión de Datos
Interfaz Humano-Máquina
(HMI, Human Machine-Interface)
• Unidades Terminales
Remotas (UTR).
• Autómatas Programables
(PLC).
• Sensores y Actuadores.
• Estándares de Interfaz de
Comunicaciones: EIA/TIA-
232, EIA/TIA-485-A.
• Protocolos de Comunicación:
Modbus, Profibus.
• Sistemas de Gestión de
Bases de Datos: MySQL,
Oracle, PosgreSQL.
Fabricantes de sistemas HMI/
SCADA.
• Wonderware: InTouch.
• Siemens: WinCC.
• Intellution: IFIX.
88
6.1. Diseño
El proceso de diseño del sistema de monitoreo, se estableció una vez conocidos los
equipos de control y respaldo de energía eléctrica del SIS ECU911 e identificadas las
variables electro-energéticas a monitorear, se estructuró de acuerdo al diagrama de
bloques mostrado en la Figura 53.
Figura 53. Implementación del sistema de monitoreo en tiempo real de las variables electro-energéticas
del SIS ECU911 Loja.
Fuente: Autor.
Este diagrama de bloques, indica la estructura funcional de un sistema SCADA, (como
se describió en la sección 4.1.2.4 o en la Figura 52) la cual se tomó como referencia para
el desarrollo del presente proyecto partiendo de la primera etapa (hardware de adquisión
de datos) hasta la última etapa (sistema de visualización remota de datos).
6.1.1. Hardware de Adquisión de Datos: Unidades de Terminal Remota.
Esta sección corresponde a los equipos de control y respaldo de energía eléctrica que se
encuentran instalados y que forman parte de la planta de suministro eléctrico del SIS ECU
911 Loja, los mimos que fueron estudiados en el apartado 4.3.4.
6.1.2. Red de Comunicación Industrial: Infraestructura de Comunicación.
La infraestructura de comunicación hace referencia a las interfaces y protocolos de
comunicación que comparten todos los equipos de control y respaldo de energía eléctrica,
que permiten integrarlos en un solo sistema de monitoreo. Como se describió
anteriormente, los analizadores de red DUCA-LCD96 485-RELÉ, los módulos
automáticos DSE7320 y los UPS Eaton 9320 presentan el protocolo Modbus
implementado en su sistema. Los analizadores y módulos automáticos implementan el
protocolo Modbus RTU (Maestro/Esclavo) a través de la interfaz serial RS485 y RS232,
89
respectivamente. En cambio, los UPS implementan el protocolo Modbus sobre redes
TCP/IP. Por esta razón, el programa desarrollado utiliza el protocolo Modbus RTU y
Modbus TCP/IP para integrar todos estos equipos al mismo sistema de monitoreo a nivel
lógico ya que la conexión física se realiza de manera diferente ya que como se estudió
anteriormente utilizan diferentes tecnologías en lo que respecta al acceso al medio.
A continuación, se indica en la Tabla 24: la configuración que se estableció en las
interfaces y protocolos de comunicación de los módulos DSE7320 y los tableros DUCA-
LCD96.
Tabla 24:
Configuración de las interfaces y protocolos de comunicación de los módulos DSE7320 y los tableros
DUCALCD96.
PR
OT
OC
OL
O D
E C
OM
UN
ICA
CIO
NE
S
MO
DB
US
RT
U (
Ma
estr
o/E
scla
vo
)
MÓDULOS DSE7320
Interfaz RS232
(9 pines)
Esta interfaz viene habilitada por defecto. No se pueden
habilitar dos interfaces al mismo tiempo por lo que la interfaz
RS485 viene deshabilitada.
Velocidad de Datos 19 200 baudios
Dirección de esclavo 10 (Modbus RTU), 10 (Modbus RTU)
Tamaño de los datos 8 bytes
Bit de parada 1
Paridad Ninguna
TABLEROS DUCA-LCD96 485-RELÉ
Interfaz RS485
(VSAT)
Esta interfaz viene integrada y habilitada en el modelo 485-
RELÉ.
(4 pines)
Velocidad de Datos 19 200 baudios
Dirección de esclavo 31 (Tablero UPS), 32 (Tablero Servicios Generales), 33
(Tablero Operaciones)
Tamaño de los datos 8 bytes
Bit de parada 1
Paridad Ninguna
MO
DB
US
TC
P/I
´P
(Cli
ente
/Ser
vid
or)
UPS EATON 9390
Dirección de red 10.131.7.95 (UPS 1)
10.131.7.96 (UPS 2)
Puerto
502
Fuente: Autor.
En la Tabla 24:, se puede observar que la interfaz usada en los módulos DSE7320 es la
RS232, esta interfaz como se indica en la sección 4.1.6, no se utiliza como el bus de
campo implementado en este sistema de monitoreo, por tal motivo, se utilizó un adaptador
de interfaz en la cual se muestra en la siguiente figura.
90
Figura 54. STM485-C. Convertidor pasivo RS-232 a RS-485.
Fuente: Autor.
El convertidor STM485-C se usó para conectar los módulos DSE7320 al bus de campo
RS-485 el cual fue seleccionado por sus características antes citadas para la conexión de
los equipos correspondiente a la topología maestro/esclavo (Modbus RTU).
Este convertidor es compatible con los estándares RS-232C y RS-485. Es capaz de
convertir la señal RS-232 en una señal diferencial balanceada RS-485 y extender la
distancia de comunicación a 1.2 km. Es pasivo y no requiere alimentación externa. Un
transceptor interno y un circuito particular controlan automáticamente la dirección del
flujo de datos en lugar de las señales de intercambio (como RTS, DTR, etc.). Cuando
funciona en modo RS-232 Half dúplex. El software mantiene la misma función bajo RS-
485 sin ningún cambio. La velocidad de transmisión es de 300 - 115 200 bps.
91
6.1.2.1. Esquema General de Conexión Física del Sistema de Monitoreo
Figura 55. Esquema general de conexión física del sistema de monitoreo.
Fuente: Autor
El esquema general de conexión física del sistema de monitoreo implementado en el SIS
ECU 911 Loja se muestra en la Figura 55. En este esquema se puede apreciar dos
estructuras funcionales de un sistema SCADA; la primera estructura que corresponde al
hardware de adquisión de datos, en donde se encuentran los equipos de control y respaldo
de energía eléctrica, como los UPS EATON 9390, los módulos DSE7320 y los Tableros
DUCA-LCD96 485 RELÉ. La segunda estructura hace referencia a la red de
comunicación industrial, aquí se utilizaron los protocolos de comunicación ModBus RTU
(Maestro/Esclavo) para comunicarse con los módulos y tableros, a través del bus de
campo RS485, además, se implementó el protocolo ModBus TCP (Cliente/Servidor) para
comunicarse con los UPS a través de la red Ethernet. Todos ellos conectados al único
maestro existente en la red de comunicación, en este PC donde se ejecuta el software
maestro de la red Modbus, se implementan las demás estructuras funcionales de un
sistema SCADA.
6.1.3. Sistema de Visualización Local de Datos
En esa sección, se indica como se llevó a cabo el desarrollo del software de monitoreo,
con el cual, a través de los controladores de cada equipo de control y respaldo de energía
92
eléctrica permite realizar las lecturas de las variables electro-energéticas y mostrarlas al
usuario final, además de permitir cargar los valores de estas variables en una base de
datos.
La programación del software de monitoreo se desarrolló en el lenguaje de programación
Python 3 en su versión 3.6.7 sobre el sistema operativo Ubuntu bionic 18.04 LTS
haciendo uso del IDE PyCharm Community 2018.3.2. Se utilizó el lenguaje de
programación Python gracias a que es libre, multiplataforma, posee frameworks de gran
variedad y utilidad, así como una sintaxis clara, además permite la programación
orientada objetos, todos estos atributos contribuyeron al desarrollo exitoso de la presenta
investigación. El sistema operativo Ubuntu en donde se desarrolló la presente
investigación fue un requerimiento dado por el ECU 911 Loja, ya que el equipo dado para
operar el sistema de monitoreo funciona con este sistema operativo.
6.1.3.1. Desarrollo de los Controladores de las UTR´s
Python presenta algunas librerías que implementan el protocolo de comunicaciones
industriales ModBus, para este proyecto se usó la librería “MinimalModbus” en su
versión 0.7 para la comunicación del maestro y los esclavos (tableros y generadores) del
modo Modbus RTU y la librería “pyModbusTCP” en su versión 0.1.7 para la
comunicación con los UPS a través del protocolo Modbus sobre TCP/IP. Para la conexión
con la base de datos se usó la librería psycopg2 en su versión 2.7.5 y para la interfaz
gráfica de usuario (GUI) que presenta el programa se hizo uso de la librería PyQt5 5.11.2.
a) Controlador del módulo automático DSE7320
El controlador del módulo automático DSE7320 es un script desarrollado en el lenguaje
Python que nos permite leer o consultar las variables electro-energéticas presentadas en
la Tabla 16: debido a que en este script se almacenan las direcciones de los registros
Modbus, las variables y sus respectivas unidades; así como también se almacenan los
valores de centinela que presentan estos equipos que ya se explicó anteriormente. A
continuación, se detalla el diagrama de flujo del controlador desarrollado para este equipo.
93
Figura 56. Diagrama de flujo del controlador DSE7320.
Fuente: Autor.
El código escrito en Python de este controlador se lo puede observar en el anexo 8.
b) Controlador del analizador de red DUCALCD96 485-RELÉ
El controlador del analizador de red DUCALCD96 485-RELE es un script que se
desarrolló en el lenguaje Python, diseñado para leer o consultar las variables electro-
energéticas presentadas en la Tabla 12:, gracias a que en este script se almacenan las
direcciones de los registros Modbus, las variables y sus respectivas unidades. A
continuación, se indica el diagrama de flujo del controlador desarrollado para este equipo.
94
Figura 57. Diagrama de flujo del controlador DucaLCD96 485-RELÉ.
Fuente: Autor
El código escrito en Python de este controlador se lo puede observar en el anexo 7.
95
c) Controlador del EATON 9390 UPS
El controlador del EATON 9390 UPS es un script desarrollado en el lenguaje Python que
nos permite leer o consultar las variables electro-energéticas presentadas en la Tabla 21:
de ya que en este script se almacenan las direcciones de los registros Modbus, las
variables y sus respectivas unidades; así como también se almacenan las respuestas de las
variables catalogadas como test y alarma que presentan estos equipos como se explicó
anteriormente. A continuación, detallamos el diagrama de flujo del controlador
desarrollado para este equipo.
Figura 58. Diagrama de flujo del controlador del Eaton9390 UPS.
Fuente: Autor.
96
El código de este controlador se lo puede observar en el anexo 9. Una vez creados y
probados los controladores de cada equipo, para las lecturas de las variables electro-
energéticas, se procedió al diseño de la interfaz gráfica de usuario del software de
monitoreo haciendo uso de la aplicación de Qt Designer y de la librería PyQt5 para su
interacción con el lenguaje Python.
6.1.3.2. Diseño y Desarrollo de la Interfaz Gráfica de Usuario del Software de
Monitoreo.
El diseño de la interfaz gráfica de usuario (GUI) del sistema de monitoreo se basó en el
esquema mostrado en las siguientes figuras. Este esquema cumple con los requerimientos
solicitados por parte del ECU 911 para la configuración y visualización de las variables
electro-energéticas de los equipos que integran la planta de suministro eléctrico.
CONFIGURACIÓN DE LA CONEXIÓN TCP/IP:
Puerto TCP Dirección IP de los esclavos
CONFIGURACIÓN DE LA CONEXIÓN SERIAL:
Puerto COM Dirección Modbus de los esclavos
Baudrate
CONFIGURACIÓN DE SEGURIDAD:
Configuración
Base de Datos
Configuración
Alertas
Configuración
Correo
CONFIGURACIÓN GENERAL DEL SISTEMA DE MONITOREO
Figura 59. Esquema de la GUI del software de monitoreo del sistema eléctrico del ECU 911 Loja:
Ventana secundaria de “configuración general del sistema”.
Fuente: Autor.
97
Figura 60. Esquema de la GUI del software de monitoreo del sistema eléctrico del ECU 911 Loja:
Ventana secundaria de “configuración de la base de datos”.
Fuente: Autor.
Nombre del Host
Nombre de la Tabla
CONFIGURACIÓN DE LA BASE DE DATOS
Nombre Base de Datos
Usuario
Contraseña
Esclavo
Valor mínimo
CONFIGURACIÓN DE ALERTAS
Variable
Tiempo de
lectura
Valor máximo
Figura 61. Esquema de la GUI del software de monitoreo del sistema eléctrico del ECU 911 Loja: Ventana secundaria de “configuración de alertas”.
Fuente: Autor
Usuario
Remitente
CONFIGURACIÓN DEL CORREO DE ALERTA
Contraseña Asunto
Destinatario
Figura 62. Esquema de la GUI del software de monitoreo del sistema eléctrico del ECU 911 Loja:
Ventana secundaria de “configuración del correo de alerta”.
Fuente: Autor.
98
Figura 63. Esquema de la GUI del software de monitoreo del sistema eléctrico del ECU 911 Loja:
Ventana principal del “sistema de monitoreo del sistema eléctrico del ECU 911 Loja”.
Fuente: Autor.
La herramienta “ventana principal” del software Qt Designer se utilizó para mostrar los
valores de las variables electro-energéticas de los equipos y es la ventana principal del
software de monitoreo del presente proyecto. A demás, se usó los cuadros de diálogo de
Qt Designer para las ventanas secundarias en donde se realiza la configuración de los
distintos parámetros y funciones que presenta el programa del cual versa el presente
proyecto.
Figura 64. Ventana principal del software de monitoreo del sistema electro-energético del SIS ECU911
Loja.
Fuente: Autor.
Nombre del equipo:
Visualización de los datos:
Fecha-hora-variable electro-energética-valor-unidad
Visualización de errores durante la ejecución del programa
(LOG)
Fecha-hora-ubicación-error
Configuración
SISTEMA DE MONITOREO DEL SISTEMA ELÉCTRICO ECU 911 LOJA
(dirección del equipo)
Detener IniciarCerrar
99
En la Figura 64, se muestra la ventana principal del software de monitoreo en donde se
puede observar todos los equipos de control y energía que integran la planta de suministro
eléctrico del SIS ECU 911 Loja, identificados por tablero 1, tablero 2, tablero 3 a los
analizadores de red con su respectiva dirección de esclavo Modbus, luego los generadores
1 y 2 que hacen referencia a los módulos de control automático que supervisan y controlan
a los mismos generadores; y finalmente los UPS 1 y 2 con su respectiva dirección IP. En
la parte inferior encontramos una sección con el nombre de LOG en donde se indican los
errores ocurridos durante: la comunicación con los esclavos, la conexión con la base de
datos entre otros.
Los botones de Iniciar, Detener y Cerrar permiten iniciar y detener la comunicación con
los esclavos y cerrar el programa. El botón de configuración abre una ventana secundaria
en donde se encuentra la configuración general del programa, observe la Figura 65.
Figura 65. Ventana secundaria de configuración general del software de monitoreo.
Fuente: Autor.
En la ventana secundaria de configuración general del software de monitoreo se muestra
desde su parte superior la configuración de los parámetros necesarios para establecer la
comunicación con el servidor Modbus TCP de los UPS, como es el puerto TCP que junto
a la dirección IP de los UPS establecen los sockets por donde se envían las peticiones
Modbus. La sección de “CONFIGURAR CONEXIÓN SERIAL” permite establecer el
puerto COM por donde se va conectar a la red Modbus RTU sobre el bus de campo RS-
485, la opción BAUDRATE permite configurar la velocidad de transmisión de los datos
medida en baudios; y finalmente en esta sección se encuentra la configuración de las
direcciones de los esclavos conectados a la red Modbus RTU.
100
En la parte inferior de la ventana se indica la sección de “CONFIGURACION DE
SEGURIDAD” en donde encontramos los botones de configuración para establecer la
conexión a la base de datos, la configuración de alertas y alarmas y la configuración del
correo de alerta; cada uno con una etiqueta que nos indica el estado de dicha configuración
es decir si encuentra correctamente configurado y por lo tanto habilitado. Al hacer click
en el botón de “Configurar Base de Datos”, se presenta una ventana secundaria que se
muestra en la Figura 66.
Figura 66. Ventana secundaria de configuración de la conexión a la base de datos.
Fuente: Autor.
En la ventana secundaria identificada con el nombre de “CONFIGURACION DE LA
BASE DE DATOS” nos presenta las opciones necesarias para conectarnos
satisfactoriamente a una base de datos.
Figura 67. Ventana secundaria de configuración de alertas.
Fuente: Autor.
Al cliquear sobre el botón “Configurar Alertas y Alarmas” se nos muestra una ventana
secundaria como lo indica la Figura 67, en donde podemos apreciar las distintas opciones
en donde podemos elegir el esclavo y sus respectivas variables para establecerlas dentro
de rangos normales de funcionamiento y en el caso en que una variable este fuera de este
rango se envía un correo de alerta y dependiendo del tipo de alerta o alarma se modifica
de alguna manera el funcionamiento del programa. La opción etiquetada con la palabra
“TIEMPO” nos permite modificar el tiempo de lectura que el programa realiza sobre los
esclavos, es decir, nos permite decidir cada que tiempo se realizan las consultas de las
101
variables electro-energéticas de todos los esclavos seleccionados. Se puede elegir entre
segundos, minutos y horas.
Figura 68. Ventana secundaria de configuración del correo de alerta.
Fuente: Autor.
Finalmente, la última ventana secundaria se nos muestra en la Figura 68 que se presenta
al momento de seleccionar la opción “Configurar Correo de Alerta”, aquí se muestra la
opción de Usuario en donde se escribe el correo del remitente y su respectiva contraseña
del proveedor del correo electrónico (Gmail, Outlook, etc) para permitir enviar el correo
de alerta, luego el correo del destinatario/s con su respectivo asunto en caso lo requiera.
El contenido del mensaje es el equipo que presento alguna media fuera de rango de una
o algunas de variables electro-energéticas en el momento que se suscitó, indicando la
variable, el valor, la unidad y la fecha.
Hasta este punto se describió el diseño de la interfaz gráfica del software de monitoreo,
en donde cada ventana representa un archivo con formato .ui el cual está desarrollado en
C++ creado por la herramienta de Qt Designer, para poder trabajar con este tipo de
archivo en Python existen dos formas. La primera es parsear el código es decir cambiar
del lenguaje a C++ a su representación en Python, esto realiza con el siguiente comando
ejecutándolo desde el terminal:
pyuic5 -x archivo_entrada.ui -o archivo_salida.py
Aplicado a nuestra ventana principal del programa aquí elaborado, el cual se encuentra
guardado con el nombre “scada_ecu_final.ui” mostrado en la Figura 64 se obtiene el
siguiente resultado.
102
pyuic5 -x scada_ecu_final.ui -o scada_ecu_final.py
Al ejecutar dicho comando nos genera un archivo scada_ecu_final.py como se puede
apreciar en formato .py de python en la misma ubicación del archivo original. El resultado
de esta conversión se observa en la Figura 69.
Figura 69. Código fuente de la ventana principal del software de monitoreo escrito en Python.
Fuente: Autor.
Como se puede apreciar, se presenta la clase Ui_MainWindow con todos sus atributos
creados en la interfaz gráfica mostrada y desarrollada con Qt Designer. Todo esto gracias
a la librería PyQt5 desarrollada en Python. La otra forma con la que se puede trabajar es
importar el archivo.ui dentro del código Python como se indica a continuación:
from PyQt5 import uic # importamos el módulo uic de la librería PyQt5
Al importar este módulo podemos hacer uso de la siguiente función:
uic.loadUi(‘scada_ecu_final.ui’)
Esta línea de código permite cargar directamente el archivo .ui y trabajar sobre el
haciendo referencia a los distintos objetos creado en Qt Designer para sus respectivas
señales y slot; todo ello directamente en código Python.
103
Se puede apreciar que en el primer método permite trabajar en un script de por si extenso
ya que muestra todos los objetos o widgets con sus propiedades, en cambio con el segundo
solo se carga el archivo y se empieza a trabajar en la lógica del programa, razón por la
cual se eligió el ultimo método.
El desarrollo en código Python de cada ventana mostrada en la sección 5.4.2 se realizó a
través de la creación de clases, es decir, se declaró una clase para cada ventana del
programa. Observe la Tabla 25:.
Tabla 25:
Clases declaradas para el funcionamiento del software de monitoreo.
Nombre Declaración Descripción
Clase
Dialogo_Correo
class
Dialogo_Correo(QDialog):
Corresponde a la ventana “Configuración
del correo de alerta”. Gestiona los
parámetros para el envío del correo de
alerta.
Clase Dialogo_DB class Dialogo_DB(QDialog)
Corresponde a la ventana “Configuración
de la base de datos”. Gestiona los
parámetros para establecer la conexión con
la base de datos.
Clase
Dialogo_alarmas
class
Dialogo_alarmas(QDialog)
Corresponde a la ventana “Configuración
de alertas”. Configura los parámetros para
establecer el rango normal del valor de las
variables electro-energéticas consultadas
con el software de monitoreo.
Clase
Dialogo_ConfigScada
class
Dialogo_ConfigScada(QDialog)
Corresponde a la ventana “Configuración
general del sistema de monitoreo”.
Configura los parámetros para establecer la
conexión serial y TCP. Además, permite
seleccionar los equipos a monitorear y
permite acceder a las demás
configuraciones que presente el programa,
Clase Ventana class Ventana(QMainWindow):
Corresponde a la ventana “Sistema de
monitoreo del sistema eléctrico ECU911
Loja”. Presenta los valores de la variables-
electro-energéticas correspondiente a cada
equipo indicando sus direcciones y los
posibles errores ocurridos durante la
comunicación.
Fuente: Autor.
La descripción del funcionamiento de cada clase se realiza a través de diagramas de flujo
para simplificar la explicación de manera clara y sencilla de todo el proceso que llevan a
cabo. El código desarrollado para cada clase se indica en los anexos 10, 11, 12, 13, 14,
respectivamente.
104
Figura 70. Diagrama de flujo de la clase Dialogo_Correo.
Fuente: Autor.
Iniciamos el constructor de la clase
Cargamos el archivo configuracion_correo.ui
Se crea los atributos donde se van a almacenar los
parámetros ingresados en la interfaz grafica
Al dar click en el botón Guardar se llama al
método guardar_correos()
El correo de
usuario es
válido?
El dominio del
proveedor de
correo del
usuario es Gmail?
El correo del
destinatario es
válido?
El usuario y
contraseña
son válidos?
SI
SI
SI
SI
Datos guardados
correctamente
FIN
Clase
Dialogo_Correo
Se ingresan los datos que se
piden en la interfaz
grafica.(Usuario, Password,
Remitente, Destinatario, Asunto)
Correo del usuario
inválido
NO
Dominio de correo
de usuario no
soportado
NO
NO Correo del destino
es inválido
NO Contraseña y
usuario no
aceptados
105
Figura 71. Diagrama de flujo de la clase Dalogo_DB.
Fuente: Autor.
Iniciamos el constructor de la clase
Cargamos el archivo configuracion_base_datos.ui
Se crea los atributos donde se van a almacenar los
parámetros ingresados en la interfaz gráfica
Al dar click en el botón Conectar se llama al método
conectar_base_de_datos()
Se estableció
conexión con la
base de datos?
SI
Conexión establecida
correctamente
FIN
Clase Dialogo_DB
Se ingresan los datos que se piden
en la interfaz grafica.(Nombre del
host, Nombre DB, Usuario,
Contraseña, Nombre de la Tabla)
NO
Se muestra el evento
que produjo el error
106
Figura 72. Diagrama de flujo de la clase Dialogo_alarmas.
Fuente: Autor.
Iniciamos el constructor de la clase
Cargamos el archivo configuracion_alarmas.ui
Se definen los atributos donde se van a guardar los
valores o estados de las alertas, alarmas y test
Al dar click en el botón Agregar se llama al
método agregar_alarma()
La variable es
del tipo
alarma?
Los valores
ingresados son
cero?
Los valores
ingresados son
iguales?
SI
NO
NO
FIN
Clase
Dialogo_alarmas
Se selecciona el equipo, la
variable y su respectivo rango o
estado considerados por el
usuario como fuera del
funcionamiento normal
Alerta guardada
correctamente
NO
NO
Se selecciona el tiempo con el
que el programa realiza las
consultas de la variables de
todos los equipos
seleccionados.
La variable es
del tipo test?
SI Alerta guardada
correctamente
valor_min>valor_m
ax
NO
Alerta guardada
correctamente
SI Ingrese valores
diferente de cero
SI Ingrese valores
diferentes
SI El valor mínimo debe
ser menor que el valor
máximo
107
Figura 73. Diagrama de flujo de la clase Dialogo_Scada.
Fuente: Autor.
Iniciamos el constructor de la clase
Cargamos el archivo configuracion_scada.ui
Se instancian los objetos de cada clase (Dialogo_DB,
Dialogo_Correo, Dialogo_alarmas)
Al dar click en el botón Aceptar se llama al
método verificar_entradas
Se eligió al
menos un
equipo?
SI
FIN
Clase Dialogo_Scada
NO
NO
Se configuran los parametros de la conexión TCP y
serial, se elige los equipos a monitorear con sus
respectivas direcciones
SI
Puerto COM no
disponible
Se definen las señales y sus respectivos slot, así como los atributos
necesarios para el correcto funcionamiento del programa
Se configuran la conexión con la base de datos,
las alertas y el correo de seguridad
Se eligió al
menos un equipo
serial?
Se eligió al
menos un equipo
serial?
Puerto COM
disponible?
NO
SI
Dirección de
esclavo valida?
NO
SI
Dirección de
esclavo
duplicadas?
SI
Ingrese una
dirección valida
Ingrese dirección
única para cada
esclavo
Seleccione al menos un
dispositivo
Dirección IP del
esclavo valida?
SI
Dirección IP de
esclavos
duplicadas?
SI
Configuración exitosa
Se cierra automáticamente la
ventana
NO
Ingrese una
dirección IP
valida
NO
Ingrese una
dirección IP
única para
cada esclavo
NO
NO
108
Figura 74. Diagrama de flujo de la clase Ventana.
Fuente: Autor.
Iniciamos el constructor de la clase
Cargamos el archivo scada_ecu_final.ui
Se instancia el objeto de la clase Dialogo_ConfigScada()
Tablero 1 ?
Clase Ventana
SI
Es una
Alarma?
Se establecen las señales con sus respectivos slot, así como los
atributos y métodos necesarios para el funcionamiento del
software
Al presionar en el botón Iniciar se llama al método iniciar()
Se encontró
alguna
alerta?
NO
i < número de
registros del
equipo
seleccionado
Se muestra las varibles, su
valor, unidad, hora y
fecha
NO
Es un test?
Se instancian los objetos para cada equipo
seleccionado
Se llama al método tiempo_ejecucion()
Se instancia el objeto timer de la librería QTimer para que llame a la función
leer_registros() cada que se agote el tiempo establecido en el método del objeto
timer
NOTablero 2 ?
NOTablero 3 ?
NO Generador
1 ?
NO Generador
2 ?
NOUPS 1 ?
NO UPS 2
seleccionado
SI SI SI SI SI SI
Se llama al método leer_registros(i) de cada
equipo, para la lectura de cada variable
cargada en su controlador.
SI
SIEnvía un Correo de
seguridad indicando en que
variable y equipo se generó
la alerta.
NO
Es un valor
de
centinela?
SI
Se reduce el tiempo de lectura de
todas las variables de lso equipos
selecionados al máximo y se envía el
correo indicando que variable no se
encontró en su rango establecido
NO
SI
i =+ 1
Se espera a
que pase el
tiempo
establecido en
el timer
Se sube la
data a la
base de
datos
NOContador =+ 1
contador <
número de
equipos
seleccionados
SI
NO
Se instancia el objeto timerlectura para que
llame a la función tiempo_ejecucion cada
que se agote el tiempo establecido en el
widget Tiempo de la ventana de
configuración de alertas
Se espera a
que se agote
el tiempo
establecido en
el timerlectura
109
La elaboración de estos diagramas de flujo, como se mencionó anteriormente, representa
el funcionamiento de cada una de las clases creadas para la interacción con cada una de
las ventanas con las que cuenta la HMI desarrollada para el presente proyecto, facilitando
la comprensión del proceso al mostrarlo como un dibujo.
6.1.4. Almacenamiento de la Información.
La conexión con la base de datos en el SGDB PostgreSQL versión 10.0 se realizó con
ayuda de la librería psycopg2. La base de datos denominada “scadaecu”, se encuentra en
un servidor local (“localhost”) dentro de la red del SIS ECU 911 Loja. Para realizar esta
tarea se creó el siguiente método:
def subir_datos(self, host, database, user, password, esclavo, variable, valor, unidad):
conn = psycopg2.connect(host=host, database=database, user=user, password=password)
cur = conn.cursor()
columnas_esclavos = "id, esclavo, variable, valor, unidad, fecha"
postgres_insert1 = "INSERT INTO esclavos (" + columnas_esclavos + ") VALUES (
nextval('serial'), '%s' ," '%s' , '%s' , '%s', NOW());" % (esclavo,
variable, valor, unidad)
cur.execute(postgres_insert1)
conn.commit()
cur.close()
conn.close()
La creación de la base de datos en PostgreSQL se realizó con las siguientes instrucciones
en lenguaje SQL. Se crea una tabla con el nombre “esclavos”, en donde se utiliza una
llave primaria para identificar cada campo de la tabla con el nombre “id”. Además, se
declaran las siguientes columnas como: “esclavo”, “variable”, “valor”, “unidad”, “fecha”,
en cada una de ellas se almacena la información necesaria para identificar a cada esclavo
que integra el sistema de monitoreo.
CREATE TABLE public.esclavos
(
id integer NOT NULL,
esclavo character(30) COLLATE pg_catalog."default",
variable character(80) COLLATE pg_catalog."default",
valor character(30) COLLATE pg_catalog."default",
unidad character(30) COLLATE pg_catalog."default",
fecha timestamp without time zone,
CONSTRAINT esclavos_pkey PRIMARY KEY (id)
)
WITH ( OIDS = FALSE
)
TABLESPACE pg_default;
ALTER TABLE public.esclavos
OWNER to postgres;
110
6.1.5. Sistema de Visualización Remota de Datos: Interfaz Web.
El conjunto de herramientas informáticas de la pila ELK, permiten trabajar con los datos
almacenados en la base de datos creada con PostgreSQL en diferentes etapas como se
indica en la Figura 75.
Figura 75. Diagrama de gestión de información mediante pila ELK para la creación de la interfaz web.
Fuente: Autor.
En primer lugar, se requiere Logstash para solicitar información a la base de datos y
transformarla para su análisis. A partir de la información recopilada por Logstash,
Elasticsearch permite establecer condiciones de búsqueda y análisis para finalmente
presentarla en la tercera etapa que es Kibana. Esta herramienta permite crear un dashboard
que muestra la información de forma organizada y entendible para el usuario.
6.1.5.1. Configuración de Logstash.
La consulta de los datos de la tabla “esclavos”, que se encuentra en la base de datos de
PostgreSQL, a través de Logstash requiere configurar el esquema y la forma en que se va
a acceder y gestionar la información. El esquema básico se muestra en la Figura 76, en
donde se aprecia la función que realiza la herramienta Logstash, la cual necesita de una
entrada input, un filtro filter (sustituible por un vacío en este sistema) y una salida output.
datos logs jsonFiltra y
TransformaBusca y
Analiza
Elasticsearch KibanaLogstash
Base de
Datos
Exploración y
Visualización
PostgreSQL
111
Figura 76. Funcionamiento de la herramienta Logstash.
Fuente: Autor.
A continuación, se muestra el script de configuración de la herramienta Logstash:
input
jdbc
jdbc_driver_library => "/home/user/Data/postgresql-42.2.2.jar"
jdbc_driver_class => "org.postgresql.Driver"
jdbc_connection_string => "jdbc:postgresql://localhost:5432/datosarduino"
jdbc_user => "user"
jdbc_password => "password"
schedule => "* * * * *"
statement => "SELECT * from esclavos
use_column_value => true
tracking_column => fecha
filter
output
stdout codec => json
elasticsearch
hosts => ["https://127.0.0.1:9200"]
index => "elk-esclavos"
112
6.1.5.2. Configuración de la Herramienta Elasticsearch.
Se configura Elasticsearch de forma que se establezca un esquema del índice, esto se
denomina como mapeo, y se refiere a establecer en Elasticsearch el tipo de atributos que
se da a los logs que contienen la información. Los datos que ingresan de la tabla sensor a
Elasticsearch son indexados como logs (línea de palabras) con formato. json que contiene
los campos y valores de los datos originales lo que permiten almacenarlos y recuperarlos
(cuando se necesite realizar una consulta).
El esquema básico del índice se compone principalmente por el nombre de la indexación,
tipo, id (proporcionado por Elasticsearch) y versión como se puede observar en las cuatro
primeras líneas del script mostrado a continuación:
"_index": "elk-esclavos",
"_type": "log",
"_id": "Gkz0IWYBRSLaWxFzwBbo",
"_version": 1,
"_score": null,
"_source":
"@version": "1",
"esclavo": “GENERADOR1”,
"variable": “Voltaje de la batería”,
"valor": 27.6,
"unidad": “V”,
"id": 22651,
"dslux": 0,
"@timestamp": "2018-09-28T20:53:00.161Z",
"fecha": "2018-09-28T20:52:14.925Z"
,
"fields":
"fecha": [
"2018-09-28T20:52:14.925Z"
],
"@timestamp": [
"2018-09-28T20:53:00.161Z"
]
,
"sort": [
1538167934925
]
113
Desde la sexta línea del script anterior, source, los siguientes parámetros se refieren
básicamente al detalle de la base de datos desde donde se toma la información requerida,
en este caso de la tabla esclavos. Las líneas detalladas como timestamp muestran la fecha
actual de indexación de la información.
De no realizar este tipo de configuración Elasticsearch agrega por defecto un formato
genérico para la indexación de los datos, la cual no satisface los requerimientos de
consulta de este sistema.
6.1.5.3. Configuración de la Herramienta Kibana.
Kibana permite definir la estructura de presentación de la información del sistema de
monitoreo de forma gráfica, donde se selecciona el tipo de métrica más conveniente para
representar los datos. El dashboard de Kibana permite seleccionar el tipo de visualización
de datos, en este caso se usó el entorno “Goal” como se muestra en la Figura 77.
Figura 77. Configuración del tipo de visualización para presentación de las variables electro-energéticas.
Fuente: Autor.
Luego de seleccionar el dashboard adecuado, se configura los niveles de las métricas que
sirven para el monitoreo visual. Se fija los parámetros de estilo para los datos obtenidos
en este caso de la variable de "Voltaje Equivalente de Tres Fases" para cada uno los
tableros. Se realiza este procedimiento para cada una de los equipos de control de
suministro y respaldo de energía eléctrica de los cuales se obtienen los datos de las
variables electro-energéticas. En la Figura 78 se verifica el detalle de la configuración.
114
Figura 78. Configuración del Goal para la presentación de los datos mediante Kibana.
Fuente: El Autor.
6.2. Implementación del Sistema de Monitoreo.
En esta sección se indica la implementación total del sistema de monitoreo del sistema
eléctrico del Ecu 911 Loja, desde la conexión física de los equipos de control y respaldo
de energía eléctrica hasta la configuración de todas las ventanas del programa de
monitoreo, el almacenamiento de las variables electro-energéticas en la base de datos y
su visualización en la interfaz web.
Figura 79. Conexión de los módulos DSE7320 del generador 1 y 2.
Fuente: Autor.
115
Figura 80. Conexión de los tableros de medición DucaLCD96 485-RELÉ
Fuente: Autor.
Figura 81. Configuración exitosa de la conexión a la base de datos.
Fuente: Autor.
Figura 82. Configuración exitosa de las Alertas del sistema de monitoreo.
Fuente: Autor.
116
Figura 84. Configuración exitosa de los equipos de control y respaldo de energía eléctrica
del ECU 911 Loja.
Fuente: Autor.
Figura 83. Configuración exitosa del correo de alerta.
Fuente: Autor.
117
6.3. Funcionamiento Integral del Sistema de Monitoreo.
El funcionamiento completo del sistema de monitoreo en tiempo real de las variables
electro-energéticas queda descrito en el diagrama mostrado en la Figura 85. Este sistema
está conformado por tres etapas principales que describen de manera general todo el
proceso que el sistema de monitoreo lleva a cabo para la lectura, procesamiento,
almacenamiento y presentación de la información. Estas etapas son:
1. Adquisión de los datos.
2. Procesamiento de los datos.
3. Almacenamiento y presentación de los datos.
En la primera etapa, la cual corresponde a la adquisión de los datos, intervienen los
equipos o controladores logicos programables (PLC), es decir los módulos de control
automático DSE7320 que controlan cada uno de los generadores instalados en el cuarto
de generadores, los analizadores de red DUCA-LCD96 485-RELÉ que corresponden a
los tableros de medición que se encuentran en el cuarto de distribución eléctrica y
finalmente los UPS EATON9390 ubicados en el cuarto de enegía regular. Todos estos
equipos se encuntran instalados y configurados para interoperar cuando la situacion lo
Figura 85. Esquema general del funcionamiento del sistema de monitoreo de los equipos de control y
respaldo de energía eléctrica del ECU 911 Loja.
Fuente: Autor.
118
amerite. Una de sus principales funciones de estos equipos, es el de monitorear
parámetros de variables electro-energéticos y almacenarlos en sus respectivos registros
ubicados en su memoria interna, consulte los apartados 4.3.4.1, 4.3.4.2 y 4.3.4.3.
Para poder acceder a los parámetros de variables electro-energéticas almacenados en sus
respectivos registros de memoria de forma remota, estos equipos presentan interfaces de
comunicación, como la interfaz RS232, RS485 y RJ45, junto con el protocolo de
comunicación Modbus en modo RTU y TCP. El protocolo Modbus define a estos equipos
como esclavos en una red modbus, por lo que hace, falta de uno o varios equipos maestros
que gestione las lecturas y/o escrituras de dichos registros. En este punto interviene el
software desarrollado en el presente proyecto, el cual cumple la funcion de maestro en la
red Modbus implemtanda para el sistema de monitoreo.
El sofware de monitoreo define la segunda etapa del funcionamiento del sistema de
monitoreo, esta etapa trata acerca del procesamiento de la datos. Este programa inicia
configurando los parámetros necesarios para establecer las conexiones seriales y TCP a
cada equipo según corresponda, como se puede apreciar en la Figura 85. Luego, de ser
requerido, se procede a establecer la conexión con la base de datos, establecer las
respectivas alertas y envíos de correos de seguridad que el usuario crea necesario.
Finalmente, se eligen los equipos que se soliciten monitorear.
A continuación, se procede a consultar las variables electro-energéticas cargadas en los
controladores para cada modelo equipo, este proceso a nivel más interno, en donde no es
transparente para el usuario, se forman las tramas Modbus con sus respectivas direcciones
de esclavo, códigos de función y direcciones de registro para el modo RTU, en el caso
del modo TCP, se utiliza el código de función y la dirección del registro. Una vez
codificadas las tramas se envía la consulta por su respectivo puerto a la espera de la
respuesta enviada por el esclavo. Una vez el escalvo envia la respuesta la cual es una
trama con el mismo formato para cada caso, se procede a extraer los datos que llevan la
información. Cada equipo almacena la informacion de manera diferente, ya que el
protocolo Modbus no se encuentra desarrollado en su totalidad, esto permite a cada
fabricante almacenar la información de la manera que crea conveniente. Para el caso de
los tableros y generadores la información se almacena en enteros del tipo long con signo
y sin signo, para la representación de numeros con decimales cada fabricante indica el
119
factor de escala que se debe aplicar a cada variable para obtener su valor real, en el caso
de los números negativos se envia el bit más significativo en alto para su representación.
En el caso de los UPS, los datos numéricos se alamacenan en punto flotante IEEE 754,
este formato es un estandar para la representacion de números decimales tanto positivos
como negativos.
Una vez decodificados los datos se logra obtener los valores reales y su representación en
decimal, posteriormente se procede a analizar si algún valor se encuentra en un rango
fuero de lo normal antes configurado en la seccion de alertas, en el caso de presentarse
una alerta se envia el correo de advertencia previamente configurado. Posterior a este
evento, se presenta los datos en la interfaz gráfica que presenta el software de monitero,
indicando el equipo, su dirección Modbus, fecha, hora y el valor de cada variable electro-
energetica con su repectica unidad.
Finalmente, la tercera y última etapa, la cual hace referencia al almacenamiento y
presentacion de los datos en la interfaz web, el sofware de monitoreo procede a almacenar
los valores de las variables electro-energéticas en la base de datos implementada, para
este caso se utilizó el gestor postgreSQL. Una vez almacenadas las variables electro-
energéticas en la base de datos, se accede a ellas a través de la pila ELK para ser
presentadas en la interfaz web desarrollada e implementada en el presente proyecto.
En las siguientes figuras, se muestra los resultados obtenidos en base al funcionamiento
anteriormente descrito del sofwate de monioreto en tiempo real de las varibales electro-
energéticas de los equipos de control y respaldo de energía eléctrica del ECU 911 Loja.
120
Figura 86. Lectura de variables electro-energéticas obtenidas con el software de monitoreo en tiempo
real.
Fuente: Autor.
Figura 87. Datos almacenados en la base de datos PostgreSQL.
Fuente: Autor
121
Figura 88. Interfaz Web desarrollada en Kibana.
Fuente: Autor.
6.3.1. Validación de los Datos Obtenidos con el Software de Monitoreo.
La verificación y validación de los datos obtenidos con el software de monitoreo,
desarrollado en el presente proyecto, se realizó comparando los valores que se muestran
en la interfaz de cada equipo, con los datos obtenidos en el software de monitoreo,
calculando el error absoluto porcentual para cada uno de los valores de las variables
electro-energéticas que fueron medidas. En la Tabla 26:, la columna con el nombre
“software” indica los valores medidos con el software de monitoreo, en la columna
“equipo” los datos que presentan los dispositivos en su pantalla y en la columna “Error”
se indica el error absoluto porcentual. En la siguiente tabla, se muestran los valores
obtenidos de cada analizador de red. Para los generadores y UPS se usa el mismo formato
para la validación de sus datos.
Tabla 26:
Validación de los datos obtenidos de los analizadores de red DucaLCD96.
Variable Tablero 1 (32) Tablero 2 (33) Tablero 3 (31)
Software Equipo Error Software Equipo Error Software Equipo Error
Voltaje
Equivalente de
Tres Fases
223 225 0,89 207 207 0,00 213 213 0,00
Corriente
equivalente trifásica
52 50 4,00 152 152 0,00 120 116 3,45
122
Factor de
potencia trifásico
equivalente
-0,97 -0,95 2,11 -0,33 -0,3 10,00 -0,53 -0,56 5,56
Potencia activa equivalente
trifásica
23600 24000 1,67 18000 18200 1,10 26000 24000 8,33
Potencia
aparente
equivalente
trifásica
28000 27000 3,70 54400 54600 0,37 44000 42800 2,80
Potencia
reactiva
equivalente trifásica
-2800 -2600 7,69 -51400 -51400 0,00 11200 12000 6,67
Energía activa equivalente
trifásica(M)
1249,46 1249,54 0,01 873,05 873,11
4 0,01 1102,184 1102,216 0,00
Frecuencia 60,1 60 0,17 60,1 60 0,17 59,9 60,1 0,33
Voltaje de
Línea (línea 1 -
línea 2)
223 225 0,89 208 208 0,00 214 214 0,00
Voltaje entre la
fase y la línea
neutra 1
129 130 0,77 120 120 0,00 124 124 0,00
Corriente de Línea 1
70 70 0,00 150 150 0,00 116 116 0,00
Factor de potencia de
línea 1
-0,98 -0,95 3,16 -0,32 -0,3 6,67 -0,71 -0,74 4,05
Potencia activa
de línea 1 10000 10000 0,00 5600 5600 0,00 10600 10800 1,85
Potencia
aparente de línea 1
13000 12600 3,17 18000 18000 0,00 14600 14200 2,82
Potencia reactiva de
línea 1
0 0 0,00 -17000 -17200 1,16 -9800 -9200 6,52
Energía activa
de línea 1(M) 494,746 494,78 0,01 272,782
272,80
2 0,01 468,38 468,392 0,00
THDFV1(124) 1,04 1,03 0,97 1 1 0,00 1,03 N/A N/A
THDFI1(130) 1,12 1,13 0,88 0,96 0,97 1,03 1,28 N/A N/A
Voltaje de Línea (línea 2 -
línea 3)
223 225 0,89 207 207 0,00 213 213 0,00
Voltaje entre la fase y la línea
neutra 2
129 130 0,77 120 120 0,00 123 123 0,00
Corriente de
Línea 2 38 38 0,00 146 146 0,00 130 123 5,69
123
Factor de potencia de
línea 2
-0,98 -0,97 1,03 -0,24 -0,26 7,69 0,02 0,02 0,00
Potencia activa
de línea 2 4800 4800 0,00 4400 4600 4,35 3200 4000 20
Potencia
aparente de
línea 2
6600 6600 0,00 17400 17400 0,00 16000 14600 9,59
Potencia
reactiva de línea 2
-1600 -1600 0,00 -16800 -16800 0,00 15800 14400 9,72
Energía activa de línea 2(M)
379,238 379,262 0,01 182,494 182,51 0,01 62,832 62,836 0,01
THDFV2(126) 1,05 1,03 1,94 1 1 0,00 1,03 N/A N/A
THDFI2(132) 1,03 1,01 1,98 1,03 1,01 1,98 1,18 N/A N/A
Voltaje de
Línea (línea 3 - línea 1)
223 225 0,89 207 207 0,00 214 214 0,00
Voltaje entre la fase y la línea
neutra 3
129 130 0,77 119 119 0,00 123 122 0,82
Corriente de
Línea 3 48 48 0,00 160 162 1,23 112 118 5,08
Factor de
potencia de
línea 3
0,96 -0,9 6,67 -0,41 -0,42 2,38 0,94 0,87 8,05
Potencia activa
de línea 3 8600 8800 2,27 8000 8200 2,44 12800 12400 3,23
Potencia aparente de
línea 3
8400 7800 7,69 19200 19200 0,00 13600 14200 4,23
Potencia reactiva de
línea 3
-2800 -2800 0,00 -17200 -17400 1,15 4400 4700 6,38
Energía activa
de línea 3(M) 375,476 375,498 0,01 417,774
417,80
2 0,01 570,972 570,988 0,00
THDFV3(126) 1,02 1,03 0,97 1 0,99 1,01 1,01 N/A N/A
THDFI3(132) 1,04 1,12 7,14 0,96 0,97 1,03 1,43 N/A N/A
Error
promedio 1,66
1,15
3,47
Nota: Los valores de las variables electro-energéticas asignados con las letras N/A (no asignada), no fueron
posibles medirlos debido a limitaciones físicas con el equipo. Fuente: Autor.
Tabla 27:
Validación de los datos obtenidos de los módulos DSE7320.
Variable Generador 1 Generador 2
Software Equipo Error Software Equipo Error
Presión del aceite N/A N/A N/A 20 20 0
Temperatura del refrigerante 42 42 0 N/A N/A N/A
Voltaje de la batería 27,6 27,6 0 27,3 27,3 0
Error promedio 0 0
124
Nota: Los valores de las variables electro-energéticas asignados con las letras N/A (no asignada), no fueron
posibles medirlos debido a limitaciones físicas con el equipo. En este caso en particular no se encontraban
instalados los sensores para las variables correspondiente que no pudieron ser monitoreadas. Fuente: Autor.
Tabla 28:
Validación de los datos obtenidos de los UPS Eaton9390
Variable
UPS 1 (10,131,7,95) UPS 2 (10,131,7,96)
Software Equipo Error (%) Software Equipo Error (%)
Check Battery (Alarm) 0 0 0 1 1 0
UPS On Battery (Alarm) 0 0 0 0 0 0
Battery Test in Progress 0 0 0 0 0 0
Battery Test Result Passed Passed 0 Passed Passed 0
System Status (Test) On On 0 On On 0
Output State (Test) On On 0 On On 0
Horn Status (Test) Disabled Disabled 0 Disabled Disabled 0
Va-n Input (V) 123,80 123,80 0,00 123,80 124,20 0,32
Vb-n Input (V) 122,90 122,90 0,00 123,00 123,30 0,24
Vc-n Input (V) 123,40 123,40 0,00 123,50 123,80 0,24
Va-n Output (V) 119,30 119,30 0,00 118,80 118,90 0,08
Vb-n Output (V) 119,00 119,00 0,00 119,20 119,10 0,08
Vc-n Output (V) 119,20 119,20 0,00 119,20 119,10 0,08
Va-n Bypass (V) 123,60 123,70 0,08 123,80 124,20 0,32
Vb-n Bypass (V) 123,10 123,20 0,08 123,00 123,30 0,24
Vc-n Bypass (V) 123,00 123,00 0,00 123,20 123,40 0,16
Battery Voltage (V) 517,70 517,70 0,00 554,30 554,30 0,00
Ia Input (A) 54,80 55,60 1,44 56,80 55,20 2,90
Ib Input (A) 54,40 55,20 1,45 56,80 54,40 4,41
Ic Input (A) 54,80 55,60 1,44 56,40 54,80 2,92
Ia Output (A) 79,60 80,80 1,49 78,40 76,40 2,62
Ib Output (A) 82,00 82,80 0,97 66,40 63,60 4,40
Ic Output (A) 80,40 80,80 0,50 78,00 75,20 3,72
P-in (W) 14700,00 15100,00 2,65 16200,00 15300,00 5,88
P-out (W) 11800,00 11900,00 0,84 10600,00 9900,00 7,07
VA-in (V-A) 20200,00 20500,00 1,46 20900,00 20300,00 2,96
VA-out (V-A) 29500,00 29800,00 1,01 27200,00 26400,00 3,03
Full Load (%) 18,00 18,00 0,00 17,00 16,00 6,25
PF-in (Factor-potencia) 0,35 0,38 7,89 0,4 0,44 9,09
PF-out (Factor-potencia) 0,71 0,73 2,74 0,77 0,80 3,75
Capacity Remaining (%) 99,00 99,00 0,00 99,00 99,00 0,00
Input Demand (KW) 148,71 148,71 0,00 190,20 180,16 5,57
Output Demand (KW) 116,55 116,55 0,00 140,30 128,13 9,51
Frequency In (Hz) 60,00 60,00 0,00 60,00 60,00 0,00
Frequency Out (Hz) 60,00 60,00 0,00 60,00 60,00 0,00
Error promedio 1,03 4,20
Fuente: Autor.
125
7. DISCUSIÓN
El presente proyecto se realizó bajo la dirección del personal especialista de soporte
tecnológico local del SIS ECU 911 Loja, en donde, se estableció una serie de actividades,
que permitieron entre otros aspectos: identificar las diferentes marcas presentes en los
equipos de control y respaldo de energía eléctrica, las cuales son DUCATI, EATON y
DEEP SEA ELECTRONICS, sus protocolos e interfaces de comunicaciones, con la
premisa de llevar a cabo el cumplimiento de cada objetivo planteado en la presente
investigación. Con base a lo anteriormente expuesto, los resultados de la investigación
han permitido validar el cumplimiento de los objetivos, como se detalla a continuación.
Objetivo 1: Determinar cuáles son los equipos de control de suministro y respaldo
de energía eléctrica que se requieren monitorear dentro de la infraestructura del
SIS ECU 911 LOJA para lograr integrarlos en un único sistema.
En base a la investigación realizada de los equipos del grupo electro-energético que
conforman la planta de suministro eléctrico del edificio del SIS ECU 911 Loja,
documentada en la sección 4.3.4, se identificó los modelos existentes, sus datos técnicos,
conexiones y configuraciones, de esta manera, se empezó a diseñar y realizar cada uno
de los bloques funcionales que integran un sistema SCADA tomado como referencia para
la realización del presente proyecto de tesis.
Una vez establecidos los equipos de control y respaldo de energía eléctrica, que integran
el sistema de monitoreo en tiempo real, se realizó un análisis en conjunto con el personal
encargado de la planta energética del SIS ECU 911 Loja, a través de una reunión en
donde se determinó las variables electro energéticas a ser supervisadas en cada uno de los
diferentes equipos electro energéticos, siendo elegidas estas variables bajo criterios
técnicos que definen la “calidad de energía eléctrica” como: a) El estándar IEC 61000-4-
30 define el término “Calidad de Energía Eléctrica” como las características de la
electricidad en un punto dado de la red eléctrica, evaluadas con relación a un conjunto de
parámetros técnicos de referencia. b) El estándar IEEE 1159/1995 define el término
“Calidad de Energía Eléctrica” como la gran variedad de fenómenos electromagnéticos
que caracterizan la tensión y la corriente en un instante dado y en un punto determinado
de la red eléctrica, esto con el fin de garantizar un óptimo funcionamiento y mayor
duración de los equipos informáticos que dan soporte a todos los servicios que presta esta
126
entidad de seguridad pública, así como también, la elección de parámetros que permitan
conocer el consumo total de este recurso natural renovable, cada vez con mayor demanda
a nivel mundial.
Las limitaciones encontradas en el desarrollo del presente objetivo, se presentaron en dos
equipos de control y respaldo de control de energía eléctrica. En primer lugar, los módulos
de control automático DSE7320, los cuales fueron instalados y configurados por el
personal calificado del proveedor, los mismos que le asignaron un PIN de seguridad el
cual es necesario siempre que se requiera realizar un cambio en la configuración del
equipo, lastimosamente el PIN que posee el encargado del SIS ECU 911 Loja no es el
correcto, por lo que, no permite cambiar los parámetros del equipo, como los
correspondientes al aparato de la comunicación, remítase a la sección 6.1.2. Uno de los
inconvenientes que esto genera, es no poder cambiar la dirección de esclavo Modbus.
Como resultado no se pueden conectar al mismo canal de comunicación ModBus los dos
módulos que controlan los generados 1 y 2 debido a que cada esclavo debe tener una
dirección única en la red, con lo cual, finalmente se conectó el módulo que controla al
generador 1 al sistema de monitoreo, se eligió este generador porque alimenta a las cargas
críticas del SIS ECU 911. Es válido mencionar, que el sistema está diseñado para soportar
la comunicación con los dos módulos de control automático, por tal razón, en cuanto se
restablezca el PIN y se cambie la dirección de esclavo solo es necesario conectar la
interfaz al bus de comunicación del sistema de monitoreo.
Otro inconveniente que se produce debido a la distancia entre el último esclavo en la red
Modbus RTU hasta el maestro, al usar la interfaz RS232 habilitada por defecto en el
módulo DSE7320 no sería factible ya que este estándar soporta una distancia máxima de
15 metros, refiérase a la sección 4.1.3, como solución se utilizó el estándar de interfaz
RS485 que permite distancias de más de mil metros, para hacer uso de este estándar se
optó por utilizar un adaptador o convertidor de interfaz RS232 a RS485, como se muestra
en la sección 6.1.2.1.
Los parámetros de configuración correspondiente a la comunicación, mostrados en la
sección 6.1.2, correspondiente al módulo DSE7320, nos condiciona toda la red Modbus
RTU a adaptarnos a estos valores por lo que, los demás equipos se tuvieron que cambiar
sus parámetros de configuración para usar una tasa de baudios de 19200, un tamaño de
127
datos de 8 bytes, bit de parada igual a 1 y con paridad nula, para poder monitorear a los
equipos en el mismo lazo de comunicación.
En el caso de los analizadores de red DucaLCD96 485-RELE, como se indica en el
apartado 4.3.2, son tres los que se mantienen funcionando y monitoreando el suministro
eléctrico, pero uno de ellos se encuentra bloqueado, específicamente el tablero que
monitorea la alimentación eléctrica de los UPS identificado como “Tablero UPS”, el cual
no responde al presionar sus botones presentes en su interfaz y necesita ser enviado para
su reparación por el personal calificado del proveedor del dispositivo. Como en el caso
anterior, no nos permite realizar ningún cambio sobre sus configuraciones establecidas,
ventajosamente este tablero si cuenta con una dirección diferente que los demás esclavos
Modbus en la red, el inconveniente aquí surge con la velocidad del puerto (baudrate) que
difiere de los módulos DSE7320. Se logró solucionar este problema mediante el uso de
programación, reconfigurando el puerto serial con un valor de baudrate fijo a este esclavo,
logrando así integrar exitosamente este equipo al sistema de monitoreo. Finalmente, los
UPS 1 y 2 se encontraban operando sin ningún problema, estos implementan el protocolo
Modbus TCP en su tarjeta de expansión, la misma que se encontraba ya instalada y
configurada, para poder acceder a su servidor Modbus TCP y consultar sus respectivas
variables electro-energéticas. Los resultados de esta investigación quedan expuestos en
el capítulo 3.
Objetivo 2: Determinar los medios y protocolos de comunicación a utilizar para las
lecturas de los parámetros electro energéticos de cada uno de los equipos
seleccionados.
Este objetivo se encuentra estrechamente relacionado con el objetivo anterior, dado que,
gracias al estudio de los equipos de control y respaldo de energía eléctrica, se identificó
exitosamente el bus de campo y el protocolo de comunicación que todos los equipos
soportan. En la sección 6.1.2.1, se indica cómo se utilizó el protocolo de comunicaciones
Modbus en sus variantes Modbus RTU y TCP, para garantizar la transmisión de los datos
de forma confiable y segura. Se puede apreciar que se usó la interfaz RS485 para conectar
los equipos que soportan la configuración maestra/esclavo, estos equipos son los
analizadores de red y los módulos de control automático, mientras que para los UPS se
128
usó el estándar ethernet, ya que estos estos equipos soportan el modo cliente/servidor del
modo Modbus TCP.
La conexión física de los equipos de la red Modbus RTU se realizó con el cable UTP
cat.5e, dado que, el tamaño de la tramas Modbus para este proyecto en específico es de 8
bytes de información, y el ruido electromagnético presente en el medio, debió a la
presencia de generadores, trasformadores y líneas de tensión, el cable UTP junto con el
estándar RS485, el cual garantiza una reducción considerable del ruido electromagnético
gracias al sistema de líneas diferenciadas que implementa para transportar la información,
como se detalla en el apartado 4.1.6.3, esto en conjunto con las características del UTP
cat. 5e, proporcionaron una conexión estable y confiable para la transmisión de los datos
usando tres pares trenzados del cable UTP como las líneas A(+), B(-) y GND, como lo
define el estándar RS485. En el caso de los UPS se utilizó el mismo cable bajo el popular
estándar Ethernet bajo el protocolo Modbus TCP/IP. Los resultados se pueden observar
en el apartado 6.2 referente a la implementación del sistema de monitoreo.
Objetivo 3: Diseñar una interfaz humano-máquina que presente las lecturas de los
parámetros electro energéticos y capturas de alarmas a implementarse para ser
almacenadas en una base de datos y acceder a ellos a través de la web.
El cumplimiento de los objetivos anteriores, permitió desarrollar satisfactoriamente la
elaboración del diseño de la interfaz humano-maquina, la cual se diseñó con la
herramienta Qt Designer. Esta herramienta, facilita la creación de interfaces gráficas de
usuario, las cuales son más simples de manejar y entender para el usuario, así como otras
de sus ventajas descritas en la sección 4.2.4. La parte lógica, es decir, el código fuente,
de la HMI se desarrolló haciendo uso de la librería PyQt la cual es una adaptación de la
biblioteca gráfica Qt para el lenguaje de programación Python, refiérase al apartado 4.2.4.
En este mismo lenguaje se programó los controladores de cada modelo de equipo electro-
energético. Cada controlador básicamente se encarga de leer los datos en los esclavos
Modbus y luego de recibir los datos, decodificarlos y transformarlos en formato decimal
para poder presentarlos a través de la HMI, como se observa en la Figura 86 de la sección
6.2. Luego de este proceso se procede a subir o cargar la data en la base de datos
implementada con PostgreSQL como se muestra en la figura 84 del apartado 6.2, para
129
luego gestionar y visualizar los datos de manera remota a través de la interfaz web
desarrollada en Kibana como se presenta en la Figura 88 en el mismo apartado.
El desarrollo de la interfaz web creada con Kibana fue posible gracias a que la pila ELK,
es perfectamente compatible con la base de datos creada con PostgreSQL, lo que permitió
acceder a la tabla “esclavos” creada para almacenar las lecturas de las variables electro-
energéticas de los equipos de control y respaldo de energía eléctrica, haciendo uso de la
primera herramienta Logstash, el proceso para consultar los valores almacenados en la
tabla “esclavos” se describe en la sección 6.1.5.1. La siguiente etapa es trabajar con los
logs que se obtienen en la etapa anterior, por lo que, la herramienta Elasticsearch, la cual
es una base de datos en sí, almacena y prepara la información dando como resultado
archivos con formato. json, remítase a la sección 6.1.5.2, los cuales son compatibles con
la última etapa, la cual se trata de Kibana. En esta fase final, se configura y da forma al
dashboard, que es donde se observa de manera gráfica las distintas variables configuradas
con sus respectivos parámetros, como se indica en la sección 6.1.5.3. El resultado final se
observa en la sección 6.2 en la Figura 88. Es importante mencionar que el acceso remoto
a la interfaz web quedó restringido para ser visualizado dentro de la red interna del SIS
ECU 911 Loja.
Adicionalmente, se agregó otras características, como la alerta temprana a través de
correo electrónico el cual nos informa acerca del tipo de evento ocurrido, como puede ser
una alerta, alarma o test, que en el caso de presentar valores o estados considerados como
fuera del funcionamiento normal se informa al ingeniero encargado de supervisar dichos
equipos para que esté al tanto de la situación y pueda actuar según el caso lo amerite. Los
valores de centinela de los módulos DSE7320 y los test de los UPS en caso de presentar
valores fuera del rango normal como por ejemplo que el sensor de temperatura no se
encuentre instalado para el generador o la batería en los UPS se encuentre en mal estado
el programa emitirá un correo de alerta una vez cada día dentro del horario de trabajo del
personal a manera de recordatorio ya que el cambio de estos componentes se puede
demorar algunos días, todo esto con el fin de no saturar al usuario con el mismo correo
cada que el programa realiza la consulta de las variables.
130
Objetivo 4: Implementar pruebas del funcionamiento y validación de los datos
obtenidos por el sistema de monitoreo.
Finalmente, para el desarrollo de este objetivo se realizó pruebas de funcionamiento de
todo el sistema de monitoreo durante periodos de treinta días, constatando el correcto
funcionamiento al ejecutar todas las etapas mostradas en la sección 6.3, así como la
validación respectiva de los datos. Esta validación se realizó, comparando los datos
obtenidos por el presente sistema de monitoreo con los datos mostrados en la interfaz de
los equipos de control y respaldo de energía eléctrica. En las Tabla 26:, Tabla 27: y Tabla
28: que se encuentran en el apartado 6.3.1, se puede observar que los datos obtenidos
mantienen valores iguales en la mayoría de las variables, variando levemente en algunas
de ellas, dado que, el tiempo en que se tomaron las muestras no fueron exactamente los
mismos, provocando, como en el caso de la frecuencia pequeñas fluctuaciones. Con estas
pruebas y mediante la revisión completa del funcionamiento por parte el personal técnico
del SIS ECU 911 Loja, queda demostrado la verificación y validación de los datos que
presenta el sistema de monitoreo en tiempo real, cumpliendo este último objetivo en su
totalidad dando como resultado la culminación del presente proyecto, como lo indica la
certificación emitida por esta entidad, presentada en el anexo 16.
131
8. CONCLUSIONES
Una parte clave de la presente investigación, fue la adquisión de los datos correspondiente
a las variables electro-energéticas, medidas por los equipos de control y respaldo de
energía eléctrica procedentes de diferentes fabricantes, esto se logró con el análisis de los
protocolos de comunicación industriales, tomando en cuenta la disponibilidad de
información de los dispositivos de campo y sus especificaciones técnicas, llegando a la
conclusión de que el protocolo Modbus presenta mejores características para la
transmisión de información entre maestro y esclavos, además, de ser de código abierto.
Se diseñó una Interfaz Hombre-Máquina de carácter intuitiva y de fácil uso, que presenta
las lecturas de los parámetros electro-energéticos y alarmas establecidas de forma gráfica,
facilitando al operador diferenciar entre los diferentes estados de los elementos del
sistema, esto con la integración del software Qt Designer y el Lenguaje Phyton para la
programación, brindando así toda la información necesaria sobre el proceso al usuario y
permitiéndole conocer sobre las variables analógicas y digitales de todos los elementos
que comprenden el sistema de control eléctrico.
El almacenamiento de los datos que permite el resguardo de la información y la
publicación web de las lecturas de los parámetros electro-energéticos, se realizó en la
tabla “esclavos”, creada para este uso en específico en la base de datos, gestionada por
PostgreSQL de forma automática, haciendo uso de una “secuencia” para evitar sobre
escribir algún dato guardado anteriormente, evitando la pérdida del mismo.
Se evidenció, que las variables electro-energéticas medidas por cada equipo de control y
respaldo de energía eléctrica se almacenan en un formato que está configurado por el
fabricante del equipo, por ejemplo, en el caso de los tableros los valores negativos se
representan poniendo el bit más significativo en alto y la parte decimal se obtiene
multiplicando por un factor de escala, en cambio los UPS representan estos valores bajo
el formato IEEE 754, esto debido a que el protocolo ModBus no se encuentra
completamente desarrollado, por lo que, no especifica en que formato se debe almacenar
la información, esto se solvento, mediante una programación que incorpore sus
características individuales.
La gestión y presentación de los datos en el interfaz web se desarrolló utilizando la
herramienta Kibana de la pila ELK, obteniendo un entorno con información detallada,
132
gráfica y de fácil interpretación, con lo cual, se permite al personal encargado acceder o
consultar el estado de los equipos y los valores de las variables electro-energéticas en
cualquier parte del edificio que tenga accedo a la red interna del SIS ECU 911 Loja.
Los controladores desarrollados en código Python, los cuales se encargan de establecer
la comunicación con los equipos de control y respaldo de energía eléctrica y transformar
los datos a valores congruentes, hacen uso de la librería MinimalModbus en su versión
7.0 desarrollado por Jonas Berg, esta librería fue la única que requirió ser modificada,
para hacer un uso adecuado que cumpla con los requerimientos del sistema de monitoreo
del presente proyecto, dado que los equipos almacenan la información en formatos
distintos.
El sistema de monitoreo en tiempo real implementado, queda como una herramienta para
el desarrollo de futuras estrategias de control automático, como mejoras al sistema para
responder de manera inmediata frente a situaciones adversas. Los datos recopilados de
los parámetros electro-energéticos en tiempo real son útiles para realizar acciones de
control que eviten, por ejemplo: complicaciones o fallos graves en el sistema electro-
energético afectando a los equipos tecnológicos que dan soporte al funcionamiento
integral del SIS ECU 911.
El sistema de monitoreo se encuentra instalado y funcionando correctamente, esto con la
validación del personal técnico del SIS ECU 911, cumpliendo con la presentación de la
información en tiempo real sobre los parámetros electro-energéticos medidos en los
equipos de control y respaldo de energía eléctrica. Es así que, se entrega una herramienta
integral, la cual permite monitorear en tiempo real, todos los equipos que componen la
planta electro-energética en un único sistema, sin la necesidad de estar presente frente a
cada uno de los dispositivos, optimizando recursos tanto de software y hardware, así como
también, reducir los costos de implementación de este tipo de sistemas al hacer uso de
tecnologías libres.
133
9. RECOMENDACIONES
El manejo de los equipos de control de suministro y respaldo de energía eléctrica se debe
realizar con extrema precaución, debido a que se encuentran instalados en zonas de media
tensión. Además, se recomienda leer el manual de uso de cada equipo para evitar alguna
alteración en el funcionamiento de los equipos que no sea el adecuado.
En caso de requerir la consulta de una variable electro-energética que no esté contemplada
en el presente proyecto, se debe consultar las especificaciones generales del protocolo
Modbus del modo RTU como del TCP/IP que se especifican en datasheet según
dispositivo, con el fin de obtener la dirección del registro Modbus correspondiente a la
variable a medir, agregando esta dirección en el controlador desarrollado para el equipo.
En los sistemas de monitoreo y control de dispositivos, que se encuentran separados por
distancias relativamente grandes, se recomienda hacer uso de estándares de interfaz que
brinden las características adecuadas para garantizar el funcionamiento del sistema, como
por ejemplo, el estándar de interfaz RS-485 que permite distancias mayores a mil metros
y que brinda una elevada protección contra la interferencia electromagnética. Aunque,
hoy en día los puertos seriales RS485 y RS232 no son muy comunes en los ordenadores
actuales, es imprescindible el uso de adaptadores de interfaz que brinden las
características necesarias para el sistema de monitoreo a implementar.
En la programación de los controladores de cada equipo de control y respaldo de energía
eléctrica, se debe respetar el orden de las direcciones Modbus con sus respectivas
variables y unidades, caso contrario, existirán incoherencias en la presentación de los
datos en la HMI.
La interfaz humano-maquina es intuitiva y de fácil compresión para el usuario, aunque
de ser el caso, se pude consultar en el anexo 15 de este proyecto, la guía de usuario de la
HMI.
La compresión del proceso de diseño, desarrollo e implementación del sistema de
monitoreo requiere de un nivel de conocimiento medio de programación en C++, Big
Data y Python, por lo que se recomienda al investigador incrementar sus habilidades en
estos temas.
134
Como trabajo a futuro se recomienda realizar un análisis de la regresión de las lecturas de
las variables electro energéticas que permita determinar la correlación de los datos
obtenidos entre el software de monitoreo y los que presenta el equipo en su panel de
control, con el fin de obtener de forma analítica el grado de exactitud y precisión que
presentan los datos mostrados en la HMI del presente proyecto.
Finalmente, se debe realizar pruebas de funcionamiento al sistema de monitoreo
implementado, como la realizada en la presente investigación, mínimo cada 6 meses para
validar el correcto funcionamiento del sistema, dado que, pueden existir actualizaciones
tanto de librerías usadas en Python, actualizaciones del sistema operativo o
actualizaciones del firmware de los equipos de control y respaldo de energía eléctrica que
comprometan el correcto desempeño del presente sistema.
135
10. BIBLIOGRAFÍA
Aldás Alarcón, A. P. (2016). Diseño de un Sistema de Gestión de la Calidad para el
Departamento de Desarrollo de Software de la PUCE. Quito.
Berg, J. (19 de Enero de 2019). MinimalModbus. Obtenido de
https://minimalmodbus.readthedocs.io/en/master/usage.html#using-multiple-
instruments
Candelas-Heredias, F. (2011). Comunicación con RS_485 y MODBUS. Obtenido de
https://rua.ua.es/dspace/bitstream/10045/18990/1/AA-p3.pdf
Cerezuela Martínez, M. (2014). Protocolos de Comunicación en Automatización
Industrial. Cartagena: Universidad Politécnica de Cartagena.
Chambi, J. &. (2006). Comparación entre MySQL y PostgreSQL . Cuenca.
Company, The Qt. (22 de Diciembre de 2018). Complete software development
framework | Qt. Obtenido de https://www.qt.io/what-is-qt/
Contemporary Controls. (12 de Diciembre de 2018). the EXTENSION: A Technical
Suplement to control NETWORK. Obtenido de
https://www.ccontrols.com/pdf/ExtV1N1.pdf
DUCATI Energia SpA. (26 de Diciembre de 2018). DUCATI energia. Obtenido de
https://www.ducatienergia.com/media/products/140729-1633-duca-lcd96-
manual-usuario-v11-es.pdf
EATON. (30 de Diciembre de 2018). Eaton 9390 UPS (sistema de energía
ininterrumpida) 40-160 kVA. Obtenido de
http://powerquality.eaton.com/Products-services/Backup-Power-
UPS/9390.aspx?cx=8&GUID=AF07AB25-594F-47CE-B1E7-1B74D8D9CD95
Elasticsearch . (2018). Elastic. Obtenido de https://www.elastic.co/use-cases
Iruela, J. (23 de 12 de 2018). Revista digital. Obtenido de INESEM:
https://revistadigital.inesem.es/informatica-y-tics/los-gestores-de-bases-de-
datos-mas-usados/
Lefebvre, L. (21 de Enero de 2019). pyModbusTCP 0.1.8. Obtenido de
https://pypi.org/project/pyModbusTCP/
136
Manton, A. (2009). Modulo de Control Series DSE7200/DSE7300. Mexico: IDIMEX.
Marais, H. (12 de Diciembre de 2018). ANALOG DEVICES. Obtenido de
https://www.analog.com/media/en/technical-documentation/application-
notes/AN-960.pdf?doc=an-1177.pdf
Martinez, M. C. (2014). Protocolos de comunicación en automatización industrial.
Obtenido de
http://repositorio.upct.es/bitstream/handle/10317/4338/pfc5902.pdf;jsessionid=E
307D9DC24D3DD2E3A07E26FD3C9D76E?sequence=1
Modbus-IDA. (2006). Modbus Application Protocol Specification V1.1b.
Moya Calderón, C. B. (2009). Software orientado a sistemas de control HMI/Scada
usando recursos libres y de código abierto, desarrollado sobre plataforma linux.
Quito: Universidad San Francisco de Quito.
National Instruments. (6 de Agosto de 2018). Información Detallada sobre el Protocolo
Modbus. Obtenido de http://www.ni.com/es-cr/innovations/white-papers/14/the-
modbus-protocol-in-depth.html
PDGD. Grupo de Desarrollo Global de PostgreSQL. (23 de 12 de 2018). PostgreSQL.
Obtenido de https://www.postgresql.org/
Python Software Fundation. (2018). Lenguaje de Programación Python. Obtenido de
https://www.python.org/psf/
RM Automatizacion. (15 de 08 de 2018). Migración de Sistemas Distribuidos. Obtenido
de https://rmautomatizacion.com/inicio/soluciones/migracion-sistemas-
distribuidos/
Rouse, M. (25 de Diciembre de 2018). TechTarget. Obtenido de
https://searchitoperations.techtarget.com/definition/Elastic-Stack
Samboya, N. (2012). Normas de comunicación en Serie: RS-232, RS-422 y RS-485.
Ingenio Libre, 86-94.
Suarez Pinzon, J. E. (2015). Diseño e Implementación de Sistemas SCADA para
Automatismos, basados en Hardware y Software Libre. Pereira: Universidad
Tecnologica de Pereira.
137
Tecnoplus. (27 de Diciembre de 2018). Tecnoplus. Obtenido de CUADROS DE
CONTROL - MONO+TRIFASICO+diferencial:
http://www.tecnoplus.es/sites/default/files/Tecnoplus_AMF-DSE7320.pdf
Telecommunications Industry Association. (Marzo, 1998). Electrical Characteristics of
Generators and Receivers for Use in Balanced Digital Multipoint Systems,
TIA/EIA-485-A.
Texas Instruments. (August de 2008). The RS-485 Desing Guide. Obtenido de
https://www.google.com.ec/search?q=eia%2Ftia-
485+standard&oq=EIA%2FTia+485&aqs=chrome.5.69i57j69i61j69i58j69i65j0l
2.12098j0j7&sourceid=chrome&ie=UTF-8
Toledo Torres, D. D., & Urgilés Cárdenas, P. D. (2017). Diseño e Implementación de un
Sistema SCADA mediante Protocolo Modbus con Comunicación Inalámbrica
para el control de un Robot. Cuenca: Universidad del Azuay.
138
11. ANEXOS
139
11.1. Anexo 1: Manual de usuario del Analizador de Red DUCA-LCD96.
11.1.1. Características Técnicas.
140
141
142
143
144
11.1.2. Conexiones.
145
146
147
148
11.1.3. Funcionamiento.
149
150
151
152
11.2. Anexo 2: Manual de Operación Sistema de Control e Instrumentación DSE
Series 7200 / 7300.
11.2.1. Especificaciones.
153
154
155
156
157
11.2.2. Instalación.
158
159
160
11.2.3. Descripción de Controles: Puerto Serial.
161
162
11.2.4. PIN de Seguridad.
163
11.3. Anexo 3: Datasheet EATON 9390.
11.3.1. Opciones de conectividad del UPS EATON 9390.
164
11.3.2. Especificaciones técnicas.
165
11.3.3. Eaton Power Xpert Gateway (PXGX) UPS Card: Guía de Usuario.
11.3.3.1. Especificaciones Técnicas.
166
11.3.3.2. Registros Modbus.
167
168
11.4. Anexo 4: Especificaciones generales del protocolo Modbus - RTU Rev. 12.
(Mach Smart/Smart Più/ Duca47(-72)-SP/Duca-LCD/ Duca-LCD96).
169
170
171
172
173
11.5. Anexo 5: Protocolo de comunicaciones GenComm para uso con 550, 555,
5210 y 5220 controladores (DSE7320).
174
175
176
177
178
11.6. Anexo 6: Mapa de registros Modbus TCP del UPS EATON 9390.
Display Name Base Address (1-based) Discrete Units Type Size (bytes)
Check Battery 1138 Yes
UPS On Battery 1149 Yes
Battery Test in Progress 2801 No no-units UINT 2
Battery Test Result 2802 No no-units UINT 2
System Status 3001 No no-units UINT 2
Output State 3003 No no-units UINT 2
Horn Status 3006 No no-units UINT 2
Van Input 4041 No volts FLOAT 4
Vbn Input 4043 No volts FLOAT 4
Vcn Input 4045 No volts FLOAT 4
Van Output 4047 No volts FLOAT 4
Vbn Output 4049 No volts FLOAT 4
Vcn Output 4051 No volts FLOAT 4
Van Bypass 4059 No volts FLOAT 4
Vbn Bypass 4061 No volts FLOAT 4
Vcn Bypass 4063 No volts FLOAT 4
Battery Voltage 4378 No volts FLOAT 4
IinA 5023 No amperes FLOAT 4
IinB 5025 No amperes FLOAT 4
IinC 5027 No amperes FLOAT 4
IoutA 5029 No amperes FLOAT 4
IoutB 5031 No amperes FLOAT 4
IoutC 5033 No amperes FLOAT 4
Watts In 6023 No watts FLOAT 4
Watts Out 6025 No watts FLOAT 4
VA In 6087 No volt-amperes FLOAT 4
VA Out 6089 No volt-amperes FLOAT 4
Percent Full Load 6185 No percent FLOAT 4
PF Disp Out 6203 No power-factor FLOAT 4
PF Disp In 6205 No power-factor FLOAT 4
Battery Capacity Remaining 7001 No percent FLOAT 4
Input Demand KW 7872 No kilowatts FLOAT 4
Output Demand KW 7874 No kilowatts FLOAT 4
Output Frequency 11003 No hertz FLOAT 4
Input Frequency 11005 No hertz FLOAT 4
179
11.7. Anexo Digital 7: Código fuente del controlador DUCA-LCD96
“duca_lcd_96.py”.
11.8. Anexo Digital 8: Código fuente del controlador DSE7320 “dse7320.py”.
11.9. Anexo Digital 9: Código fuente del controlador UPS9390 “ups_ecu.py”.
11.10. Anexo Digital 10: Código fuente de la clase “Dialogo_Correo”.
11.11. Anexo Digital 11: Código fuente de la clase “Dialogo_DB”.
11.12. Anexo Digital 12: Código fuente de la clase “Dialogo_alarmas”.
11.13. Anexo Digital 13: Código fuente de la clase “Dialodo_ConfigScada”.
11.14. Anexo Digital 14: Código fuente de la clase “Ventana”.
180
11.15. Anexo 15: Guía de Usuario del Software de Monitoreo del Sistema Eléctrico
del SIS ECU 911 Loja.
181
182
183
184
11.16. Anexo 16: Certificado de Funcionamiento del Sistema de Propuesto.
