2019 - Toscano Rojas

FACULTAD DE INGENIERÍA
Carrera de Ingeniería Informática y de Sistemas
PROPUESTA DE UN SISTEMA INMÓTICO PARA

LA AUTOMATIZACIÓN DEL MONITOREO DE
ENERGÍA RENOVABLE EN UN RESORT
Tesis para optar el Título Profesional de Ingeniero

Informático y de Sistemas
PIERO ALFONZO TOSCANO ROJAS

(ORCID0000-0002-9260-8333)
Asesor:
CECILIA MARÍN TENA DE SEBASTIÁN
(ORCID0000-0001-6194-7626)
Lima – Perú
2019
1
2
índice
RESUMEN .......................................................................................................................12
ABSTRACT .....................................................................................................................13
INTRODUCCIÓN .............................................................................................................14
PROBLEMA DE INVESTIGACIÓN ..................................................................................16
Identificación del problema ...........................................................................................16
Formulación del problema ............................................................................................17
Problema general .....................................................................................................17
Problemas específicos ..............................................................................................17
MARCO REFERENCIAL .................................................................................................18
Antecedentes ...............................................................................................................18
Antecedentes internacionales ...................................................................................18
Antecedentes peruanos ............................................................................................20
Estado del arte .............................................................................................................23
Marco teórico ...............................................................................................................27
OBJETIVOS ....................................................................................................................35
Objetivo general ...........................................................................................................35
Objetivos específicos ...................................................................................................35
JUSTIFICACIÓN..............................................................................................................36
HIPÓTESIS .....................................................................................................................37
Hipótesis general..........................................................................................................37
Hipótesis específicas....................................................................................................37
ALCANCES .....................................................................................................................37
MATRIZ DE CONSISTENCIA ..........................................................................................38
MARCO METODOLÓGICO .............................................................................................40
Metodología .................................................................................................................40
Paradigma ....................................................................................................................40
Enfoque........................................................................................................................40
Método .........................................................................................................................41
VARIABLES .....................................................................................................................41
POBLACIÓN Y MUESTRA ..............................................................................................43
UNIDAD DE ANÁLISIS ....................................................................................................43
INSTRUMENTOS Y TÉCNICAS ......................................................................................43
Instrumentos ................................................................................................................43
Técnicas .......................................................................................................................43
PROCEDIMIENTOS Y MÉTODO DE ANÁLISIS ..............................................................43
Procedimientos ............................................................................................................43
Metodología Extreme Programming (XP)..................................................................44
Planificación del proyecto .........................................................................................46
3
Diseño ......................................................................................................................51
Diagrama de Gantt (tiempos) ....................................................................................72
Estimación de costos ................................................................................................75
Estimación de flujo de caja, VAN y TIR .....................................................................80
Desarrollo del proyecto .............................................................................................83
Puesta a producción ...............................................................................................103
Evaluación de la propuesta del sistema inmótico ....................................................105
Método de análisis .....................................................................................................108
RESULTADOS ..............................................................................................................112
DISCUSIÓN ...................................................................................................................130
CONCLUSIONES ..........................................................................................................132
RECOMENDACIONES ..................................................................................................133
REFERENCIAS .............................................................................................................135
4
Índice de figuras
Figura 1. Diagrama de Ishikawa para la identificación de causas del problema:
Interrupción de los servicios.. ...........................................................................................16
Figura 2: Frameworks (marcos de trabajo) de desarrollo web que continúan siendo

usados en el 2019. ..........................................................................................................25
Figura 3: Figura 3: Funcionamiento de AJAX. ..................................................................26
Figura 4: Estructura del protocolo MQTT. ........................................................................32
Figura 5: Rutas de ataque de aplicaciones web. ..............................................................34
Figura 6: Diagrama de diseño preprueba/posprueba de un grupo. ..................................40
Figura 7: Diagrama del ciclo de vida de un proyecto XP. .................................................45
Figura 8: Diagrama del ciclo de la iteración en la metodología XP. ..................................51
Figura 9: Diagrama de Gantt para el desarrollo del proyecto.. .........................................72
Figura 10: Interfaz de Visual Studio Code.. ......................................................................83
Figura 11: Vista general de los diseños de las interfaces en Figma. ................................85
Figura 12: Interfaz phpMyAdmin, para la administración de la base de datos MySQL.. ...86
Figura 13: Distribución de los pines analógicos y digitales del módulo ESP32 devkit v1..87
Figura 14: Pantalla de inicio de PlatformIO en Visual Studio Code. .................................88
Figura 15: Raspberry Pi 4 Modelo B. ...............................................................................89
Figura 16: Acceso al sistema.. .........................................................................................90
Figura 17: Mapa visualizador de los estados de los ambientes del resort. .......................90
Figura 18: Mapa visualizador de los estados de los ambientes del resort indicando un
error en algunos de sus circuitos de un ambiente específico.. .........................................91
Figura 19: Listado de operarios disponibles para la emisión de la orden de reparación.. .91
Figura 20: Mapa visualizador con los ambientes del resort indicando el que tiene una
orden de reparación emitida pendiente.. ..........................................................................92
Figura 21: Mapa visualizador de los estados de las fuentes de energía renovable del
resort.. .............................................................................................................................92
Figura 22: Mapa visualizador de los estados de las fuentes de energía renovable del
resort indicando un error en una de ellas específicamente.. ............................................93
Figura 23: Mapa visualizador con las fuentes de energía renovable del resort indicando el
que tiene una orden de reparación emitida pendiente.. ....................................................93
5
Figura 24: Relación de todos los ambientes del resort.. ...................................................94
Figura 25: Gráfico consumo – tiempo. .............................................................................94
Figura 26: Relación de todos los sectores de producción del resort.. ...............................95
Figura 27: Relación de todas las fuentes de producción de energía de un sector particular
del resort..........................................................................................................................95
Figura 28: Gráfico producción – tiempo. ..........................................................................96
Figura 29: Reporte de consumo de energía mediante búsqueda por periodo ..................96
Figura 30: Reporte de historial de consumo de energía de un ambiente particular del

resort, mediante búsqueda por periodo............................................................................97
Figura 31: Reporte de producción de energía mediante búsqueda por periodo. ..............97
Figura 32: Reporte de historial de producción de energía de una fuente de energía en

particular, una vez realizada la búsqueda por periodo.. ...................................................98
Figura 33: Gráfico de análisis de consumo y producción por periodo para la contrastación
entre ambos.. ...................................................................................................................98
Figura 34: Diseño de la base de datos.. ...........................................................................99
Figura 35: Listado de las peticiones HTTP en Postman.. .................................................99
Figura 36: Diagrama de la arquitectura de la aplicación web y su integración con el

sistema inmótico.. ..........................................................................................................101
Figura 37: Esquema del circuito de pruebas.. ................................................................103
Figura 38: Encuesta del pre-test en Google Forms.. ......................................................108
Figura 39: Encuesta del post-test en Google Forms.. ....................................................109
Figura 40: Recopilación de datos de las encuestas en el software SPSS.. ....................109
Figura 41: Medición de fiabilidad del pre-test. ................................................................110
Figura 42: Medición de fiabilidad del post-test. ..............................................................110
Figura 43: Frecuencia de la variable control_orden_reparacion. ....................................113
Figura 44: Frecuencia de la variable nivel_detalle_consumo_energia............................114
Figura 45: Frecuencia de la variable nivel_utilidad_consumo_energia. ..........................115
Figura 46: Frecuencia de la variable nivel_detalle_produccion_energia.........................116
Figura 47: Frecuencia de la variable nivel_utilidad_produccion_energia. .......................117
Figura 48: Frecuencia de la variable control_orden_reparacion_sist. .............................118
6
Figura 49: Frecuencia de la variable nivel_detalle_consumo_energia_sist. ...................119
Figura 50: Frecuencia de la variable nivel_utilidad_consumo_energia_sist. ..................120
Figura 51: Frecuencia de la variable nivel_detalle_produccion_energia_sist. ................121
Figura 52: Frecuencia de la variable nivel_utilidad_produccion_energia_sist.................122
Figura 53: Frecuencia de la variable nivel_calidad_reportes. .........................................123
Figura 54: Frecuencia de la variable nivel_interaccion_flujo_energia. ............................124
Figura 55: Histograma de la variable control_orden_reparacion. ...................................124
Figura 56: Histograma de la variable control_orden_reparacion_sist. ............................125
Figura 57: Histograma de la variable nivel_detalle_consumo_energia. ..........................125
Figura 58: Histograma de la variable nivel_detalle_consumo_energia_sist. ...................126
Figura 59: Histograma de la variable nivel_utilidad_consumo_energia. .........................126
Figura 60: Histograma de la variable nivel_utilidad_consumo_energia_sist. ..................127
Figura 61: Histograma de la variable nivel_detalle_produccion_energia. .......................127
Figura 62: Histograma de la variable nivel_detalle_produccion_energia_sist. ................128
Figura 63: Histograma de la variable nivel_utilidad_produccion_energia. ......................128
Figura 64: Histograma de la variable nivel_utilidad_produccion_energia_sist. ...............129
Figura 65: Histograma de la variable nivel_calidad_reportes. ........................................129
Figura 66: Histograma de la variable nivel_interaccion_flujo_energia. ...........................130
7
Índice de tablas
Tabla 1: Indicadores de la variable independiente. ..........................................................41
Tabla 2: Indicadores de la variable dependiente.. ............................................................42
Tabla 3: Historia de usuario H01.. ....................................................................................46
Tabla 10: Historia de usuario H08.. ..................................................................................49
Tabla 13: Tarjeta CRC de la clase “Login”.. .....................................................................53
Tabla 14: Tarjeta CRC de la clase “Usuario”.. ..................................................................53
Tabla 15: Tarjeta CRC de la clase “RolUsuario”.. ............................................................53
Tabla 16: Tarjeta CRC de la clase “Navbar”.....................................................................54
Tabla 17: Tarjeta CRC de la clase “Sidebar”.. ..................................................................54
Tabla 18: Tarjeta CRC de la clase “ControlConsumo”.. ...................................................54
Tabla 19: Tarjeta CRC de la clase “ControlProduccion”.. .................................................55
Tabla 20: Tarjeta CRC de la clase “AsignPersonalMantenimientoAmbiente”. ..................56
Tabla 21: Tarjeta CRC de la clase “AsignPersonalMantenimientoFuenteEnergia”. ..........56
Tabla 22: Tarjeta CRC de la clase “AnalisisConsumo”.. ...................................................56
Tabla 23: Tarjeta CRC de la clase “AnalisisConsumoAmbiente”. .....................................57
Tabla 24: Tarjeta CRC de la clase “AnalisisProduccion”.. ................................................57
Tabla 25: Tarjeta CRC de la clase “AnalisisProduccionSector”. .......................................57
Tabla 26: Tarjeta CRC de la clase “AnalisisProduccionFuente”. ......................................58
Tabla 27: Tarjeta CRC de la clase “HistorialConsumo”.. ..................................................59
8
Tabla 28: Tarjeta CRC de la clase “AnalisisConsumo” del rol de gerente. .......................59
Tabla 29: Tarjeta CRC de la clase “HistorialProduccion”..................................................60
Tabla 30: Tarjeta CRC de la clase “AnalisisProduccion” del rol de gerente. .....................60
Tabla 31: Tarjeta CRC de la clase “Reportes”..................................................................61
Tabla 32: Tarjeta CRC de la clase “ReparacionesPendientes”. .......................................62
Tabla 33: Tarjeta CRC de la clase “ReparacionesSolucionadas”. ....................................62
Tabla 34: Tarjeta CRC de la clase “Circuito”.. ..................................................................62
Tabla 35: Tarjeta CRC de la clase “ConsumoEnergia”.....................................................63
Tabla 36: Tarjeta CRC de la clase “Ambiente”.. ...............................................................63
Tabla 37: Tarjeta CRC de la clase “ProduccionEnergia”.. ................................................63
Tabla 38: Tarjeta CRC de la clase “FuenteEnergia”.. .......................................................64
Tabla 39: Tarjeta CRC de la clase “OrdenReparacion”.. ..................................................64
Tabla 40: Tarjeta CRC de la clase “PersonalMantenimiento”.. .........................................64
Tabla 41: Tarjeta CRC de la clase “RolUsuario”.. ............................................................65
Tabla 42: Tarjeta CRC de la clase “Usuario”.. ..................................................................65
Tabla 43; Tarjeta CRC de la clase “SectorConsumo”.. .....................................................65
Tabla 44: Tarjeta CRC de la clase “SectorProduccion”.. ..................................................66
Tabla 45: Tarjeta CRC de la clase “AmbienteController”.. ................................................66
Tabla 46: Tarjeta CRC de la clase “FuenteEnergiaController”.. .......................................66
Tabla 47: Tarjeta CRC de la clase “ConsumoEnergiaController”. ....................................66
Tabla 48: Tarjeta CRC de la clase “ProduccionEnergiaController”. ..................................67
Tabla 49: Tarjeta CRC de la clase “OrdenReparacionController”. ....................................67
Tabla 50: Tarjeta CRC de la clase “PersonalMantenimientoController”............................67
Tabla 51: Tarjeta CRC de la clase “SectorConsumoController”. ......................................68
Tabla 52: Tarjeta CRC de la clase “SectorProduccionController”. ....................................68
Tabla 53: Tarjeta CRC de la clase “UsuarioController”.. ..................................................68
Tabla 54: Tarjeta CRC de la clase “BaseConnection”.. ....................................................69
Tabla 55: Tarjeta CRC de la clase “AmbienteContext”.. ...................................................69
9
Tabla 56: Tarjeta CRC de la clase “FuenteEnergiaContext”.. ...........................................69
Tabla 57: Tarjeta CRC de la clase “ConsumoEnergiaContext”. .......................................69
Tabla 58: Tarjeta CRC de la clase “ProduccionEnergiaContext”. .....................................70
Tabla 59: Tarjeta CRC de la clase “OrdenReparacionContext”. .......................................70
Tabla 60: Tarjeta CRC de la clase “PersonalMantenimientoContext”. ..............................70
Tabla 61: Tarjeta CRC de la clase “SectorConsumoContext”.. ........................................71
Tabla 62: Tarjeta CRC de la clase “SectorProduccionContext”. .......................................71
Tabla 63: Cronograma de actividades de cada fase del proyecto. ...................................75
Tabla 64: Estimación de costos específicos durante la fase “Adquisición de equipos para
el prototipo”.. ....................................................................................................................76
Tabla 65: Estimación de costos de actividades para el desarrollo del prototipo. ..............78
Tabla 66: Costo total de sueldos.. ....................................................................................79
Tabla 67: Costo total de infraestructura tecnológica.........................................................80
Tabla 68: Costo de infraestructura tecnológica.. ..............................................................80
Tabla 69: Costo total de ejecución del proyecto.. .............................................................80
Tabla 70: Detalles de la recuperación de inversión del proyecto. .....................................82
Tabla 71: Requerimientos y especificaciones de las conexiones. ..................................102
Tabla 72: Encuesta de evaluación en el preprueba........................................................106
Tabla 73: Encuesta de evaluación en el posprueba.. .....................................................108
Tabla 74: Nombre de variables en SPSS.. .....................................................................111
Tabla 75: Estadísticos de la variable control_orden_reparacion.....................................112
Tabla 76: Frecuencia de la variable control_orden_reparacion. .....................................112
Tabla 77: Estadísticos de la variable nivel_detalle_consumo_energia. ..........................113
Tabla 78: Frecuencia de la variable nivel_detalle_consumo_energia. ............................113
Tabla 79: Estadísticos de la variable nivel_utilidad_consumo_energia. .........................114
Tabla 80: Frecuencia de la variable nivel_utilidad_consumo_energia. ...........................114
Tabla 81: Estadísticos de la variable nivel_detalle_produccion_energia. .......................115
Tabla 82: Frecuencia de la variable nivel_detalle_produccion_energia. .........................115
10
Tabla 83: Estadísticos de la variable nivel_utilidad_produccion_energia. ......................116
Tabla 84: Frecuencia de la variable nivel_utilidad_produccion_energia. ........................116
Tabla 85: Estadísticos de la variable control_orden_reparacion_sist. ............................117
Tabla 86: Frecuencia de la variable control_orden_reparacion_sist. ..............................117
Tabla 87: Estadísticos de la variable nivel_detalle_consumo_energia_sist. ...................118
Tabla 88: Frecuencia de la variable nivel_detalle_consumo_energia_sist. ....................118
Tabla 89: Estadísticos de la variable nivel_utilidad_consumo_energia_sist. ..................119
Tabla 90: Frecuencia de la variable nivel_utilidad_consumo_energia_sist. ....................119
Tabla 91: Estadísticos de la variable nivel_detalle_produccion_energia_sist. ................120
Tabla 92: Frecuencia de la variable nivel_detalle_produccion_energia_sist. .................120
Tabla 93: Estadísticos de la variable nivel_utilidad_produccion_energia_sist. ...............121
Tabla 94: Frecuencia de la variable nivel_utilidad_produccion_energia_sist. .................121
Tabla 95: Estadísticos de la variable nivel_calidad_reportes. ........................................122
Tabla 96: Frecuencia de la variable nivel_calidad_reportes. ..........................................122
Tabla 97: Estadísticos de la variable nivel_interaccion_flujo_energia. ...........................123
Tabla 98: Frecuencia de la variable nivel_interaccion_flujo_energia. .............................123
11
RESUMEN
En este proyecto de investigación se define la propuesta de un sistema inmótico para el

resort “El Campesino”, ubicado en el distrito de Santa Rosa de Quives, en la provincia de
Canta, con el propósito de automatizar y mejorar el proceso de monitoreo de las fuentes
de energía renovable del lugar, detección y solución de fallos en la red eléctrica. Asimismo,
emplea controladores, sensores y medidores para la obtención de datos. El sistema
inmótico emplea el protocolo MQTT (Transporte de Telemetría de Colas de Mensajes) para
el intercambio de datos con una aplicación web, de manera que sea bidireccional y no
requiera de refrescar la página para visualizar los datos más recientes provenientes del
controlador. El proyecto consta de un prototipo de un circuito controlado por un SoC
(sistema en un chip) ESP32, un microcontrolador totalmente compatible con Arduino con
conectividad Wifi y Bluetooth; junto con un panel y un motor de corriente directa para
simular algunas fuentes de energía renovable, del mismo modo cuenta con interruptores
para simular a algunos ambientes del resort. Mientras tanto, la aplicación web por el lado
del cliente está hecha con Angular, un framework de Javascript; por el lado del servidor,
posee una arquitectura REST (Transferencia de Estado Representacional), que trabaja con
objetos JSON (Objeto de Notación de Javascript), y está desarrollado con .NET Core,
conectado a una base de datos MySQL.
12
ABSTRACT
In this research project, the proposal of an inmotic system for the resort "El Campesino",
located in the district of Santa Rosa de Quives, in the province of Canta, is defined, with the
purpose of automating and improving the monitoring process of the renewable energy
sources of the place, detection and solution of failures in the electrical network. It also uses
controllers, sensors and meters to obtain data. The inmotic system uses the MQTT
(Message Queueing Telemetry Transport) protocol to exchange data with a web
application, so that it is bi-directional and does not require refreshing the page to view the
most recent data from the controller. The project consists of a prototype of a circuit
controlled by an ESP32 module, a fully Arduino compatible microcontroller with Wifi and
Bluetooth connection, together with a panel and a direct current motor to simulate some
sources, in the same way it has switches to simulate some environments of the resort.
Meanwhile, the web application on the client side is made with Angular, a Javascript
framework; on the server side, it has a REST (Representational State Transfer)
architecture, which works with JSON (Javascript Object Notation) objects, and is developed
with .NET Core, connected to a MySQL database.
13
INTRODUCCIÓN
En el Perú, uno de los sectores económicos más grandes que aporta al crecimiento del PBI
es el turismo. Según la última medición económica realizada por el Ministerio de Comercio
Exterior y Turismo, el turismo creció desde el 3.6% en el año 2011 al 3.9% en el año 2015
(2016). Sin embargo, se estima un crecimiento del 10% para este año 2020 (Portal del
Turismo, 2020). Dicho crecimiento da a entender que hay oportunidades para hacer
negocio en el sector turismo, como un lugar de hospedaje, un lugar recreativo, un
restaurante, etc.
El resort “El Campesino” está ubicado en el distrito de Santa Rosa de Quives, provincia de
Canta, que tiene un clima amigable y apto para las actividades recreativas y campestres.
Entonces, el resort tomó la decisión de implementar las fuentes de energía renovables por
3 principales razones: no contaminar el medio ambiente mediante el cuidado del
ecosistema del lugar; ser parte de su marca para identificarse mejor en el mercado y
distinguirse de otros negocios; así como reducir los gastos de energía.
Las fuentes de energía renovables se caracterizan, aparte de ser ecológicas, en generar

energía de manera infinita, garantizando el abastecimiento a largo plazo; pero para
realizarlo, es necesario que exista un control y monitoreo hacia su uso racional y eficiente
en el ámbito doméstico e industrial. Esto es debido a que los factores ambientales del
entorno son los que varían la producción de energía.
Para el desarrollo de la tesis, se ha tomado como referencia el resort “El Campesino”,

ubicado en el distrito de Santa Rosa de Quives, provincia de Canta. Este resort lleva poco
tiempo de ser inaugurado, pero tiene la infraestructura que le permite funcionar con
energías renovables. Además, presenta un clima amigable y apto para las actividades
recreativas y campestres.
De acuerdo a los requerimientos de ahorros y uso adecuado de energía, el resort tomó la

decisión de implementar las fuentes de energía renovables por 03 principales razones: no
contaminar el medio ambiente mediante el cuidado del ecosistema del lugar; ser parte de
su marca para identificarse mejor en el mercado y distinguirse de otros negocios.
Respecto al uso de energías renovables en el contexto peruano, OSINERGMIN sostiene

que, la participación en la producción de energía renovable es mucho mayor en el centro
del país, siendo Lima la región con mayor capacidad productiva (2019, p. 41). En el
contexto mundial, el turismo rural o comunitario fueron entrando cada vez más en países
de Europa y América Latina, ya que existen casos donde la energía renovable se
convirtieron en un atractivo turístico y de paso contribuyen también con el desarrollo
14
humano (Jimenez, 2014, p. 102). En contraste con el contexto peruano, no se ha
involucrado aún con el turismo, sino otros medios de protección al medio ambiente tales
como las áreas verdes o la reutilización del agua.
El propósito de esta investigación tiene que ver con la optimización del monitoreo y la
distribución de energía renovable en toda la red eléctrica por medio de la implementación
de un sistema inmótico mediante el Internet de las Cosas basado en una plataforma web.
De esa manera se procederá a automatizar los procesos de control y verificación del estado
de la red eléctrica y las fuentes de energía, de la misma forma con la customización de la
distribución de energía eléctrica del resort para suministrar la energía de manera eficiente
y asegurar la continuidad de los servicios que ofrece, en virtud de la implementación de
sensores y dispositivos inteligentes capaces de enviar y recibir datos a través de internet.
En cuanto al alcance de los objetivos, se realizarán mediciones de la energía en reserva,

comprobando que sea más que la energía demandada establecida para el funcionamiento
de los servicios del hotel.
15
PROBLEMA DE INVESTIGACIÓN
Identificación del problema
El resort “El Campesino” ha mantenido su filosofía de trabajar con energías renovables

desde que se inauguró, de esa manera operaría en convivencia con la naturaleza, donde
se garantiza el cuidado de ésta durante el uso de sus instalaciones.
Según el Ministerio de Agricultura (s.f.) existen 7 tipos de fuentes de energía renovables

en el Perú: hidráulica, térmica, eólica, solar térmica, solar fotovoltaica, de la biomasa y
geotérmica.
Últimamente la conciencia ambiental está ocasionando que las empresas, centros de

hospedaje y hogares están implementando las fuentes de energía renovable para su
funcionamiento con la finalidad de reducir los índices de contaminación. A esto se le suma
una mayor libertad en su uso sin afectar al planeta, así como la absolución de gastos de
consumo de energía eléctrica por parte de una entidad proveedora de electricidad y, por
cuestiones de negocio, aseguran que los servicios estén funcionando pese a cortes de
servicios por mantenimiento de la red pública.
El resort decidió implementar fuentes renovables de energía para evitar varios problemas
provenientes de la red pública y por razones económicas antes mencionados, así como
por razones de imagen, los cuales brindan un peso importante a la marca y la distingue de
otros clubes, centros campestres u hoteles de la zona.
Sin embargo, empezaron a surgir incertidumbres. Esto es debido a que no hay forma de
cómo monitorear la energía renovable, conocer cuánto es el flujo de energía, producción,
consumo y en qué estados se encuentran los componentes de la red eléctrica. A
continuación, se identificarán las causas del problema:
Figura 1. Diagrama de Ishikawa para la identificación de causas del problema: Interrupción de los servicios. Fuente:
Elaboración propia.
16
El equipo de mantenimiento del Resort es responsable de asegurar el funcionamiento
adecuado de las fuentes de energía. Sin embargo, resulta ser muy difícil llevarlo a cabo de
forma manual, porque están ubicados estratégicamente en zonas geológicas donde
aprovechan al máximo las fuentes renovables. Esto ocasionará que, en caso que fallen, no
produzcan energía y no respondan a la demanda energética de los ambientes, el cual no
garantizan la continuidad de los servicios.
Así como el equipo de mantenimiento es responsable del funcionamiento adecuado de las

fuentes de energía, lo es también con las instalaciones eléctricas de los ambientes. Sin
embargo, al llevarse a cabo de forma manual y al no supervisarse las instalaciones
eléctricas de manera constante, pueden surgir errores en ellas que no se solucionen a
tiempo.
Por otro lado, el equipo de mantenimiento también requiere reportar los consumos de luz.
Puesto que la red eléctrica no opera con la red pública, no está sujeta a una entidad
proveedora de luz y no puede reportar sus consumos de luz en base a recibos. Es en ese
punto que el equipo también desea saber la cantidad de energía consumida, pero no solo
el total del resort, sino también por ambiente, para ayudarles a tomar decisiones sobre qué
sitios del resort tienen más actividad y en qué momentos.
Al punto anterior se le suma la necesidad de contrastar con la producción de energía.

Debido a que tampoco hay un registro de la producción, el equipo tiene la incertidumbre si
las fuentes de energía responden a la demanda energética del resort.
Formulación del problema
Problema general
¿De qué manera un sistema inmótico automatiza el monitoreo de la energía renovable del
resort “El Campesino”?
Problemas específicos
¿De qué manera un sistema inmótico notifica instantáneamente los fallos detectados en la
red eléctrica del resort?
¿De qué manera un sistema inmótico maneja las fuentes de energía renovables empleados
en el resort para la obtención de datos de producción de energia?
¿De qué manera un sistema inmótico maneja la red eléctrica para la obtención de datos de
consumo de energía?
¿Un sistema inmótico mejora la visualización del flujo de energía en el resort?
17
MARCO REFERENCIAL
Antecedentes
Antecedentes internacionales
Peláez y Jiménez (2018) en su tesis “Diseño de un Sistema de Medición y Monitoreo del

Consumo de Energía por Circuitos en el Hogar, Mediante Tecnología de Comunicación por
Línea de Potencia” plantean la creación de una red local basada en la combinación de
protocolos de comunicación PLC (comunicación por línea de potencia) y TCP/IP, para
efectuar aplicaciones como la supervisión y adquisición de parámetros característicos de
energía, así como el almacenamiento automático de información proveniente del
dispositivo de medición que es transmitida y mostrada en tiempo real por medio de una
interfaz web. Los resultados obtenidos fueron el correcto funcionamiento de la red, que
garantiza la transmisión de información entre los dispositivos de medición y el servidor. Por
otro lado, se logró la visualización del consumo de energía en la interfaz web.
Orovwode, Wara, Mercy, Abudu, Adoghe y Ayara (2018) en su proyecto “Desarrollo e

implementación de un suministro de energía alternativa sostenible basado en la web para
una oficina modernizada” propusieron controlar la energía a tiempo real para el
abastecimiento del lugar utilizando la energía solar; además de emplear controles de
baterías para prevenir sobrecargas como sucede con cualquier implementación de fuentes
de energía renovable. Respecto a la aplicación web, se construyó la infraestructura basado
en la arquitectura cliente/servidor, donde en el cliente se aloja la interfaz web y en el
servidor se aloja el software de control. Mientras tanto, para el intercambio de datos entre
el servidor y el sistema de energía, aplicaron el uso de un microcontrolador que es un
Arduino Yun, que posee un fin para el Internet de las Cosas (IoT).
Belcredi, Modernell y Sosa (2015) en su tesis “Controlador de energía domiciliario para una
Red Eléctrica Inteligente” mencionan el concepto de Smart Grid que, en pocas palabras,
significa red eléctrica inteligente. Para lograr una optimización de la red eléctrica se debe
contar con un sistema de gestión eléctrica a nivel nacional, cuyos componentes de la
misma envían información a los usuarios en tiempo real; así como un controlador de
energía local que reciba la información, la procese y ejecute comandos de control sobre
los electrodomésticos. Para el desarrollo del proyecto se implementó una red inalámbrica
para la comunicación entre los dispositivos y el controlador de energía, así como la
implementación de circuitos que reportan el consumo de energía y de comandar el
encendido y apagado de los electrodomésticos junto con una interfaz web que visualiza el
consumo y envía los comandos a los electrodomésticos y un algoritmo para el control
18
básico de un termotanque en función a la tarifa del distribuidor del proveedor de energía y
de las características del hogar. Para poder implementarlos, los autores decidieron emplear
hardware y software Open Source con un propósito de colaborar con futuras
investigaciones. Respecto a los resultados, se lograron cumplir con los objetivos por medio
de generación de reportes de consumo de energía, el envío de comandos a los
electrodomésticos por la web y la aplicación de algoritmos de optimización en tiempo real.
Siguiendo con el tema de Smart Grid, Bejarano (2015) en su tesis “Plataforma Unificada
De Comunicaciones Multiservicio ‘Smart Grid’ Para El Monitoreo Y Control De Los
Procesos De Suministro Eléctrico En La República Argentina” lo propone para que el
mercado eléctrico argentino lo pueda adoptar y que represente un rol que juegan los
sistemas de telecomunicaciones en el mismo. El estudio explica, analiza y propone de
manera innovadora utilizar –con mínimo costo adicional– la Red Federal de Fibra Óptica
extendida con tecnología GPON y el Sistema Satelital Geoestacionario Argentino de
Telecomunicaciones para interconectar a la industria de la energía de conducción y así
crear la plataforma unificada de comunicaciones multiservicio “Smart Grid” en la provincia
de Buenos Aires a través de tecnología SCADA (Supervisión, Control y Adquisición de
Datos) para el monitoreo y control de los elementos activos y pasivos que participan en
esta propuesta en sus distintos escenarios de aplicación descritos como AMI (Advanced
Metering Infrastructure), HAN (Home Área Network), EVSE (Electric Vehicle Supply
Equipment), almacenamiento y venta de energía distribuida entre otros, los cuales
promueven la innovación permanente mediante economías de alcance y la transformación
del mercado de las telecomunicaciones. Se concluye que, a nivel de despliegue, Smart
Grid provee una alta demanda; a nivel de transporte y distribución, se tiene que desarrollar
una capacidad de interconexión con países adyacentes y desplegar la monitorización y
automatización por la red; a nivel del consumidor, deben crear mecanismos sencillos y
dinámicos para acercar a los clientes al mercado eléctrico.
Chiñas (2017) en su tesis “Diseño Y Desarrollo De Un Sistema De Monitoreo Basado En

La Web Para Una Plataforma Híbrida De Energías Renovables” tiene como finalidad
diseñar, desarrollar y crear un sistema de monitoreo, supervisión y adquisición de datos
basado en la web, para que a través de internet se pueda visualizar la información en
cualquier parte del mundo de los dispositivos electrónicos conectados dentro de una micro-
red con distintas fuentes generadoras de energía eléctrica por medio de energías
renovables. Este proyecto se divide en dos partes. La primera es el desarrollo y la
implementación de un analizador de redes eléctricas de bajo costo y su incorporación en
el Laboratorio de Energías Renovables (LabDER) del Instituto de Ingeniería Energética
19
(IIE) de la Universidad Politécnica de Valencia (UVP). Se realizaron pruebas de operación
y funcionamiento de dicho analizador para después comparar los parámetros eléctricos
contra otros analizadores industriales comerciales de mayor precio en el mercado. La
segunda parte se centra en el diseño de la página web, su vinculación con una base de
datos para la obtención de valores en tiempo real y el control de contactores de la micro-
red, tomando como referencia el SCADA local que se encuentra en una computadora
dentro del LabDER, con el fin de replicar todo su contenido en el sitio web a crear. Cabe
resaltar en cuanto al análisis de redes se utilizó un Arduino, pudiendo lograr con las
expectativas de ser económico, código abierto, multiplataforma y de obtención y
almacenamiento de datos de los parámetros eléctricos. Respecto al desarrollo web, el
lenguaje usado fue PHP junto con el motor de base de datos MYSQL.
Antecedentes peruanos
Canaza (2018) en su tesis “Desarrollo de un sistema de control para la medición

experimental de la eficiencia en tiempo real de un sistema fotovoltaico (38.4 watts) en el
departamento de Puno” presenta el desarrollo de un sistema de control para el monitoreo
en tiempo real de un panel fotovoltaico AEG Modelo PQ10/40/02 de 38.4 Watts de potencia,
usando como hardware un adquisidor de datos Arduino UNO R3, sensores de irradiación,
temperatura, voltaje y corriente. Y como softwares Matlab y IDE Arduino V.1.8.1. Los
sensores de irradiación y temperatura se utilizan para la verificar cómo las condiciones
ambientales influyen en la producción de energía del panel fotovoltaico en el departamento
de Puno, los sensores de voltaje y corriente son instalados en la bornera de salida del panel
fotovoltaico para la obtención de las curvas de voltaje - corriente, voltaje - potencia.
Mediante el modelamiento matemático de los paneles fotovoltaicos se valida, por una parte,
las características técnicas del panel fotovoltaico dadas por el fabricante y por otra parte
las curvas de voltaje - corriente, voltaje - potencia que fueron obtenidos en tiempo real en
campo por el sistema de control desarrollado en función a la influencia de las condiciones
ambientales. Este trabajo se realizó en el departamento de Puno del territorio peruano. Con
el cual se pretende demostrar que se puede realizar sistemas de control baratos, también
verificar cual es el verdadero desenvolviendo de los paneles fotovoltaicos en la región
Puno.
Sánchez (2015) en su artículo “Modelo matemático del sistema de medición de variables

climatológicas usando un microcontrolador” se elaboró un sistema de medición de variables
climatológicas usando un microcontrolador con su respectivo modelo matemático, así como
el desarrollo de una interfaz para monitorear las variables en línea, a fin de realizar lecturas
de los sensores de temperatura, radiación solar, dirección y velocidad del viento y su
20
almacenamiento. Esto permitirá disponer de información a los estudiantes de Ingeniería y
de los programas de Nivel Técnico Operativo del Senati, en la toma de decisiones para la
elaboración de equipos de energía renovable. El estudio de naturaleza Tecnológica se
desarrolló en 4 etapas, revisión documental referente a los diferentes sensores, diseño de
los sensores para capturar las variables, desarrollo de la programación para el
Microcontrolador 16F876 y por último desarrollo del modelo matemático con la interfaz
gráfica para visualizar las variables en línea. Los resultados obtenidos referentes al diseño
de los sensores reflejan un nivel de confiabilidad del 99% en el anemómetro y un 100% en
la veleta con relación a los equipos comerciales existentes para estaciones meteorológicas.
Romero (2015) en su tesis “Diseño de un sistema de monitoreo de parámetros eléctricos

basado en tecnología GSM para un riogenerador PUCP” parte del uso de los sistemas de
monitoreo a distancia por empresas que necesitan conocer el estado y funcionamiento de
sus equipos o de un sistema en particular. El monitoreo es realizado de forma remota
porque los equipos se encuentran ubicados en lugares alejados de las oficinas de las
empresas o en lugares donde el acceso es restringido. En particular, un regulador de carga
de un riogenerador, es un dispositivo que tiene por finalidad producir el acople correcto
entre una fuente de energía eléctrica, las baterías y los elementos de consumo. Con la
finalidad de conocer el funcionamiento adecuado de este dispositivo, es necesario el
monitoreo constante de dos parámetros: voltaje y corriente. Sin embargo, al estar ubicado
en un lugar distante, requiere un enlace vía una red de telecomunicaciones, tal como GSM.
El objetivo de esta tesis es el diseño de un sistema de monitoreo de parámetros eléctricos
de un riogenerador PUCP, empleando tecnología GSM. Para determinar la operatividad
del riogenerador, se eligió monitorear constantemente el voltaje y la corriente entre el
regulador de carga y sus baterías. Este riogenerador, construido por el Grupo PUCP, tiene
como finalidad generar energía eléctrica para zonas rurales aprovechando el caudal de un
río. Para alcanzar este objetivo, se analizará el estado del arte de la tecnología existente,
que se emplea en un sistema de monitoreo a distancia a fin de realizar la elección óptima
de sus elementos. Estas decisiones incluyen la selección de los sensores, el diseño de las
etapas de acondicionamiento, la programación de un microcontrolador, el desarrollo de una
interfaz web y el suministro de energía solar del sistema de monitoreo. Al final, se realizan
pruebas para comprobar y validar su funcionamiento.
Rosado (2018) en su tesis “Desarrollo de un Prototipo de Monitoreo y Supervisión de Costo

por Producto Fabricado por la Empresa Embotelladora San Miguel del Sur S.A.C.” plantea
una forma que le permita a la empresa tomar decisiones sobre sus máquinas y sobre el
grupo humano que conforma a la empresa por medio de la implementación de un sistema
21
automatizado de supervisión, monitoreo, adquisición y procesamiento de información de
manera local y/o remota, contribuyendo significativamente a una mejora en la gestión de
los gastos por mantenimiento y de operación en las empresas de este sector; siendo ésta
la razón por la que se ha realizado este proyecto con equipos industriales que permiten
una programación flexible, escalable, confiable y que se encuentran al alcance de las
empresas, además de prestar funcionalidades de comunicación industrial y visualización
web, lo que permite incluso llevar la información obtenida a través de internet e incluso a
través de tecnologías inalámbricas como Wi-Fi, al alcance de las manos de los
supervisores de producción y mantenimiento de las industrias. La interfaz web se crea por
medio del entorno de programación que ofrece el PLC, donde se definen tanto el diseño
como la visualización de los parámetros más importantes del sistema. Con el proyecto se
lograron el diseño del prototipo del sistema de monitorización como la creación de la
plataforma web, la integración de los equipos, la implementación de dispositivos modernos
y de un servidor en la nube. Los resultados permitieron la toma de decisiones para optimizar
la producción y la planificación, dosificación y el cálculo del costo de consumo eléctrico.
Benique (2017) en su tesis “Implementación del sistema web de supervisión, control y

adquisición de Datos - Scada en la empresa de generación eléctrica Machupicchu” plantea
una solución a una realidad problemática para los colaboradores de la entidad, puesto que
no tienen un conocimiento completo acerca de cuál es la cantidad de generación de energía
eléctrica que ocurre en EGEMSA, ya que, al ver esta situación, cada colaborador
desconoce este problema. Otra razón fundamental por la que se realizó esta
implementación del Sistema Web SCADA, es para no utilizar una licencia pagada al
ingresar al sistema SCADA para visualización, manipulación y control de este sistema, sino
de utilizar herramientas de software libre y de fácil adquisición, que puedan extraer la
información en tiempo real desde el Sistema SCADA, que está instalada y ubicada en el
Centro de Control en Cusco y en Machupicchu. Es por ello, que el presente trabajo de tesis
hace uso de herramientas de fácil adquisición, como por ejemplo Cogent Datahub, que
logrará la migración de datos en tiempo real y sin pérdida de datos con el protocolo OPC,
lenguajes de programación como PHP y C#, también los servicios que brinda Windows,
como el Internet Information Server (IIS), para publicar en un Servicio Web, así como la
utilización de máquinas virtuales para minimizar recursos para tal implementación.
Esperando que este aporte sirva de referencia para nuestras vidas profesionales en un
campo de acción de la línea en estudio y la empresa se sienta satisfecha con de repente
usar algunas recomendaciones que puedo proporcionarle, también que en el futuro se
pueda implementar varios sistemas de información que ayuden a la empresa, utilizando la
tecnología al alcance y de fácil adquisición.
22
Estado del arte
Inmótica y el internet de las cosas
La domótica e inmótica son aplicados en locales que se deseen automatizar. En sus inicios
solamente se podía hablar de domótica, además era bastante limitado por la tecnología
utilizada para la transmisión de datos y la accesibilidad, por lo que se permitía aplicarla en
espacios pequeños como hogares y en pequeñas oficinas. Sin embargo, está cada vez
más escalando a proyectos de arquitectura más extensos como edificios, industrias o
lugares públicos, cosa que dio origen a la inmótica.
La domótica e inmótica trabajan mucho mejor con el wifi para intercomunicar equipos e
interactuar con el usuario, de esa manera se pueden transmitir datos a mayor distancia y
de una manera más rápida.
La evolución de los equipos, los protocolos de comunicación, los medios digitales, las
tecnologías de los medios de transmisión de información y el desarrollo de software dieron
paso a nuevas formas de automatizar los espacios desde cualquier lugar. Eso dio paso al
internet de las cosas (IoT) y el uso de las aplicaciones web y móviles como medios de
interacción con el usuario.
Evolución del desarrollo web
Desde que el desarrollo dejó de ser caótico como lo era en su evolución y gracias a la
estandarización de HTML 5 por parte de la W3C (World Wide Web Consortium en sus
siglas en inglés), comenzaron a surgir roles más específicos en los equipos de desarrollo,
haciéndolo más organizado y más concreto para la repartición de tareas. Los tipos de
desarrollo en el campo de las aplicaciones web son los siguientes:
• Desarrollo front-end: Es aquel desarrollo del lado del cliente, donde el

desarrollador opera con los diseñadores para crear las páginas web, darles estilos
y lógica de interacción con el usuario final. El desarrollo front-end se fundamenta a
partir de 3 tecnologías:
o HTML (lenguaje de marcas de hipertexto): Es la base de las páginas web,
el cual define su estructura. Con ello se crean los campos de texto,
formularios, tablas, imágenes, etc. Cabe resaltar que solo se debe usar para
la estructura de la página web y no para su diseño.
o CSS (hojas de estilo en cascada): Como su nombre lo indica, proporciona
los estilos a HTML. Es decir, define el diseño de las páginas web. Gracias a
23
su estandarización, las páginas web se fueron adaptando a diferentes
tamaños de pantalla, técnica conocida como “Responsive design”.
o JavaScript: Es el único lenguaje de programación que funciona del lado del
cliente, puesto que corre en el navegador web sin la necesidad de compilar,
brindándole interactividad a las páginas web mediante la manipulación del
DOM (modelo de objeto de documento).
Si bien es cierto, la manipulación del DOM era muy difícil solo con JavaScript, para
ello surgieron librerías como JQuery. Actualmente los conflictos y la
incompatibilidad entre los navegadores se fueron reduciendo a tal punto de que
esas librerías se hicieran obsoletas y el enfoque de JavaScript se fue dirigiendo a
potenciar el desarrollo web. A partir de ahí se fueron creando frameworks (marcos
de trabajo) y librerías de JavaScript. Según los resultados de encuestas a
desarrolladores realizadas por Stack Overflow en el 2019, los tres más importantes
son:
o React.js: Es una librería desarrollada por Facebook de código abierto que

está basado en componentes reactivos, que consisten en elementos
reutilizables y tienen reglas para comunicarse con el resto del sitio web.
o Angular/Angular.js: Es un framework desarrollado por Google que también
se basa en componentes reutilizables, pero orientado al patrón MVC
(Modelo Vista Controlador) y enfocado a las SPAs (Single Pages
Applications, donde las páginas se crean bajo una sola página HTML). Cabe
resaltar que la documentación de Angular.js está creada con JavaScript,
mientras que Angular lo está con el lenguaje TypeScript.
o Vue.js: Es un framework creado y mantenido por su comunidad que también
trabaja con componentes y se enfoca en las SPAs, con la diferencia que es
adaptable a cualquier arquitectura y va creciendo con desarrollo del
proyecto.
24
Figura 2: Frameworks (marcos de trabajo) de desarrollo web que continúan siendo usados en el 2019. Fuente:
https://insights.stackoverflow.com/survey/2019
• Desarrollo back-end: Es el desarrollador que trabaja del lado del servidor, que
interactúa con las bases de datos, manipula los datos y realiza las consultas de los
datos, en síntesis, se encuentra la lógica del negocio. Puesto que el front-end es
abierto, donde el código fuente puede ser visto por el usuario, el back-end se
encarga de brindar seguridad a los datos y acceder a las peticiones del front-end,
siempre y cuando éste cumpla con los requisitos de acceso.
Existen variedades de frameworks de lenguajes de programación para el back-end.
En la misma encuesta sobre frameworks que continúan siendo usados hecha por
Stack Overflow, se encuentran:
o ASP.NET: Framework de desarrollo web para C#
o Express: Framework de desarrollo web para JavaScript (a través de
Node.js)
o Spring MVC: Framework de desarrollo web para Java
o Django y Flask: Frameworks de desarrollo web para Python
o Laravel: Framework de desarrollo web para PHP
o Ruby on Rails: Framework de desarrollo web para Ruby
Para que los datos se puedan transmitir desde el servidor al cliente sin recargar la
página, se realiza mediante una técnica llamada AJAX (JavaScript y XML
asíncrono), soportada por la mayoría de navegadores y sistemas operativos
móviles.
25
Figura 3: Figura 3: Funcionamiento de AJAX. Recuperado de: https://www.w3schools.com/xml/ajax_intro.asp
Para que los datos puedan ser leídos por el cliente, siendo este agnóstico del
lenguaje de programación del back-end, existen formatos de archivos para
representar esos datos:
o Servicios web REST (Transferencia de Estado Representacional) y
JSON (Notación de Objetos JavaScript): Es un protocolo cliente/servidor
para HTTP. Además, maneja cuatro principales métodos HTTP para
manipular los recursos: GET (consultar y leer), POST (crear), PUT
(actualizar) y DELETE (eliminar). Dichos métodos están relacionados con
las operaciones “select”, “insert”, “update” y “delete” de las bases de datos
SQL respectivamente.
o GraphQL: Es un lenguaje de consulta de datos creado por Facebook que
arranca por el lado del cliente. A diferencia de REST, es el cliente quien
controla la petición y recibe solo los datos que necesita.
La creación de gestores de paquetes ha ido evolucionando el desarrollo web hasta el punto

de involucrarse en otras plataformas, como el desarrollo móvil, programas de escritorio e
incluso comunicarse con dispositivos IoT.
Si bien se pueden crearse aplicaciones web dinámicas que pueden compartir datos
(enviarlas y recibirlas) con dispositivos IoT, es necesario de un protocolo de comunicación.
Los protocolos de comunicación utilizados para IoT no son ajenos, pues se basan en el
modelo OSI (modelo de interconexión de sistemas abiertos). Existen una variedad, pero
Gómez (2020, pp. 12-14) resalta los dos más importantes:
o CoAP: Es un protocolo a nivel de aplicación basada en REST, que es

cliente/servidor, mediante el acceso por una URL (localizador de recursos
26
uniformes) y los métodos GET, POST, PUT, DELETE, haciéndolo interoperable
con HTTP. La transmisión de datos se hace por UDP.
o MQTT (Transporte de Telemetría de Colas de Mensajes): Es un protocolo
también a nivel de aplicación, con la diferencia que es basado en el modelo
publicador/subscriptor, permitiendo que sea asíncrono y bidireccional.
Marco teórico
A continuación, se expondrán los conceptos relacionados que se involucran para el

desarrollo y el propósito de esta investigación.
Energías renovables
Según el Ministerio de Agricultura y Riego, la energía renovable son aquellas fuentes de

energía que llegan al planeta de forma continua y que en escala de tiempo real son
inagotables. Además, se definen dos tipos según el uso que tiene: las convencionales,
tales como la hidráulica de mayor potencia y las no convencionales, como la solar, eólica,
geotérmica, biomasa, picos hidráulicos, mareomotriz e hidráulica de pequeña potencia.
Sin embargo, las fuentes no entregan una cantidad uniforme de energía. Es ahí que se
necesite almacenarla para distribuirla uniformemente. Ourahou, Ayrir, EL Hassouni y Haddi
(2019) aclaran que, para preservar la estabilidad de la red mientras se absorben de las
fuentes de energía renovable, el almacenamiento de energía juega un papel importante
para preservar la estabilidad de la red y absorber las fuentes de energía renovables
intermitentes impredecibles (p. 21).
Resort
Según Toscani (2019), un resort no solo posee los servicios tradicionales de comida y
descanso como un hotel, sino que poseen otros servicios de diversas actividades tales
como restaurantes, bares o centros de recreación.
Según Catalonia Hotel & Resorts (2018), algunas características principales de los resorts
son:
• Están localizados en un ambiente natural, que abren el paso a una gran cantidad
de actividades de ocio adicionales.
• Permiten acceder a los servicios por un precio definido.
Los resorts, para garantizar la experiencia de sus usuarios, integran sus servicios de tal
manera que permiten la estadía por varias horas o incluso días.
Internet de las cosas
27
Se conoce como Internet de las cosas a la posibilidad de los objetos, ya sean de tipo
doméstico, mecánico, industrial o de cualquier índole; de enviar y recibir datos a través de
internet.
Para adaptar el concepto en el monitoreo de energía y medición inteligente; Viciana et al.

(2019) sostienen que deben seguir estándares como la IEC 61000-4-30 y la EN-50160.
Este sistema permite acceder a sus valores procesados o sin procesar desde una base de
datos por medio de una aplicación web (p. 5).
Smart grid
Es aquel sistema eléctrico que está integrada con las tecnologías de información y
comunicación (TIC), que acompaña en los procesos como distribución y producción e
involucra al usuario final.
Ourahou et al. (2019, pp. 23 - 25) menciona los requerimientos para que la red eléctrica
sea inteligente:
• Control de información del consumidor

• Alojamiento de tecnologías de producción
• Mercados de intercambio económico
• Prospectiva energética de calidad
• Especificación técnica y operativa
• Seguridad ante vulnerabilidades
Las energías renovables están integradas con el smart grid para dar solución a las
inconvenientes de sus usos. Sin embargo, requiere la adaptación de las infraestructuras y
la gestión del sistema eléctrico. Para ello, se debe contar con tecnologías de redes
inteligentes que cuenten con herramientas para la medición, almacenamiento de energía,
cargas controlables, entre otros. No solo eso, sino que deben optimizar los flujos de energía
para garantizar el equilibrio entre oferta y demanda. Para que el smart grid interfiera en el
sistema de energía renovable, debe cumplir con los siguientes puntos:
• Debe desarrollar pronósticos u observabilidad, es decir, monitorear la red, anticipar

de errores y ayudar en la toma de decisiones para optimizar la red eléctrica.
• Debe interactuar con la producción descentralizada mediante herramientas de
control, gestión y automatización.
• Debe gestionar la demanda para manejar el balance entre producción y consumo
y tomar acciones dependiendo de los periodos de actividad.
28
• Debe asegurar la flexibilidad de la red para que pueda gestionar la intermitencia y
variabilidad de las energías renovables.
Sistema inmótico
Para entender qué es un sistema inmótico, primero se debe comprender qué comprende
un sistema domótico. Hernández (2012, p. 7) define la domótica como el conjunto de
sistemas capaces de automatizar una vivienda, brindando servicios de gestión energética,
comunicación, comodidad y seguridad, integrados por redes de comunicación para el
control tanto dentro como fuera del hogar. Por otra parte, la domótica emplea las nuevas
tecnologías, involucrando la electricidad, electrónica, informática y comunicaciones.
Sánchez (2016, pp. 2-3) menciona 3 grupos a los cuales pertenecen los componentes de
los sistemas domóticos:
• Sensores: Son receptores de variables físicas del ambiente, mientras que otros
monitorizan el entorno para generar un evento que será procesado por el
controlador. Sin embargo, algunos fabricantes ya incluyen en sus equipos
características para que actúen como controladores, sensores o actuadores de
manera simultánea. Las variables físicas se identifican entre un rango de voltajes.
• Actuador: Reciben información digital o analógica de los sistemas y mediante el
voltaje indicado en el rango de voltaje de actuación mandan órdenes a los
dispositivos de salida: activan o desactivan, suben o bajan las intensidades o abren
o cierran los circuitos, etc.
• Controlador: Es el que enlaza el sensor con el actuador que, mediante la lógica
programada en él, manda señales de activación, inhibición o establecimiento al
actuador. Posee además las interfaces de usuario para el procesamiento de
información.
Cuando se trata de definir un sistema inmótico, tanto los componentes como los aspectos
tecnológicos prácticamente tienen los mismos conceptos como estaría definido un sistema
domótico. Las diferencias están en dónde se implementan: la domótica se aplica en la
automatización y control de viviendas, mientras que la inmótica es aplicado en ambientes
más amplios como una industria o edificios, es decir, a una escala mayor. Por ende, la
complejidad es mayor en la aplicación de los sistemas inmóticos, donde los componentes,
aparatos y los espacios son más grandes que la de los sistemas domóticos.
El sistema inmótico, como se mencionó, aplica a espacios más grandes que uno domótico,
por lo que requiere que controle procesos industriales. Es ahí donde entran otros
29
componentes como los dispositivos de entrada, que ya incluyen a los sensores, pero
también incluyen a máquinas industriales.
Así como se mencionó que el nivel de complejidad es mayor en un sistema inmótico, esto
aplica a los procesos a controlar, el manejo de las salidas y el canal de comunicación.
En caso de que se desee emplear una aplicación para interactuar con los equipos, el canal
de comunicación debe garantizar que los controladores y la aplicación puedan intercambiar
datos en todo el entorno o incluso por fuera. Por lo tanto, es necesario un protocolo de
comunicación que ayude a la aplicación y los controladores a “hablar el mismo lenguaje”.
Sistema web
Conocida también como aplicación web, es el software alojado en el servidor web, el cual
cuenta con una interfaz que interactúa con el usuario (lado del cliente o front-end) y los
servicios web (lado del servidor o back-end). El módulo principal está compuesto por un
Dashboard que muestra de manera sintetizada los procesos de distribución y monitoreo
con varios tipos gráficos.
Sin embargo, el front-end, principalmente por motivos de seguridad y flexibilidad en el

desarrollo, debe estar aislada de la base de datos y del sistema de gestión de energía; ya
que, al ser abierto, provocaría que se expongan datos sensibles.
API REST
API (Interfaz de Programación de Aplicaciones) permite la comunicación entre dos

sistemas por medio de protocolos y reglas. Los servicios web API REST son aquellos que
transfieren datos de manera representacional, siendo JSON el formato más utilizado. Cabe
destacar que trabajan con el protocolo HTTP (protocolo de transferencia de hipertexto en
inglés), lo cual brinda la posibilidad de trabajar con los distintos métodos de petición, como
manejar las distintas respuestas.
Para garantizar el correcto funcionamiento implica separar las capas del servidor web con
la API REST. De esa manera se logrará trabajar con concurrencia. Belcredi et al. aclaran
el término “programación concurrente”, que no es más que el trabajar en base a hilos de
ejecución o Threats. Por otro lado, otra manera de trabajar es la programación asíncrona,
donde una subrutina o función espera un resultado en varios puntos de salida (2015,
p.161). Un ejemplo de aplicación a este concepto son los callbacks que se hacen en
JavaScript.
30
Monitoreo de energía
Li, Luo, Yang, Ranzi y Wen en su proyecto explican dos aspectos para medir el consumo.
Uno de ellos es el perfil de consumo de energía no desplazable, que es prácticamente el
estilo de vida del usuario; el consumo de energía desplazable, la elasticidad de respuesta
a la demanda del usuario.
Respecto a la medición, mencionan también el Monitoreo No Intrusivo de Carga (NILM en

sus cifras en inglés) que, como su nombre lo dice, evita el uso masivo de dispositivos y es
una alternativa más económica que otras técnicas, como la instalación múltiple de
sensores. Sin embargo, la medición de carga es menos precisa. Elegir cuál sería la técnica
más adecuada dependería más del negocio y de cómo quieren manejar su información. No
sería lo mismo el nivel de detalle para una red de oficina u hogar como la de una empresa,
organización o smart city.
En cuanto al protocolo de comunicación, mencionan que se pueden aplicar distintos, pero

la elección dependería también del tamaño de la red a monitorear (pp. 405, 406).
Websockets
Existen múltiples herramientas y tecnologías para el desarrollo de servicios web, siendo

REST una de las más usadas, que portan el protocolo de comunicación HTTP. Sin
embargo, las técnicas para solicitar información y recibirla son unidireccional, es decir, se
crea un canal únicamente para el envío o la respuesta; a eso se le suman los bytes de la
cabecera, ocasionando inconvenientes para la transmisión de datos en tiempo real.
Para solucionar esos inconvenientes Cioffuletti (2017) menciona la implementación de

Websockets, considerándolo compatible con REST y que implementa una comunicación
bidireccional y sin restricciones, como un estilo TCP Socket tal como lo indica su nombre,
dentro de una sesión HTTP. También con una petición HTTP de actualización se procede
a cambiar al protocolo WebSocket. Además, los Websockets son suficientemente ligeros
para implementarlos a dispositivos IoT (pp. 3, 4), que intercambian datos en tiempo real.
Protocolo MQTT
La comunidad de MQTT (s.f.) la define de esta manera:
“MQTT [Transporte de Telemetría de Colas de Mensajes en sus siglas en inglés] es

un protocolo de conectividad máquina a máquina (M2M) / "Internet de las cosas".
Fue diseñado como un transporte de mensajes de publicación / suscripción
extremadamente ligera [...] se ha utilizado en sensores que se comunican con un
corredor a través de un enlace satelital, a través de conexiones de acceso telefónico
31
ocasionales con proveedores de atención médica y en una variedad de escenarios
de automatización del hogar y dispositivos pequeños. También es ideal para
aplicaciones móviles debido a su pequeño tamaño, bajo consumo de energía,
paquetes de datos minimizados y distribución eficiente de información a uno o
varios receptores [...]”
Cabe destacar que hay un intermediario (broker) que gestiona la comunicación. En la

siguiente imagen se define cómo funciona MQTT:
Figura 4: Estructura del protocolo MQTT. Recuperado de https://www.pickdata.net/es/noticias/mqtt-vs-coap-mejor-protocolo-

iot
Algunos autores como Moghimi, Liu, Jamborsalamati, Md Raf, Rahman, Hossain, Stegen
y Lu (2018, p. 7) consideran que MQTT, en la gestión de la energía en un sistema de
múltiples microrredes, como protocolo operativo, es su alta eficiencia de ancho de banda
de red, compatibilidad segura con servicios en la nube, bajo consumo de energía y
personalización de temas para los usuarios.
Hablando de los servicios en la nube, existen varios de ellos públicos y privados que
facilitan y agilizan el desarrollo de aplicaciones web que se integran con el internet de las
cosas, mediante la creación de MQTT brokers (intermediarios en inglés). Entre los más
usados son:
• Azure: Utiliza los puertos 8883 y 443 para MQTT y Websockets respectivamente.
Sostienen que se debe asegurarse con TTL (para asegurar en la capa de
transporte) y SSL (para asegurar en la capa de sockets).
• CloudMQTT: Se encarga de facilitar el desarrollo de aplicaciones sin invertir tanto
tiempo en crear e implementar el broker como los websockets. Tiene varios planes
y precios para la conectividad, velocidad de transmisión de datos, soporte para
32
correo, etc. Algunas ventajas más resaltantes son que es fácil de manejar y que
posee un plan gratuito para aquellos desarrolladores que están iniciándose en el
mundo a desarrollar aplicaciones para el internet de las cosas.
• Amazon Web Services IoT: Según la documentación, tiene la ventaja de estar
integrada con la nube de AWS. Además, brinda soporte para la calidad de servicio
(QoS) de nivel 0 y 1. A pesar de que la implementación sea MQTT versión 3.1.1.1,
existen variaciones específicas del funcionamiento ordinario.
• Mosquitto: Es un broker MQTT desarrollada por Eclipse para testing o
implementación en servidores y de carácter open source. Provee librerías en C para
la implementación de clientes MQTT, así como algunos comandos.
• IBM Cloud Service: En este caso es la plataforma Watson IoT la que actúa como
broker, encargada de la comunicación entre los dispositivos y la transmisión de
mensajes.
Para el desarrollo de aplicaciones web, existen librerías para la implementación de clientes

MQTT. Los clientes MQTT pueden actuar como publicadores o suscriptores, dependiendo
que si quieren publicar datos o recibirlos. Existen muchas librerías para varios lenguajes
como C, C++, Java, Phyton, etc. Javascript, al ser el único lenguaje que corre del lado del
front-end, existe una librería muy popular llamada Eclipse Paho, facilitando el desarrollo de
aplicaciones web basadas en MQTT. El concepto de MQTT sobre Websockets permite
apuntar a un broker habilitado de manera más directa con menos inconvenientes. Tanto
los clientes MQTT como los mensajes derivan de la clase Paho.MQTT, de ahí tienen sus
métodos para publicar mensajes o suscribirse a un topic.
OWASP (Open Web Application Security Project)
OWASP (Proyecto Abierto de Seguridad de Aplicaciones Web en español) es una

comunidad abierta dedicado a brindar asesoramiento a organizaciones para el desarrollo
de APIs seguras y confiables (OWASP, 2017, p. 1).
Los atacantes identifican y utilizan varias rutas para realizar robos o realizar daños. Estas
rutas de ataque pueden tener diferentes niveles de riesgos.
33
Figura 5: Rutas de ataque de aplicaciones web. Fuente: https://wiki.owasp.org/images/5/5e/OWASP-Top-10-2017-es.pdf
Según OWASP (2017, p. 6), los 10 mayores riesgos en las APIs son los siguientes:
• Inyección: Es el envío de datos no confiables a un intérprete, de manera que es

parte de un comando o consulta. Por ejemplo, inyección SQL a través de la interfaz
de usuario.
• Pérdida de autenticación y gestión de sesiones: Cuando la implementación de

la autenticación y gestión de sesiones es aplicada incorrectamente, permitiendo a
los atacantes asumir la identidad de otros usuarios.
• Exposición de datos sensibles: Datos sensibles como información financiera o

de identidad pueden ser robados o modificados por los atacantes para cometer
delitos como robo de identidad o estafa financiera.
• Entidad externa de XML: Los procesadores de XML mal configurados evalúan

referencias a otras entidades en documentos XML que pueden usarse por los
atacantes para revelar archivos mediante la URI o en servidores no actualizados,
escanear puertos, denegar servicios o ejecutar código remotamente.
• Pérdida de control de acceso: Los atacantes pueden aprovechar las restricciones

sobre los usuarios autenticados mal aplicados para el acceso de datos o permisos
y modificarlos.
• Configuración de seguridad incorrecta: Sucede por establecer la configuración

manualmente, por omisión o ad hoc. Algunos ejemplos son cabeceras HTTP mal
configuradas, mensajes de error con contenido sensible, componentes
desactualizados, etc.
34
• Secuencia de comandos en sitios cruzados (Cross-Site Scripting o XSS):
Sucede cuando una aplicación toma datos no confiables y las envía al navegador
sin validarlos ni con codificación apropiada.
• Deserialización insegura: Sucede cuando una aplicación recibe objetos

serializados dañinos que pueden ser manipulados o borrados por los atacantes
para realizar ataques de repetición, inyecciones, elevar los privilegios de ejecución
y ejecutar código en el servidor.
• Uso de componentes con vulnerabilidades conocidas: Los atacantes pueden

tener conocimiento sobre vulnerabilidades encontradas en bibliotecas, frameworks
y otros módulos para aprovecharlos y realizar ataques a partir de esas
vulnerabilidades.
• Registro y monitoreo insuficientes: Permite que los atacantes puedan

mantenerse infiltrados sin ser descubiertos, de manera que puedan realizar sus
ataques por más tiempo.
JWT (JSON Web Token)
Según Jones, et al. (2015), JWT es un estándar abierto (RFC-7519) basado en JSON que
consta de un formato compactado de representación de reclamaciones (claims) destinados
a entornos con limitaciones de espacio tales como las cabeceras de las autorizaciones de
los métodos HTTP.
JWT brinda seguridad y validez al momento de enviar datos entre aplicaciones y servicios.
Los casos más comunes se dan en la autenticación de los usuarios para garantizar el
acceso a los recursos del servidor sin antes saber quiénes son.
OBJETIVOS
Objetivo general
Aplicar un sistema inmótico para la automatización del monitoreo de la energía renovable

del resort “El Campesino”.
Objetivos específicos
Notificar instantáneamente los fallos detectados en la red eléctrica del resort mediante un
sistema inmótico.
Manejar las fuentes de energía renovables empleados en el resort y obtener los datos de
la producción de energía utilizando un sistema inmótico.
35
Manejar la red eléctrica y obtener los datos de consumo de energía empleando un sistema
inmótico.
Mejorar el nivel de visualización del flujo de energía en el resort con un sistema inmótico.
JUSTIFICACIÓN
Algo que las empresas de servicios de hospedajes y/o recreativos son conscientes es que
sus gastos de energía son principalmente por el consumo de esta por parte de sus clientes,
incluso más que para los procesos del negocio. Entonces, el resort tuvo la decisión de
implementar las energías renovables para evitar contaminando con fuentes fósiles,
situación que resaltaría más su imagen como resort; así como evitar gastos de consumo
de energía.
Los resorts como los centros recreativos en el campo se caracterizan por su arquitectura
horizontal, es decir, que abarcan más terreno cuando el negocio desea abarcar más
servicios. Sin embargo, no todos los ambientes se abastecen con la misma cantidad de
energía eléctrica. Como se mencionó, depende más de cuánto los usen los clientes.
Es a partir de ello, que el resort debe tomar decisiones acerca del manejo de su energía.
Gracias a que contamos con herramientas novedosas en la inmótica, el Internet de las
Cosas (IoT) y la variedad de frameworks de desarrollo web tanto front-end como para back-
end, es posible desarrollar un sistema inmótico basado en la web que conjuga una
aplicación web y su interacción con la red eléctrica del resort para monitorear la energía,
ayudar a mantener los servicios y las instalaciones ininterrumpidas en los momentos más
apropiados, así como saber qué ambientes del resort consume más energía o cuánta
energía se produce.
Respecto a que la investigación tenga una justificación práctica. Con esta investigación, se
podrá mejorar el control de las energías renovables, permitiendo tener un registro de
producción y consumo y distribuir la energía según el negocio lo requiera para satisfacer
algunos procesos de una mejor manera desde internet, así como brindar la portabilidad del
monitoreo desde cualquier dispositivo conectado y ayudar al resort en prevenir ante los
posibles cambios climatológicos para un mejor provecho de las fuentes. Además, el
sistema podrá ser escalable, ya sea a través de lógica de negocio como de infraestructura
de la empresa.
En cuanto al impacto del proyecto, se puede aplicar a nivel nacional; ya que este sistema
puede aplicarse en cualquier resort en el país. El sector turismo en el Perú es muy grande
donde, independientemente de la ubicación geográfica, se encuentran hoteles, centros
culturales y recreativos. Mientras tanto, los lugares donde están localizados poseen las
36
fuentes inagotables para generar energía eléctrica. Es cuestión de ver qué fuentes aplicar
y emplear el sistema para poder aprovecharlos de la mejor manera y a través de internet.
HIPÓTESIS
Hipótesis general
El sistema inmótico automatiza el monitoreo de la energía renovable del resort “El

Campesino” de manera que lo hace más eficiente.
Hipótesis específicas
El sistema inmótico realiza el seguimiento de la red eléctrica de manera automática

mediante sensores y controladores conectados a Internet, consiguiendo que la detección
de fallos sea instantánea y se notifique al equipo de mantenimiento del resort.
El sistema inmótico emplea medidores conectados a las fuentes de energía renovables y

controladores para la obtención de datos de la producción de energía.
El sistema inmótico emplea medidores por ambiente para la obtención de datos de

consumo de energía del resort.
El nivel de mejora de la visualización del flujo de energía es mucho mayor mediante un

sistema inmótico en el resort.
ALCANCES
La tesis está orientada a la propuesta de un sistema inmótico para automatizar el monitoreo

de energía renovable en un resort, tratando de mejorarla y hacerla más fácil para el
personal encargado para llevar a cabo mejor los procesos de negocio que implican a la red
eléctrica.
Sin embargo, la propuesta solo será a base de un prototipo que será una versión en
miniatura de la red eléctrica y las fuentes renovables, por lo que no será implementada aún
en el resort. Mientras tanto la evaluación de la propuesta será a través de la percepción de
parte de los trabajadores de mantenimiento.
37
MATRIZ DE CONSISTENCIA
TITULO PROBLEMA OBJETIVOS HIPÓTESIS VARIABLES METODOLOGÍA
Propuesta de un sistema Problema general Objetivo general Hipótesis general Variable independiente: Metodología:
inmótico para la Sistema inmótico
¿De qué manera un sistema Aplicar un sistema inmótico El sistema inmótico Correlacional bivariada
automatización del
inmótico automatiza el para la automatización del automatiza el monitoreo de Es la variable en el que se
monitoreo y distribución de Paradigma:
monitoreo de la energía monitoreo de la energía la energía renovable del centrará esta investigación,
energía renovable en un
renovable del resort “El renovable del resort “El resort “El Campesino” de el cual será manipulada por Positivista
resort
Campesino”? Campesino”. manera que lo hace más el investigador y no se verá
Enfoque:
eficiente. afectada por otras variables.
Problemas específicos Objetivos específicos
Cuantitativo
Hipótesis específicas Variable dependiente:
¿De qué manera un sistema Aplicar un sistema inmótico
Monitoreo de la energía Método:
inmótico notifica para notificar El sistema inmótico realiza el
renovable Experimental pre-
instantáneamente los fallos instantáneamente los fallos seguimiento de la red
detectados en la red detectados en la red eléctrica de manera Es la variable que se verá experimental
eléctrica del resort? eléctrica del resort. automática mediante afectada por la intervención
sensores y controladores de la variable independiente.
conectados a Internet, En este caso, se busca
inmótico maneja las fuentes para manejar las fuentes de
consiguiendo que la optimizarlo mediante el
de energía renovables energía renovables
detección de fallos sea sistema inmótico.
empleados en el resort para empleados en el resort y
instantánea y se notifique al
la obtención de datos de obtener los datos de la
equipo de mantenimiento del
producción de energia? producción de energía.
resort.
El sistema inmótico emplea
inmótico maneja la red para manejar la red eléctrica
medidores conectados a las
eléctrica para la obtención y obtener los datos de
fuentes de energía
de datos de consumo de consumo de energía.
renovables y controladores
energía?
Aplicar un sistema inmótico para la obtención de datos
para mejorar el nivel de de la producción de energía.
38
¿Un sistema inmótico visualización del flujo de El sistema inmótico emplea
mejora la visualización del energía en el resort. medidores por ambiente
flujo de energía en el resort? para la obtención de datos
de consumo de energía del
resort.
El nivel de mejora de la
visualización del flujo de
energía es mucho mayor
mediante un sistema
inmótico en el resort.
39
MARCO METODOLÓGICO
Metodología
La investigación tendrá un nivel pre experimental. A un grupo se le aplica una prueba

anterior al estímulo o tratamiento experimental, posteriormente del estímulo se le aplica
otra prueba. Este diseño sirve para saber el nivel que tenían las variables antes y después
del estímulo, como una especie de seguimiento. Sin embargo, no hay manipulación ni
grupo de comparación, así como la consideración de las fuentes externas de invalidación,
tales como la historia o acontecimientos que produzcan cambios (Hernández, 2013, p.
136).
El diagrama sería de esta manera:
𝐺 𝑂1 𝑋 𝑂2
Figura 6: Diagrama de diseño preprueba/posprueba de un grupo. Fuente: Hernández, 2013
Donde:
● 𝑂1 es la preprueba
● 𝑋 es la estimulación
● 𝑂2 es la posprueba
Paradigma
El paradigma será de carácter positivista, pues el estudio debe tener un carácter científico
donde los fenómenos que estudiaban las ciencias son medibles (Hernández, 2013, p. 4).
La principal razón de emplear el paradigma positivista es la aplicación de un método
científico para asegurar un buen término, avance y progreso creciente y pleno de sus
indagaciones, búsquedas, resultados y realizaciones (Ramírez, Arcila, Buriticá, Castrillón,
2004).
Enfoque
La investigación tendrá un enfoque cuantitativo, el cual es secuencial y probatorio. Se parte

de la idea que se acotará, se derivan objetivos y preguntas de investigación, se elabora un
marco teórico, surgen las hipótesis de las preguntas y se determinan variables, que
después se diseña un plan de prueba, se miden las variables en contexto, se aplica la
estadística para el análisis de mediciones obtenidas y se concluye (Hernández, 2013, p.
4).
40
Método
La tesis tendrá una característica experimental. Hernández (2013, pp. 121, 122) aclara que
se emplea cuando el investigador pretende establecer el efecto posible de una causa que
se manipula. En otras palabras, manipular las variables independientes (en este caso es el
sistema inmótico) para analizar las consecuencias sobre las variables dependientes (en
este caso es el monitoreo de la energía renovable). No siempre se pueden realizar
experimentos, por ejemplo, cuando el estímulo es imposible de manipular, con hechos
pasados o por cuestiones éticas. El investigador debe dominar las condiciones que se
tomarán en cuenta para realizar el experimento y modifica las variables independientes
para la obtención de resultados.
VARIABLES
Variable independiente
Sistema inmótico
Es la variable en el que se centrará esta investigación, el cual será manipulada por el

investigador y no se verá afectada por otras variables.
Indicadores de la variable independiente
N° Indicador Descripción
1 Gestión de órdenes Desempeño de llevar a cabo las órdenes para el

de reparación proceso de reparación.
2 Detalle de los datos Nivel de granularidad de los datos de consumo de

de consumo de energía.
energía
3 Detalle de los datos Nivel de granularidad de los datos de producción de

de producción de energía.
energía
4 Generación de Nivel de calidad que el sistema genera los reportes

reportes respecto a las expectativas del negocio.
5 Visualización del flujo Experiencia de usuario respecto a la calidad de datos e

de energía interactividad del sistema para visualizar la cantidad de
energía consumida y producida en tiempo real.
Tabla 1: Indicadores de la variable independiente. Fuente: Elaboración propia
41
Variable dependiente
Monitoreo de energía renovable
Es la variable que se verá afectada por la intervención de la variable independiente. En

este caso, se busca optimizarlo mediante el sistema inmótico.
Indicadores de la variable dependiente
Nª Indicador Descripción
1 Gestión de órdenes Desempeño de llevar a cabo las órdenes para el

de reparación sin el proceso de reparación antes de utilizar el sistema.
sistema
2 Detalle de los datos Nivel de granularidad de los datos de consumo de

de consumo de energía antes de utilizar el sistema.
energía sin el sistema
3 Utilidad de los datos Nivel de utilidad de los datos de consumo de energía

de consumo de antes de utilizar el sistema.
4 Detalle de los datos Nivel de granularidad de los datos de producción de

de producción de energía antes de utilizar el sistema.
5 Utilidad de los datos Nivel de utilidad de los datos de producción de energía

de producción de antes de utilizar el sistema.
6 Utilidad de los datos Nivel de utilidad de los datos de consumo de energía

de consumo de después de utilizar el sistema.
energía con el
sistema
7 Utilidad de los datos Nivel de utilidad de los datos de producción de energía

de producción de después de utilizar el sistema.
energía con el
sistema
Tabla 2: Indicadores de la variable dependiente. Fuente: Elaboración propia.
42
POBLACIÓN Y MUESTRA
Población
La población es el “conjunto de todos los casos que concuerda con una serie de
especificaciones” (Selltiz et al., 1980 citado en Hernández et al. 2006, p. 174). La población
para el proyecto de investigación está conformada por el personal que trabaja en el área
de control y mantenimiento del resort “El Campesino”, el cual está conformado por un
número determinado y pequeño de personas.
Muestra
La muestra es un subconjunto de la población, donde se recolectarán los datos y debe

delimitarse con precisión y debe representar a la población (Hernández et al. 2006, p. 174).
Para el desarrollo de la investigación, la muestra será del mismo tamaño de la población,
debido a que esta es muy pequeña, como se mencionó antes. Por lo tanto, el muestreo es
no probabilístico.
UNIDAD DE ANÁLISIS
Para esta investigación, la unidad de análisis serán las personas que laboran en el área de
control y mantenimiento del resort “El Campesino”, quienes tienen conocimientos y
experiencia acerca de elaboración de planes de contingencia y continuidad del negocio.
INSTRUMENTOS Y TÉCNICAS
Instrumentos
El instrumento para la presente investigación será el cuestionario, que permitirá realizar las
encuestas a los trabajadores.
Técnicas
La técnica empleada para la recolección de datos será la encuesta dirigida a los

trabajadores del área de control y mantenimiento del resort. La encuesta será en línea, de
esa manera se podrá realizarla de forma directa y asíncrona.
PROCEDIMIENTOS Y MÉTODO DE ANÁLISIS
Procedimientos
En este punto se detallarán las herramientas y avances realizados en el desarrollo del

proyecto, de la aplicación web y del sistema inmótico.
El desarrollo abarcará solo la primera fase del proyecto. Esta primera fase comprende el
prototipo del circuito, con el que se realizará la simulación con dos ambientes del resort:
43
lobby y restaurante. Así mismo se realizará la simulación con dos fuentes de energía: la
turbina 1, ubicada en el parque eólico 1; el panel solar 1, ubicado en el parque solar 1. Sus
ubicaciones en el mapa se detallarán en los diseños de las interfaces de usuario.
Respecto a la aplicación web, se desarrollarán los módulos de visualización del flujo de

consumo y producción de energía; los de detección y solución de fallos, y los de reportes
(consumo, producción y general).
Metodología Extreme Programming (XP)
Es una metodología leve de desarrollo de software, el cual consta de un sistema de

prácticas que van evolucionando por el equipo de desarrolladores para asegurar la calidad
del software y la adaptabilidad a los cambios. Los creadores de esta metodología fueron
Kent Bent y Ward Cunninghan en un proyecto piloto. Su nombre menciona que se aplica,
al extremo, las buenas prácticas de ingeniería de software (Laínez, 2014).
Al ser una metodología ágil, comparte similitudes con otras metodologías como SCRUM,
pero con algunas diferencias, siendo las más resaltantes la flexibilidad con los cambios en
la iteración, el tiempo de duración de las iteraciones, su enfoque con buenas prácticas, la
manera de trabajar como la programación por parejas, reutilización de código y la
retroalimentación. De esa manera se puede trabajar con versiones útiles del sistema, que
conlleva a empezar con una versión funcional en vez de una primera parte del sistema.
La metodología Extreme Programming comprende las siguientes fases:
• Exploración: Fase de captación de las necesidades del cliente, es decir, de los

procesos que desee que el sistema realice.
• Planificación de la entrega: Fase de estimación del esfuerzo del equipo para

desarrollar las historias de usuario.
• Iteraciones: Fase del desarrollo del proyecto, donde se desarrolla el código el

sistema.
• Puesta a producción: Fase de entrega de la solución culminada y validada al

cliente.
• Mantenimiento: Fase de brindar mantenimiento al sistema en funcionamiento.
• Muerte del proyecto: Ocurre cuando todas las necesidades del cliente en cuanto
al funcionamiento, confiabilidad y rendimiento del sistema ya se lograron satisfacer,
o cuando el cliente no cuenta con más presupuesto durante la fase de
mantenimiento.
44
Figura 7: Diagrama del ciclo de vida de un proyecto XP. Fuente: http://www.extremeprogramming.org/map/project.html
Roles
La metodología indica los roles para poder llevar a cabo los siguientes pasos para la
ejecución del proyecto. Bent y Cunninghan definieron los roles para trabajar con la
metodología XP. Sin embargo, la definición de los roles dependerá del tipo de proyecto o
del tamaño del equipo. Algunos son opcionales, mientras que otros son esenciales para
llevar a cabo cualquier proyecto.
• Cliente: Es quien escribe las historias de usuario, les asigna la prioridad y define
cuáles irán en cada iteración. Así mismo, define las pruebas funcionales para
validar la implementación de las historias de usuario.
• Programador: Es el encargado de desarrollar el código de la aplicación y de definir
las pruebas unitarias.
• Encargado de pruebas de desarrollo (test developer): Es quien ejecuta las
pruebas unitarias definidas por los programadores. Dependiendo del equipo, este
rol puede asumirlo uno de los programadores, que es el caso de este proyecto.
• Encargado de pruebas (tester): Es quien ejecuta las pruebas regularmente,
reporta los resultados de las pruebas y se encarga de las herramientas para la
ejecución de las pruebas. Por otro lado, ayuda al cliente en la definición de las
pruebas funcionales.
• Encargado del seguimiento (tracker): Como su nombre lo indica, es quien realiza
el seguimiento, donde brinda retroalimentación al equipo. De esta forma, verifica y
contrasta las estimaciones realizadas durante la planificación de la iteración con el
tiempo real para que después se definan cambios necesarios en la próxima
iteración.
• Entrenador (coach): Es quien guía a los miembros del equipo según las prácticas
de XP y se asegura que los procesos se sigan correctamente.
45
• Gestor (big boss): Es el jefe encargado de todo el equipo, quien brinda el entorno
de trabajo con las condiciones adecuadas y maneja los problemas.
• Consultor: Es un miembro externo del equipo con conocimientos de algún tema
que guía al equipo a resolver un problema específico.
En cuanto a las reglas y prácticas de XP, se agrupan en cinco categorías (Wells, 2006),
pero para el desarrollo del prototipo solo se usarán cuatro de ellos:
• Planificación del proyecto

• Diseño
• Desarrollo del proyecto
• Pruebas
Planificación del proyecto
Para la planificación del proyecto, el equipo se guio de los procesos de la metodología XP

para culminar la fase de desarrollo del prototipo y tener un entregable demostrado,
funcional y que realice lo que el cliente desee. De tal forma que se pueda proseguir con las
próximas fases hasta la implementación del sistema inmótico.
1. Historias de usuario
Para la elaboración de las historias de usuario se tomaron en cuenta las

necesidades de los usuarios, sus prioridades y sus requisitos de tiempo. Las
prioridades son definidas por el usuario. Sin embargo, para la estimación del tiempo
por cada historia, se consideró la disponibilidad del equipo de desarrollo, una vez
ya familiarizado y con el conocimiento de las herramientas, tecnologías,
frameworks, IoT, etc.
Historia: Acceso al sistema
ID: H01 Usuario: Gerente / Supervisor
Prioridad: Baja Estimación: 4 días
Descripción:
Como: Usuario del sistema
Quiero: Ingresar al sistema.
Para: Comenzar a utilizar el sistema.

Tabla 3: Historia de usuario H01. Fuente: Elaboración propia.
46
Historia: Estado de la red eléctrica
ID: H02 Usuario: Supervisor
Prioridad: Alta Estimación: 15 días
Descripción:
Como: Supervisor
Quiero: Monitorear los ambientes y las fuentes de energía en el mapa para ver
en qué estado se encuentran.
Para: Buscar errores.

Historia: Orden de reparación
Descripción:
Como: Supervisor
Quiero: Emitir una orden de reparación cada vez que se haya detectado un
error en la red eléctrica, ya sea del circuito de un ambiente o de una fuente de
energía.
Para: Mandar a un técnico para realizar esa reparación.

Historia: Flujo de consumo energético en tiempo real
Prioridad: Media Estimación: 7 días
Descripción:
Como: Supervisor
Quiero: Visualizar el consumo de energía de cada ambiente en tiempo real, el

total consumido, la lectura mínima y la lectura máxima durante el día.
Para: Monitorear el flujo de consumo energético de cada ambiente.

47
Historia: Flujo de producción energética en tiempo real
Descripción:
Como: Supervisor
Quiero: Visualizar la producción de energía de cada fuente en tiempo real, el

total producido, la lectura mínima y la lectura máxima durante el día.
Para: Monitorear el flujo de producción energética de cada fuente.

Historia: Historial de consumo de energía
ID: H06 Usuario: Gerente
Descripción:
Como: Gerente
Quiero: Ver el historial de consumo de energía de un periodo determinado y por

cada ambiente. De manera que se pueda tomar datos como el consumo total, el
máximo y el mínimo.
Para: Comparar los ritmos de consumo de energía entre los ambientes por
periodos definidos.
Historia: Historial de producción de energía
Descripción:
Como: Gerente
Quiero: Ver el historial de producción de energía de un periodo determinado y

por cada fuente renovable. De manera que se pueda tomar datos como la
producción total, la máxima y la mínima.
Para: Comparar los ritmos de producción de energía entre las fuentes de

energía renovables por periodos definidos.
48
Historia: Reporte general de energía
Descripción:
Como: Gerente
Quiero: Ver el reporte general de todo el flujo energético en el resort por

periodos definidos.
Para: Contrastar la producción y el consumo de energía en todo el resort.

Historia: Órdenes de reparación pendientes
ID: H09 Usuario: Personal de mantenimiento
Descripción:
Como: Personal de mantenimiento
Quiero: Ver las órdenes de reparaciones pendientes.
Para: Emitir la solución con su informe técnico.

Historia: Órdenes de reparación solucionadas
ID: H10 Usuario: Personal de mantenimiento
Descripción:
Como: Personal de mantenimiento
Quiero: Ver las órdenes de reparaciones solucionadas.
Para: Consultar cómo y cuándo se llevó a cabo la solución.

2. Velocidad del proyecto

Según Wells, es una medida de cuánto trabajo se está realizando en el proyecto.
Para medirla, se suman las estimaciones de las historias de usuario terminados y
las estimaciones de las tareas terminadas durante la iteración. Estas dos medidas
se utilizan para la planificación de iteraciones. La mejor forma de llevar el proyecto
49
avanzado es dando seguimiento a los trabajos realizados de manera constante y
predecible (2006).
3. Planificación de lanzamientos
Wells (2006) menciona que la planificación de lanzamientos se utiliza para crear
planes de iteración. La planificación de lanzamientos tiene un conjunto de reglas
para que todos los involucrados en el proyecto puedan tomar sus propias
decisiones, tanto el equipo como el cliente. De esta manera, se definen horarios a
los que todos puedan comprometerse y el equipo de desarrollo calcula la estimación
de las historias de usuarios, previamente elegidas por el cliente en función a la
prioridad que les dio.
4. Planificación de iteraciones
Para el comienzo de las iteraciones, primero se tuvo que realizar la estimación de
la disponibilidad del equipo en base al horario semanal ideal, que fueron 8 horas
diarias de lunes a viernes, descontando los días no laborables.
Para la planificación de cada iteración, el equipo se guío de las prácticas de XP
(Wells, 2006):
• La planificación de cada iteración se realizó al comienzo de cada una de
ellas.
• Cada planificación conlleva a la creación y asignación de tareas al equipo
de desarrollo, los cuales deben ser entendibles y prácticos para ellos, por lo
que se escribió empleando su lenguaje técnico.
• El tiempo de cada iteración debe ser entre una y tres semanas.
• Respecto a las historias de usuario, es el cliente quien decide cuáles se
trabajarán en la iteración en orden a la prioridad que les da.
• En cuanto a cosas pendientes de la iteración anterior, se consideraron las
tareas que no se completaron en la iteración anterior y los test pendientes
por corregir, de manera que se crean tareas que las respalden.
• La velocidad del proyecto de la iteración anterior se utiliza para determinar
el tiempo ideal de la iteración, es decir, la suma de los tiempos de las tareas
programadas; de manera que no debe excederse de la velocidad del
proyecto. En caso que ocurriese, el cliente deberá elegir qué historias de
usuario posponer para la siguiente iteración.
• Se trabajaron en programación por parejas en tareas que se consideraron
que sí aplicarían, tales como las que requieran la interacción entre el back-
end, el front-end y el controlador.
50
Figura 8: Diagrama del ciclo de la iteración en la metodología XP. Fuente:
http://www.extremeprogramming.org/map/iteration.html
Diseño
Las características y los elementos empleados en la fase de desarrollo son:
1. Simplicidad
XP sugiere realizar los procesos lo menos complejos posible para que el diseño sea
entendible y no genere conflictos durante el desarrollo. Es aquí cuando el equipo
de desarrollo busca identificar y nombrar las entidades a implementar en el sistema,
de manera que todos los involucrados en el desarrollo sepan qué se manipulará
durante la codificación.
2. Metáfora
Da la posibilidad de explica cómo funciona el sistema de una manera sencilla para

hacerlo entendible a cualquier persona. Para este proyecto se definió al sistema
como “un sistema inmótico basado en web que controla las energías renovables,
detecta fallos en la red eléctrica y reporta los estados de consumo y producción de
energía”.
3. Glosario de términos
Aunque se trate de nombrar las entidades y métodos de manera sencilla, existirán

términos que requieran de un nivel más complejo para describirlo mejor, sobre todo
métodos.
Para hacerlo sencillo, se trató de emplear palabras clave para definir mejor los
métodos sin la necesidad de emplear varios tecnicismos. De esta manera fueron
más entendibles y posteriormente pudieron describirse con la codificación.
4. Spike solutions (soluciones en base a exploración) para la reducción de

riesgos
51
El objetivo de estos tipos de soluciones es reducir el riesgo de algún problema
técnico o aproximarse más a la estimación de una historia de usuario.
Para evitar dificultades, se tomó la decisión de trabajar por parejas en los momentos
más enfocados a las integraciones entre las capas del sistema, con la finalidad de
que los desarrolladores de diferentes roles (IoT, front-end y back-end) puedan
determinar la forma de cómo se comunicarían, qué datos se transmitirían y cómo
desarrollarlas. Así mismo, se trató de configurar los entornos de desarrollo de cada
capa del sistema para evitar conflictos durante la codificación.
En cuanto a escribir código, se consideraron buenas prácticas que se basan en el

balance entre dos formas de trabajar: escribir código legible para escribir la menor
cantidad de comentarios posible, de forma que pueda entenderse bien y no requiera
de mucha documentación o más bien pueda autodocumentarse; la otra trata de
escribir menos código para la solución, pero el balance indica que, si escribir un
poco más de código lo hace más entendible, es mucho mejor. Esto se debe
principalmente a que los programadores pasan más tiempo leyendo que
escribiendo código, lo cual es muy considerable en la fase de pruebas y de
mantenimiento.
En caso que ocurriesen problemas externos, se planificó que serían discutidos por
el equipo de desarrollo o el cliente para encontrar soluciones. Cabe resaltar que,
por cada problema, se trate de encontrar su solución específica, ya que cada
problema se tiene que tratar de forma aislada de los otros. Esto se debe a que una
solución para varios problemas no lograría cubrirlos a todos por igual, ocasionando
que la reducción de riesgos no sea tan efectiva.
5. Tarjetas CRC (Clase, Responsabilidades y Colaboraciones)
Son tarjetas diseñadas para representar al sistema como equipo. Las tarjetas CRC
dan la facilidad al equipo con respecto al diseño y el entendimiento del sistema.
Además, suelen ser usadas para representar objetos. Las tarjetas consisten en el
nombre de la clase en la parte superior, las responsabilidades en el lado inferior
izquierdo y en el lado inferior derecho se colocan las clases colaboradoras (Wells,
2006).
Entonces, las tarjetas CRC ayudará de tres maneras, la primera es ayudando al

equipo en el diseño y en entender cómo funciona el sistema, la segunda es para su
desarrollo de forma rápida, de modo que los programadores puedan desarrollar con
un paradigma orientado a objetos y así puedan implementar mejor el patrón MVC
52
(Modelo Vista Controlador) y trabajar mejor con los frameworks de desarrollo front-
end como back-end.
A continuación, se muestran las tarjetas CRC diseñadas para la representación del

sistema inmótico:
Front-end
Login
• Autenticar las credenciales del • Usuario

usuario a ingresar
Tabla 13: Tarjeta CRC de la clase “Login”. Fuente: Elaboración propia.
Usuario
• Ingresar al sistema • RolUsuario
• Definir el rol del usuario
Tabla 14: Tarjeta CRC de la clase “Usuario”. Fuente: Elaboración propia.
RolUsuario
• Identificar el tipo de usuario
• Alistar el menú y los datos

correspondientes al rol del
usuario
Tabla 15: Tarjeta CRC de la clase “RolUsuario”. Fuente: Elaboración propia.
Navbar
• Mostrar los datos del usuario • Usuario

logueado en la barra
• RolUsuario
• Alistar las opciones del usuario
logueado
53
• Alistar el cierre de sesión de
usuario
Tabla 16: Tarjeta CRC de la clase “Navbar”. Fuente: Elaboración propia.
Sidebar
• Mostrar las opciones de • Usuario

navegación correspondientes
• RolUsuario
al rol del usuario logueado.
Tabla 17: Tarjeta CRC de la clase “Sidebar”. Fuente: Elaboración propia.
ControlConsumo
• Mostrar el mapa con los • Usuario

estados de cada
• RolUsuario
ambiente y de sus
circuitos en tiempo real.
• Ambiente
• Representar el listado
• Circuito
de los ambientes en el
mapa y sus órdenes de • Subscription
reparaciones
• OrdenReparacion
pendientes si tuvieran.
• MqttService
• Permitir visualizar los
errores que pueden
• AsignPersonalMantenimientoAmbiente
ocurrir en la red
eléctrica en tiempo real,
donde un circuito de un
ambiente falla.
• Permitir registrar una

orden de reparación
para cada circuito de un
ambiente con error
detectado.
Tabla 18: Tarjeta CRC de la clase “ControlConsumo”. Fuente: Elaboración propia.
54
ControlProduccion
• Mostrar el mapa • Usuario

con los estados de
• RolUsuario
cada fuente de
energía en tiempo
• SectorProduccion
real.
• FuenteEnergia
• Representar el
listado de las • Subscription
fuentes de energía
• OrdenReparacion
en el mapa y sus
órdenes de
• MqttService
reparaciones
pendientes si • AsignPersonalMantenimientoFuenteEnergia
tuvieran.
• Permitir visualizar
los errores que
pueden ocurrir en
alguna de las
fuentes en tiempo
real.
• Permitir registrar
una orden de
reparación para
cada fuente con
error detectado.
Tabla 19: Tarjeta CRC de la clase “ControlProduccion”. Fuente: Elaboración propia.
AsignPersonalMantenimientoAmbiente
• Listar los personales de • PersonalMantenimiento

mantenimiento disponibles.
• OrdenReparacion
55
• Asignar solo un personal de • Ambiente
mantenimiento para el circuito
• Circuito
del ambiente elegido.
• Emitir orden de mantenimiento
Tabla 20: Tarjeta CRC de la clase “AsignPersonalMantenimientoAmbiente”. Fuente: Elaboración propia.
AsignPersonalMantenimientoFuenteEnergia
• Listar los personales de • PersonalMantenimiento

mantenimiento disponibles.
• OrdenReparacion
• Asignar solo un personal de
• FuenteEnergia
mantenimiento para la fuente
elegida.
• Emitir orden de mantenimiento
Tabla 21: Tarjeta CRC de la clase “AsignPersonalMantenimientoFuenteEnergia”. Fuente: Elaboración propia.
AnalisisConsumo (supervisor)
• Listar los ambientes y sus • Subscription

consumos de energía.
• Ambiente
• Los consumos de energía se
• MqttService
muestran en tiempo real.
• AnalisisConsumoAmbiente
• Permitir escoger un ambiente
para ver su flujo de energía en
tiempo real.
Tabla 22: Tarjeta CRC de la clase “AnalisisConsumo”. Fuente: Elaboración propia.
AnalisisConsumoAmbiente
• Graficar el flujo de energía del • Subscription

ambiente escogido en tiempo
• Ambiente
real.
56
• Leer el total de energía • MqttService
consumido por el ambiente
elegido durante el día.
• Obtener el registro máximo y el

mínimo durante la visualización
del flujo de consumo de
energía del ambiente elegido.
Tabla 23: Tarjeta CRC de la clase “AnalisisConsumoAmbiente”. Fuente: Elaboración propia.
AnalisisProduccion (supervisor)
• Listar los sectores de • SectorProduccion

producción de energía del
• AnalisisProduccionSector
resort.
• Permitir ver las producciones

de energía en tiempo real de
las fuentes renovables de cada
sector.
Tabla 24: Tarjeta CRC de la clase “AnalisisProduccion”. Fuente: Elaboración propia.
AnalisisProduccionSector
• Listar las fuentes renovables y • Subscription

sus producciones de energía.
• Las producciones de energía
• FuenteEnergia
se muestran en tiempo real.
• MqttService
• Permitir escoger una fuente
renovable para ver su flujo de
• AnalisisProduccionFuente
producción de energía en
tiempo real.
Tabla 25: Tarjeta CRC de la clase “AnalisisProduccionSector”. Fuente: Elaboración propia.
57
AnalisisProduccionFuente
• Graficar el flujo de producción • Subscription

de energía de la fuente
• FuenteEnergia
renovable escogida en tiempo
real.
• MqttService
• Leer el total de energía

producido por la fuente elegida
durante el día.
• Obtener el registro máximo y el

mínimo durante la visualización
del flujo de producción de
energía de la fuente elegida.
Tabla 26: Tarjeta CRC de la clase “AnalisisProduccionFuente”. Fuente: Elaboración propia.
HistorialConsumo
• Permitir seleccionar el periodo • SectorConsumo

de consumo.
• Ambiente
• Validar que la fecha de inicio
• ConsumoEnergia
no sea posterior a la fecha
final.
• Obtener los registros de

consumo de energía diarios
por cada ambiente a partir del
periodo escogido.
• Repartir los porcentajes de

consumo eléctrico entre todos
los ambientes.
• Permitir ver a detalle el historial

de consumo de cada ambiente.
58
• Permitir exportar como PDF el
reporte de historial de
consumo.
Tabla 27: Tarjeta CRC de la clase “HistorialConsumo”. Fuente: Elaboración propia.
AnalisisConsumo (gerente)
• Graficar el historial de • Ambiente

consumo del ambiente elegido
• ConsumoEnergia
durante el periodo.
• Indicar el consumo máximo y

mínimo del ambiente elegido
en el periodo.
• Indicar el total de consumo

energético del ambiente
elegido durante periodo

reporte de consumo del
ambiente elegido durante el
periodo,
Tabla 28: Tarjeta CRC de la clase “AnalisisConsumo” del rol de gerente. Fuente: Elaboración propia.
HistorialProduccion
• Permitir seleccionar el periodo • SectorProduccion

de producción energética.
• FuenteEnergia
• Validar que la fecha de inicio
• ProduccionEnergia
no sea posterior a la fecha
final.
• Obtener los registros de

producción de energía diarios
59
por cada fuente renovable a
partir del periodo escogido.
• Agrupar las fuentes renovables

por su sector correspondiente.
• Repartir los porcentajes de

consumo eléctrico entre todas
las fuentes por cada sector.
• Permitir ver el detalle del

historial de producción de
energía de cada fuente.

reporte de historial de
producción.
Tabla 29: Tarjeta CRC de la clase “HistorialProduccion”. Fuente: Elaboración propia.
AnalisisProduccion (gerente)
• Graficar el historial de • FuenteEnergia

producción de energía de la
fuente elegida en un periodo.
• Indicar la producción máxima y

mínima de la fuente elegida en
el periodo.
• Indicar el total de producción

de energía de la fuente elegida
durante periodo

reporte de producción de
energía de la fuente elegida
durante el periodo,
Tabla 30: Tarjeta CRC de la clase “AnalisisProduccion” del rol de gerente. Fuente: Elaboración propia.
60
Reportes
• Graficar el historial de • ProduccionEnergia

producción de todas las
• ConsumoEnergia
fuentes renovables y consumo
de energía de todos los
ambientes durante en el
periodo.
• Indicar la producción máxima y

mínima con su respectiva
fecha en el periodo.
• Indicar el consumo máximo y

mínimo con su respectiva
fecha en el periodo.
• Calcular el total de producción

y consumo de energía durante
periodo.
• Obtener la ganancia o pérdida

de energía, restando la
producción menos el consumo.

reporte general durante el
periodo.
Tabla 31: Tarjeta CRC de la clase “Reportes”. Fuente: Elaboración propia.
ReparacionesPendientes
• Enlistar las órdenes de • PersonalMantenimiento

reparación por ambiente y
• OrdenReparacion
fuentes de energía emitidas
por los supervisores para el
• Ambiente
personal de mantenimiento.
61
• Permitir escribir un informe • Circuito
técnico para detallar cómo se
• FuenteEnergia
llevó a cabo la solución.
Tabla 32: Tarjeta CRC de la clase “ReparacionesPendientes”. Fuente: Elaboración propia.
ReparacionesSolucionadas
• Enlistar las órdenes de • PersonalMantenimiento

reparación por ambiente y
• OrdenReparacion
fuentes de energía ya
solucionadas por el personal
• Ambiente
de mantenimiento.
• Circuito
• Permitir los detalles como
informe técnico y fecha de • FuenteEnergia
reparación, además de otros
datos de la orden de
reparación.
Tabla 33: Tarjeta CRC de la clase “ReparacionesSolucionadas”. Fuente: Elaboración propia.
Back-end
Circuito
• Representar los datos de los

circuitos almacenados en la
base de datos.

circuitos procedentes de las
peticiones al servidor.
Tabla 34: Tarjeta CRC de la clase “Circuito”. Fuente: Elaboración propia.
ConsumoEnergia

consumos de energía
62
almacenados en la base de
datos.

consumos de energía
procedentes de las peticiones
al servidor.
Tabla 35: Tarjeta CRC de la clase “ConsumoEnergia”. Fuente: Elaboración propia.
Ambiente
• Representar los datos de los • Circuito

ambientes almacenados en la
• ConsumoEnergia
base de datos.

ambientes procedentes de las
peticiones al servidor.
Tabla 36: Tarjeta CRC de la clase “Ambiente”. Fuente: Elaboración propia.
ProduccionEnergia
• Representar los datos de las

producciones de energía
almacenadas en la base de
datos.

producciones de energía
al servidor.
Tabla 37: Tarjeta CRC de la clase “ProduccionEnergia”. Fuente: Elaboración propia.
FuenteEnergia
• Representar los datos de las • ProduccionEnergia

fuentes renovables
63
almacenados en la base de
datos.

fuentes renovables
al servidor.
Tabla 38: Tarjeta CRC de la clase “FuenteEnergia”. Fuente: Elaboración propia.
OrdenReparacion
• Representar los datos de las • Ambiente

órdenes de reparación
• PersonalMantenimiento
almacenadas en la base de
datos. De manera que también
• Circuito
represente los hechos.
• FuenteEnergia
órdenes de reparación • Usuario
al servidor.
Tabla 39: Tarjeta CRC de la clase “OrdenReparacion”. Fuente: Elaboración propia.
PersonalMantenimiento

personales de mantenimiento
en la base de datos.

personales de mantenimiento
al servidor.
Tabla 40: Tarjeta CRC de la clase “PersonalMantenimiento”. Fuente: Elaboración propia.
64
RolUsuario
• Permitir identificar el tipo de

usuario para la manipulación
de los recursos que les
corresponde.
Tabla 41: Tarjeta CRC de la clase “RolUsuario”. Fuente: Elaboración propia.
Usuario
• Representar los datos los • RolUsuario

usuarios en la base de datos.
• Permitir identificar al usuario

para la manipulación de los
recursos que les corresponde.
Tabla 42: Tarjeta CRC de la clase “Usuario”. Fuente: Elaboración propia.
SectorConsumo
• Representar los datos de los • Ambiente

sectores de consumo en la
base de datos.

sectores de consumo
al servidor.
Tabla 43; Tarjeta CRC de la clase “SectorConsumo”. Fuente: Elaboración propia.
SectorProduccion
• Representar los datos de los • FuenteEnergia

sectores de producción en la
base de datos.

sectores de producción
65
al servidor.
Tabla 44: Tarjeta CRC de la clase “SectorProduccion”. Fuente: Elaboración propia.
AmbienteController
• Obtener todos los ambientes. • AmbienteContext
• Obtener todos los ambientes • Ambiente

con sus circuitos respectivos.
• Circuito
• Obtener un ambiente a través
de su identificador.
Tabla 45: Tarjeta CRC de la clase “AmbienteController”. Fuente: Elaboración propia.
FuenteEnergiaController
• Obtener todas las fuentes • FuenteEnergiaContext

renovables a través del
• FuenteEnergia
identificador de su sector.
• Obtener una fuente a través de

su identificador.
Tabla 46: Tarjeta CRC de la clase “FuenteEnergiaController”. Fuente: Elaboración propia.
ConsumoEnergiaController
• Obtener los totales de • ConsumoEnergiaContext

consumos de energía de todos
• ConsumoEnergia
los ambientes a partir de un
periodo.
Tabla 47: Tarjeta CRC de la clase “ConsumoEnergiaController”. Fuente: Elaboración propia.
ProduccionEnergiaController
• Obtener los totales de • ProduccionEnergiaContext

producciones de energía de
66
todas las fuentes a partir de un • ProduccionEnergia
periodo.
Tabla 48: Tarjeta CRC de la clase “ProduccionEnergiaController”. Fuente: Elaboración propia.
OrdenReparacionController
• Obtener todas las órdenes de • OrdenReparacionContext

reparación pendientes.
• OrdenReparacion
• Obtener las órdenes de
reparación pendientes para los
ambientes.
• Obtener las órdenes de

reparación pendientes para las
fuentes.
• Obtener una orden de

reparación por su identificador.
• Crear una o varias órdenes de

reparación.
Tabla 49: Tarjeta CRC de la clase “OrdenReparacionController”. Fuente: Elaboración propia.
PersonalMantenimientoController
• Obtener los personales de • PersonalMantenimientoContext

mantenimiento disponibles, es
decir, que aún no estén en una
orden de reparación pendiente.
• Actualizar la condición de un
personal de mantenimiento.
Tabla 50: Tarjeta CRC de la clase “PersonalMantenimientoController”. Fuente: Elaboración propia.
67
SectorConsumoController
• Obtener los sectores de • SectorConsumoContext

consumos con sus ambientes
• SectorConsumo
respectivos.
• Ambiente
• Obtener los consumos de
energía de los sectores de
• ConsumoEnergia
consumos en un periodo.
Tabla 51: Tarjeta CRC de la clase “SectorConsumoController”. Fuente: Elaboración propia.
SectorProduccionController
• Obtener todos los sectores de • SectorProduccionContext

producción.
• Obtener los sectores de
• FuenteEnergia
producción con sus fuentes
respectivas.
• Obtener un sector de
producción con sus fuentes
respectivas a partir de su
identificador.
• Obtener las producciones de

energía de los sectores de
producción en un periodo.
Tabla 52: Tarjeta CRC de la clase “SectorProduccionController”. Fuente: Elaboración propia.
UsuarioController
• Autenticar al usuario a través • UsuarioContext

de su correo y contraseña.
• Usuario
• Brindar los datos del usuario
una vez autenticado
Tabla 53: Tarjeta CRC de la clase “UsuarioController”. Fuente: Elaboración propia.
68
BaseConnection
• Brindar la conexión con la base

de datos para la obtención o
manipulación de recursos.
Tabla 54: Tarjeta CRC de la clase “BaseConnection”. Fuente: Elaboración propia.
AmbienteContext
• Realizar las operaciones • BaseConnection

• Ambiente
al controlador del ambiente,
para realizar las operaciones
• Circuito
correspondientes en la base de
datos.
Tabla 55: Tarjeta CRC de la clase “AmbienteContext”. Fuente: Elaboración propia.
FuenteEnergiaContext

• FuenteEnergia
al controlador de la fuente de
energía, para realizar las
operaciones correspondientes
Tabla 56: Tarjeta CRC de la clase “FuenteEnergiaContext”. Fuente: Elaboración propia.
ConsumoEnergiaContext

• ConsumoEnergia
al controlador del consumo de
energía, para realizar las
Tabla 57: Tarjeta CRC de la clase “ConsumoEnergiaContext”. Fuente: Elaboración propia.
69
ProduccionEnergiaContext

al controlador de la producción
de energía, para realizar las
Tabla 58: Tarjeta CRC de la clase “ProduccionEnergiaContext”. Fuente: Elaboración propia.
OrdenReparacionContext

• OrdenReparacion
al controlador de la orden de
reparación, para realizar las
Tabla 59: Tarjeta CRC de la clase “OrdenReparacionContext”. Fuente: Elaboración propia.
PersonalMantenimientoContext

al controlador del personal de
mantenimiento, para realizar
las operaciones
correspondientes en la base de
datos.
Tabla 60: Tarjeta CRC de la clase “PersonalMantenimientoContext”. Fuente: Elaboración propia.
SectorConsumoContext

• SectorConsumo
al controlador del sector de
consumo, para realizar las
70
operaciones correspondientes • Ambiente
• ConsumoEnergia
Tabla 61: Tarjeta CRC de la clase “SectorConsumoContext”. Fuente: Elaboración propia.
SectorProduccionContext

al controlador del sector de
producción, para realizar las
• FuenteEnergia
en la base de datos. • ProduccionEnergia
Tabla 62: Tarjeta CRC de la clase “SectorProduccionContext”. Fuente: Elaboración propia.
71
Diagrama de Gantt (tiempos)
Figura 9: Diagrama de Gantt para el desarrollo del proyecto. Fuente: Elaboración propia.
72
Siendo más específico, dentro de cada fase del proyecto están presente una o varias
actividades, que se detallarán a continuación:

Nombre Estado Prioridad Inicio Fin
Definición de objetivos Listo Alta 2020-12-14 2020-12-20
Desarrollo de la encuesta para las
Listo Alta 2020-12-21 2020-12-24
pruebas
Identificación del problema Listo Alta 2020-12-28 2020-12-30
2020-12-14 2020-12-30
Encuesta pretest
Ejecución de la encuesta para la
Listo Alta 2021-01-04 2021-01-07
preprueba
Procesamiento de datos de la
Listo Alta 2021-01-08 2021-01-09
encuesta para la preprueba
2021-01-04 2021-01-09
Análisis y diseño
Análisis de requisitos Listo Alta 2021-01-11 2021-01-13
Diseño de mockups Listo Mediano 2021-01-14 2021-01-21
Diseño de la arquitectura del
Listo Alta 2021-01-18 2021-01-25
sistema
Diseño de la base de datos Listo Alta 2021-01-22 2021-01-29
Análisis y diseño del prototipo del
Listo Alta 2021-02-01 2021-02-17
circuito
2021-01-11 2021-02-17
Adquisición de equipos para el
prototipo
Identificación de los equipos de
cómputo y electrónicos para el Listo Alta 2021-02-18 2021-02-20
desarrollo
Adquisición del equipo de
Listo Mediano 2021-02-22 2021-02-24
cómputo para el desarrollo
Adquisición del controlador del
Listo Alta 2021-02-22 2021-02-26
prototipo del circuito
Adquisición del servidor para el
Listo Alta 2021-02-22 2021-02-26
broker MQTT
Adquisición de los componentes
Listo Mediano 2021-02-22 2021-02-26
del prototipo del circuito
2021-02-18 2021-02-26
73
Desarrollo de la aplicación web
y del prototipo del circuito
Desarrollo del front-end Listo Alta 2021-03-01 2021-03-28
Desarrollo del back-end Listo Alta 2021-03-15 2021-04-16
Ejecución de pruebas unitarias Listo Alta 2021-04-19 2021-05-07
Programación del controlador Listo Alta 2021-05-10 2021-05-14
2021-03-01 2021-05-14
Desarrollo e implementación
del prototipo del circuito
Armado del circuito Listo Alta 2021-05-17 2021-05-17
Fabricación del soportes para el
Listo Mediano 2021-05-18 2021-05-18
molino y el panel solar
Instalación y optimización del
Listo Alta 2021-05-19 2021-05-22
servidor IoT
Elaboración de reportes Listo Mediano 2021-05-24 2021-05-28
2021-05-17 2021-05-28
Encuesta posttest
Ejecución de la encuesta para la
Listo Alta 2021-05-31 2021-06-04
posprueba
Análisis de resultados de las
Listo Alta 2021-06-05 2021-06-07
encuestas
2021-05-31 2021-06-07
Aprobación del prototipo
Espera de respuesta de
En espera Alta 2021-06-14 2021-08-13
aprobación del prototipo
2021-06-14 2021-08-13
Configuración de servidores
IoT y web
Alquiler de servidores para IoT,
Planificado Alta 2021-08-16 2021-08-28
front-end y back-end
Instalación de herramientas Planificado Alta 2021-08-30 2021-09-10
2021-08-16 2021-09-10
Implementación del sistema
inmótico
74
Adquisición de equipos para el
sistema eléctrico
Instalación del sistema inmótico Planificado Alta 2021-10-11 2021-12-17
2021-09-13 2021-12-17
Pase a producción
Configuración de controladores Planificado Alta 2022-01-10 2022-01-21
2022-01-10 2022-01-21
Pruebas y validaciones con el
usuario
Ejecución de las pruebas
funcionales con el usuario
2022-01-24 2022-02-04
Marcha blanca
Ejecución de la marcha blanca Planificado Alta 2022-02-07 2022-04-01
2022-02-07 2022-04-01
Tabla 63: Cronograma de actividades de cada fase del proyecto. Fuente: Elaboración propia.
Estimación de costos
1. Costos del prototipo
Para analizar el costo de desarrollo del prototipo del sistema inmótico, primero se
determinó que consistirá en una aplicación web conectada al prototipo del circuito
del resort propiamente dicho hecho con un circuito de prueba.
Durante el desarrollo de la aplicación web no se requerirá de ninguna inversión en

herramientas tecnológicas, ya que estas herramientas no se obtienen
necesariamente por una licencia de pago. Mientras tanto el prototipo del circuito sí
se requerirá de una inversión en dispositivos como sensores y controladores. A
continuación, se detallarán los costos de adquisición de equipos para el prototipo:
ítem Costo unitario Unidades Costo subtotal
Laptop Lenovo S/. 3000 1 S/. 3000

z50 4GB RAM,
1 TB de disco
duro,
75
procesador
core i7
Raspberry Pi 4 S/. 256 1 S/. 256

8 GB RAM
ESP32 Devkit S/. 42 1 S/. 42

v1
Placas de S/. 8 2 S/. 16

pruebas
pequeña
Placa de S/. 14 1 S/. 14

pruebas
grande
Cables S/. 3 3 S/. 9

maleables
Motor DC 5 S/. 4 1 S/. 4

Volts
Regulador 3.3 S/. 5 1 S/. 5

Volts LM1117
Resistencias S/. 0.50 10 S/. 5

100 Ohms
Interruptores S/. 1 7 S/. 7
Panel solar S/. 8 1 S/. 8

pequeño 3.3
Volts
Total S/. 3366
Tabla 64: Estimación de costos específicos durante la fase “Adquisición de equipos para el prototipo”. Fuente:
Elaboración propia.
Esta etapa del desarrollo del prototipo comprende desde su fase de planificación
hasta su aprobación, el cual incluye algunas manos de obra relacionadas con el
circuito de pruebas. Mientras tanto, los costos de adquisición de equipos están
anotados en su fase correspondiente. Por otro lado, se toman en cuenta otros
gastos de servicios como luz eléctrica e Internet, cuyo promedio es de S/. 5.00 por
76
día. A continuación, se especificarán los costos aproximados de las actividades del
cronograma y del desarrollo del prototipo:

Nombre Costo
Definición de objetivos S/ 30.00
Desarrollo de la encuesta para las pruebas S/ 20.00
Identificación del problema S/ 15.00
S/ 65.00
Encuesta pretest
Nombre Costo
Ejecución de la encuesta para la preprueba S/ 20.00
Procesamiento de datos de la encuesta para la preprueba S/ 10.00
S/ 30.00
Análisis y diseño
Nombre Costo
Análisis de requisitos S/ 15.00
Diseño de mockups S/ 35.00
Diseño de la arquitectura del sistema S/ 35.00
Diseño de la base de datos S/ 35.00
Análisis y diseño del prototipo del circuito S/ 75.00
S/ 195.00
Adquisición de equipos para el prototipo
Nombre Costo
Identificación de los equipos de cómputo y electrónicos para el
S/ -
desarrollo
Adquisición del equipo de cómputo para el desarrollo S/ 3,000.00
Adquisición del controlador del prototipo del circuito S/ 42.00
Adquisición del servidor para el broker MQTT S/ 256.00
Adquisición de los componentes del prototipo del circuito S/ 68.00
S/ 3,366.00
Desarrollo de la aplicación web y del prototipo del circuito
Nombre Costo
Desarrollo del front-end S/ 120.00
Desarrollo del back-end S/ 145.00
77
Ejecución de pruebas unitarias S/ 85.00
Programación del controlador S/ 25.00
S/ 375.00
Desarrollo e implementación del prototipo del circuito
Nombre Costo
Armado del circuito S/ 35.00
Fabricación del soportes para el molino y el panel solar S/ 15.00
Instalación y optimización del servidor IoT S/ 20.00
Elaboración de reportes S/ 25.00
S/ 95.00
Encuesta posttest
Nombre Costo
Ejecución de la encuesta para la posprueba S/ 25.00
Análisis de resultados de las encuestas S/ 10.00
S/ 35.00
Aprobación del prototipo
Nombre Costo
Espera de respuesta de aprobación del prototipo
S/ -
Costo total de actividades S/ 4,161.00
Tabla 65: Estimación de costos de actividades para el desarrollo del prototipo. Fuente: Elaboración propia.
2. Costos del proyecto
Costo en recursos humanos y sueldos
Fase del Rol Días Personas Costo Subtotal

proyecto laborados por (S/.)
día
Planificación Consultor de 13 1 300 3900
del proyecto proyectos
Encuesta
pretest
Análisis y Analista 28 1 150 4200
diseño programador
Arquitecto 28 1 210 5880
de software
Ingeniero 13 1 275 3575
electrónico
Consultor de 28 1 300 8400
proyectos
78
Adquisición de Técnico en 5 1 135 675
equipos para el sistemas
prototipo Técnico IoT 5 1 175 875
proyectos
Desarrollo de la Analista 55 1 150 8250
aplicación web programador
y del prototipo Técnico IoT 55 1 175 9625
del circuito
proyectos
Desarrollo e Técnico IoT 4 1 175 700
implementación
del prototipo Analista 5 1 150 750
del circuito programador
proyectos
Encuesta
posttest
Aprobación del
prototipo
Configuración Técnico en 10 2 135 2700
de servidores sistemas
IoT y web Consultor de 10 1 300 3000
proyectos
Implementación Técnico IoT 50 5 175 43750
del sistema
inmótico Ingeniero 70 1 275 19250
electrónico
Pase a Técnico IoT 10 2 175 3500
producción
Ingeniero 10 1 275 2750
electrónico
Pruebas y Tester 10 3 160 4800
validaciones
con el usuario
Marcha blanca
Total de RR.HH 146680
Tabla 66: Costo total de sueldos. Fuente: Elaboración propia.
Costos de infraestructura tecnológica
Equipo Cantidad Costo Costo total (S/.)

unitario (S/.)
Programador Lógico 1 7427.89 7427.89

Controlable (PLC)
Sensores de corriente 16 117 1872

alterna para las
79
cuchillas de los
ambientes
Sensores de corriente 10 117 1170

alterna para las
fuentes
Total 10469.89
Tabla 67: Costo total de infraestructura tecnológica. Fuente: Elaboración propia.
Gastos de servicios de computación en la nube
Recurso Gasto mensual (S/.)
Amazon Relational Database 2868.20

Service: Instancia estándar
db.r5.xlarge
AWS Elastic Computer Cloud: 2 558.91

instancias estándar c6g.xlarge
Amazon S3: 16 GB 5.06
Total 3432.17
Tabla 68: Costo de infraestructura tecnológica. Fuente: Elaboración propia.
3. Costo total de ejecución del proyecto
En resumen, los costos de ejecución comprenden los costos de actividades, en

recursos humanos y sueldos, y de la infraestructura tecnológica:
Tipo Costo (S/.)
Recursos humanos y sueldos S/. 130955.00
Infraestructura tecnológica S/. 10469.89
Costo total de ejecución del S/. 145665.89

proyecto
Tabla 69: Costo total de ejecución del proyecto. Fuente: Elaboración propia.
Estimación de flujo de caja, VAN y TIR
Para la estimación, se consideraron como beneficios al monto de ahorro de energía.

Mientras que los gastos equivalen a los gastos por los servicios de computación en la nube
e infraestructura.
80
Sin embargo, el ahorro de energía depende de qué tan activo está el resort durante el año,
para ello el resort tiene estimado de cuánto se gastó en energía eléctrica antes de
implementar las fuentes renovables.
Otros aspectos a considerar fueron la tasa de descuento anual y mensual, la reserva de

contingencia y el tiempo de recuperación de la inversión.
A continuación, se detallará la inversión y su recuperación:
81
Tabla 70: Detalles de la recuperación de inversión del proyecto. Fuente: Elaboración propia.
82
Desarrollo del proyecto
Herramientas de edición y gestión de cambios del código
1. Visual Studio Code
Es un software editor de código ligero desarrollado por Microsoft, pero muy potente
y multiplataforma. Permite desarrollar en una variedad de lenguajes, como
JavaScript, Phyton, PHP, Go, C#, Java, etc. Una de sus ventajas es que brinda un
soporte muy grande de librerías para trabajar con Node.js y las tecnologías de .NET.
Debido a que es multiplataforma, se empleará tanto para el desarrollo de la interfaz

de usuario, los servicios web y la programación de la tarjeta controladora de
pruebas ESP32 gracias a que también existen extensiones para trabajar con
Arduino.
Figura 10: Interfaz de Visual Studio Code. Fuente: recopilación propia.
2. Git y Github
Git es un sistema de control de versiones que permite a los desarrolladores de una

aplicación a gestionar los cambios sin afectar el proyecto entre ellos de manera
desordenada. Cabe mencionar que Git realiza el seguimiento del proyecto a través
de un repositorio y cada desarrollador tiene una copia del repositorio en su
computadora para comenzar a trabajar y realizar sus cambios para después
fusionar su código con los avances de otros desarrolladores.
Como se mencionó, controla versiones de la aplicación, donde se dispone de un

historial de cambios y lo que permite retroceder a una versión anterior del código
83
en caso que un desarrollador quiera hacerlo, facilitando la corrección de errores, el
mantenimiento de la aplicación, entre otras cosas.
Git emplea una serie de comandos para realizar las acciones en el repositorio. Sin
embargo, su integración en Visual Studio Code permite a los desarrolladores
trabajar de forma más amigable, así como facilitarles en el control de cambios
durante la codificación.
Por otro lado, Github es una plataforma de colaboración y gestión de proyectos de

software con Git, donde los desarrolladores suben el código. Además, los
desarrolladores pueden descargar distintas versiones del código o colaborar con
proyectos de otros desarrolladores. Sin embargo, también se puede alojar
proyectos privados, pero con una versión de pago.
3. Node.js y NPM (Node Package Manager)
Node.js es un entorno de ejecución de Javascript multiplataforma para el lado del

servidor y admite una variedad de herramientas para el desarrollo de aplicaciones
de escritorio, web y móviles con Javascript. En ese punto de la obtención de esas
herramientas es donde entra NPM, que es el gestor de paquetes que usa Node.js
para instalarlas y actualizarlas.
Herramientas de desarrollo front-end
El desarrollo front-end es aquel desarrollo por el lado del cliente, que contempla la interfaz
visual de la aplicación web, que es accesible a través del navegador web. Para que la
aplicación sea multiplataforma, es decir, sea accesible desde cualquier dispositivo, se han
tenido que emplear herramientas de diseño y maquetación web.
A continuación, se detallarán las herramientas y tecnologías para el diseño y desarrollo de

la interfaz web:
1. Figma
Es una aplicación que se ejecuta en el navegador para diseñar interfaces de

usuario, ya sean de aplicaciones web o móviles, de manera interactiva y permite la
colaboración en tiempo real. Además, posee un repositorio de plantillas creadas por
diseñadores para aplicarlos al proyecto personal. De esa manera, los diseñadores
pueden trabajar y realizar pruebas de interacción entre interfaces desde cualquier
computadora conectada.
84
Figura 11: Vista general de los diseños de las interfaces en Figma. Fuente: Recopilación propia.
2. Bootstrap
Es un framework de CSS para el desarrollo front-end de aplicaciones web y sitios

mobile first, que comprende las técnicas de “responsive design”, es decir, diseño
adaptado a cualquier tamaño de pantalla del dispositivo del usuario final. Con eso
quiere decir que el equipo de desarrollo front-end podrá crear las páginas que
componen la interfaz de usuario para que sean accesible desde una computadora,
una tableta o un móvil.
3. Angular
Es un framework de Javascript creado por Google para el desarrollo lado del cliente
o front-end y crear aplicaciones de una página (SPA en sus siglas en inglés) de tal
manera que sean eficientes y sofisticadas.
Cuenta con muchos módulos que se instalan a través de NPM, permitiendo añadir
otras funcionalidades, entre ellas la comunicación con dispositivos IoT por MQTT.
4. TypeScript
Es un lenguaje de programación de código abierto desarrollado por Microsoft, que

se trata de un lenguaje sobre otro lenguaje, que en este caso es Javascript,
brindándole características tales como el tipado fuerte y herramientas de
programación orientado a objetos. Cabe resaltar que Angular brinda la posibilidad
de trabajar con TypeScript para aprovecharlo mejor como lenguaje (Caceres, 2016).
Herramientas de desarrollo back-end
Por otro lado, el desarrollo back-end es el desarrollo por el lado del servidor, que
comprende a la lógica del negocio, la interacción con la base de datos, el acceso y la
85
seguridad de estos. De esa manera el front-end accederá a los datos a través de un API,
por medio del protocolo HTTP.
1. .NET Core
Es un framework de desarrollo web de código abierto creado por Microsoft que

incluye las herramientas para crear y ejecutar aplicaciones en lenguajes como C#
o Visual Basic. A diferencia de .NET Framework, la característica más resaltante de
.NET Core es que es multiplataforma, de esta manera las operaciones se pueden
realizar desde la línea de comandos, brindando la ventaja de trabajar con editores
de código más livianos. Este framework será utilizado para desarrollar el back-end,
que interactúa con la base de datos.
2. WAMP server
Son las siglas de Windows, Apache, MySQL y PHP. Como su nombre lo dice,
contiene el motor de base de datos MySQL, el cual se administra con una interfaz
de usuario llamado phpMyAdmin.
Figura 12: Interfaz phpMyAdmin, para la administración de la base de datos MySQL. Fuente: recopilación propia.
3. Postman
Es un programa con varias herramientas que permiten realizar tareas en las API
REST, de tal manera que se pueda hacer test sin necesidad de crear un cliente,
permitiendo al desarrollador back-end probar las APIs desarrolladas.
Dispositivos y herramientas IoT
1. ESP32
Es una placa de desarrollo de código abierto que se programa con el mismo

lenguaje de programación usado para las tarjetas de Arduino. La característica más
principal de esta placa es que permite conectarse por Wifi y ser utilizado como un
86
pequeño servidor web o como un cliente, tal como lo sería otro dispositivo
conectado a la red. La diferencia radica en que es también un controlador al que se
le conectan sensores y actuadores, tal como lo haríamos con una placa de Arduino,
solo que podríamos obtener datos del circuito o enviar comandos para que el
circuito haga algunas cosas desde la red, pero para ello se requiere de un
intermediario para interactuar con la aplicación web.
Debido a que el circuito eléctrico es un prototipo que simula una parte del entorno
real y es solo para pruebas, no puede ser empleado para trabajar con la red del
resort. Para ello será necesario trabajar con dispositivos de automatización
industrial, tales como los PLCs (Controlador Lógico Programable).
Figura 13: Distribución de los pines analógicos y digitales del módulo ESP32 devkit v1. Fuente:
https://github.com/playelek/pinout-doit-32devkitv1
2. PlatformIO
Es un entorno de desarrollo de programas para controladores como Arduino y sus

versiones y otros como el ESP32. Este entorno se caracteriza por ser una extensión
que se instala en editores de código tales como Visual Studio Code, brindándole la
posibilidad de escribir código y compilarlo en ahí mismo.
Está claro que para programar controladores como Arduino y ESP32 ya existe el
IDE (Entorno de Desarrollo Integrado) de Arduino, pero PlatformIO está más
enfocado en el mundo del desarrollo IoT. Además, trabajar en el editor ayudará al
equipo a gestionar los cambios en el código del controlador en Github de forma más
rápida y directa.
87
Figura 14: Pantalla de inicio de PlatformIO en Visual Studio Code. Fuente: Recopilación propia.
3. Raspberry Pi 4
Es una computadora de tamaño de una tarjeta de crédito, donde están integrados

varios periféricos como controladores de audio, gráfico, conectores USB, entrada
ethernet, memorias, etc. Prácticamente se puede usar como una computadora de
escritorio o como un servidor, por lo que se instala un sistema operativo.
Existen varios modelos, los cuales dependen sus capacidades, pero las tarjetas
permiten conectarse con otras, de esa es que se pueden utilizar varias tarjetas para
armar un clúster y sumar las capacidades para tener una computadora muy potente.
Uno de sus mayores usos es como servidor IoT, que permite controlar y distribuir
los datos que viajan en la red entre los dispositivos o aplicaciones conectadas.
Al igual que la tarjeta Arduino y el ESP32, posee pines de conexión para trabajar
con circuitos electrónicos y programar la tarjeta con el lenguaje de programación
Python. De la misma manera con el ESP32, se puede enviar o recibir datos por
Internet.
Sin embargo, para este proyecto, la tarjeta estará destinada a ser utilizada como
servidor IoT, puesto que el ESP32 ya tiene el rol de ser el controlador del circuito
eléctrico.
88
Figura 15: Raspberry Pi 4 Modelo B. Fuente: https://www.raspberrypi.org/products/raspberry-pi-4-model-b/
4. Raspbian
Es un sistema operativo desarrollado basado en una distribución Debian de Linux,

solo que fue creado especialmente para el hardware del Raspberry Pi. Contiene la
posibilidad de ser instalada con interfaz gráfica o sin ella. Mientras tanto, la gestión
de paquetes se realiza a través de APT (Herramienta Avanzada de Empaquetado)
como ocurre con otro sistema operativo basado en Debian, como Ubuntu.
5. Eclipse Mosquitto
Es un broker open source que trabaja con el protocolo MQTT. El broker puede ser
instalado y configurado en varios sistemas operativos. De esa manera se dispondrá
de un servidor para IoT para gestionar la comunicación entre el dispositivo
controlador y la aplicación web.
Interfaces de usuario
A través de la plataforma Figma, se elaboraron los diseños de interfaces de usuario y la

interacción entre ellas:
89
Figura 16: Acceso al sistema. Fuente: Elaboración propia.
Para el usuario cuyo rol sea el de supervisión, se diseñaron estas interfaces para el
monitoreo y distribución de energía renovable en el resort:
Figura 17: Mapa visualizador de los estados de los ambientes del resort. Fuente: Elaboración propia.
90
Figura 18: Mapa visualizador de los estados de los ambientes del resort indicando un error en algunos de sus circuitos de
un ambiente específico. Fuente: Elaboración propia.
Figura 19: Listado de operarios disponibles para la emisión de la orden de reparación. Fuente: Elaboración propia.
91
Figura 20: Mapa visualizador con los ambientes del resort indicando el que tiene una orden de reparación emitida
pendiente. Fuente: Elaboración propia.
Figura 21: Mapa visualizador de los estados de las fuentes de energía renovable del resort. Fuente: Elaboración propia.
92
Figura 22: Mapa visualizador de los estados de las fuentes de energía renovable del resort indicando un error en una de
ellas específicamente. Fuente: Elaboración propia.
Figura 23: Mapa visualizador con las fuentes de energía renovable del resort indicando el que tiene una orden de
reparación emitida pendiente. Fuente: Elaboración propia.
93
Figura 24: Relación de todos los ambientes del resort, donde se puede ver el flujo de consumo por ambiente en tiempo
real. Fuente: Elaboración propia.
Figura 25: Gráfico consumo – tiempo, ayuda a visualizar el flujo del consumo de energía de un ambiente particular del
resort, cuenta con una lectura que suma el consumo total del día, para la medición más baja y la más alta registradas.
Fuente: Elaboración propia
94
Figura 26: Relación de todos los sectores de producción del resort. Cada uno de ellos contiene sus fuentes productoras de
energía. Fuente: Elaboración propia.
Figura 27: Relación de todas las fuentes de producción de energía de un sector particular del resort, donde se puede ver el
flujo de producción por fuente en tiempo real. Fuente: Elaboración propia.
95
Figura 28: Gráfico producción – tiempo, ayuda a visualizar el flujo de producción de energía de una fuente particular del
resort, cuenta con una lectura que suma la producción total del día, para la medición más baja y para la más alta
registradas. Fuente: Elaboración propia.
Respecto al rol de usuario gerente, requiere de módulos para visualizar reportes de

consumo y producción de energía. Para ello, se diseñaron las siguientes interfaces:
Figura 29: Reporte de consumo de energía mediante búsqueda por periodo. Fuente: Elaboración propia.
96
Figura 30: Reporte de historial de consumo de energía de un ambiente particular del resort, mediante búsqueda por
periodo. Fuente: Elaboración propia.
Figura 31: Reporte de producción de energía mediante búsqueda por periodo. Fuente: Elaboración propia.
97
Figura 32: Reporte de historial de producción de energía de una fuente de energía en particular, una vez realizada la
búsqueda por periodo. Fuente: Elaboración propia.
Figura 33: Gráfico de análisis de consumo y producción por periodo para la contrastación entre ambos. Fuente: Elaboración
propia.
Base de datos
La base de datos es de tipo relacional, creada en MySQL, codificada en phpMyAdmin. La

base de datos contiene una tabla de hechos, que vienen a ser las órdenes de reparación;
cuyas dimensiones son: ambiente, fuente de energía, personal de mantenimiento, circuito
98
y usuario. Mientras tanto, también guardan datos como el consumo de energía y la
producción de energía.
A continuación, se muestran las entidades y las relaciones en la base de datos.
Figura 34: Diseño de la base de datos. Fuente: Elaboración propia.
Creación de los servicios web
Con el programa Postman se diseñaron las peticiones HTTP al back-end con sus
respectivos métodos. Al ser una API REST, los datos se procesan en formato JSON. Una
vez diseñadas las peticiones HTTP, se indica al equipo de front-end para programarlas en
el framework Angular.
Figura 35: Listado de las peticiones HTTP en Postman. Fuente: Recopilación propia.
99
Desarrollo del sistema inmótico
El sistema inmótico maneja otro tipo de comunicación con el front-end, puesto que requiere
que los datos sean transmitidos en tiempo real. Para ello se emplearon el protocolo MQTT
y los websockets. Sin embargo, también puede conectarse con el back-end a través del
protocolo HTTP como lo hace el front-end, ya que esto involucra el guardado de datos de
consumo de consumo y producción de energía diarios para los reportes, pero las peticiones
deben ser programadas en un tiempo específico.
Protocolos de seguridad
Se implementarán las medidas de seguridad asesoradas por OWASP para buenas

prácticas de codificación durante el desarrollo. En el paso a producción (PaP), se
considerarán las medidas para la administración de servidores, gestión de archivos,
mantenimiento, etc.
A continuación, se detallarán las medidas de seguridad aplicadas en el desarrollo de la

aplicación web:
• La base de datos guardará la contraseña del usuario registrado encriptada, para

ello se emplearán la función de encriptación de MySQL.
• Las operaciones con datos sensibles siempre se deberán hacer desde el lado del
back-end o desde la base de datos. Esto es debido a que el front-end es abierto y
el código fuente puede ser visto. Así es que el front-end deberá enviar los datos
necesarios y esperar la respuesta con su código HTTP y/o con los datos
procesados.
• Los usuarios deberán autenticarse para acceder a los recursos del servidor, pero
únicamente a los que les corresponde según su rol. Es ahí donde entra JWT para
brindarle un token que contiene información del rol.
• El token de usuario tendrá un tiempo límite de vencimiento, evitando todo intento

de robo de identidad o pérdida de autenticación.
• El back-end deberá manejar las peticiones a la base de datos mediante el uso de

declaraciones preparadas (prepared statement) para evitar vulnerabilidades de
inyección SQL.
• Se instalarán los certificados de seguridad en el back-end para el uso de HTTPS.
• El back-end empleará CORS (intercambio de recursos de origen cruzado) con los

dominios del front-end y del controlador del circuito para evitar que clientes
desconocidos accedan a los recursos.
100
Respecto al protocolo MQTT para la comunicación entre el controlador y la aplicación web,
se deberá de asegurar que se hayan aplicado los certificados de seguridad en la capa de
sockets y de transporte (SSL/TSL). Luego se procederá a asegurar que el cliente se
autentique al bróker con el protocolo SSL y viceversa. No se permitirán clientes anónimos,
donde solo la autenticación se da por parte del cliente y no del bróker (IBM, s.f.).
Arquitectura del proyecto
El proyecto cuenta con un servidor web, donde se aloja el front-end de la aplicación web
que serán accedidos por los usuarios. Respecto a los servicios que consume el front-end
para realizar las operaciones en la base de datos, se encuentran alojados en el servidor
back-end, donde además estarán configurados los permisos hacia los recursos y la
seguridad de éstos según las medidas asesoradas por OWASP. Para la comunicación
entre el circuito controlador y la aplicación web, entra en juego el broker MQTT. El circuito
controlador, al tener el poder de conexión a Internet como el cliente, puede realizar
peticiones de recursos al back-end por medio del protocolo HTTP, pero deben ser
controladas mediante su programación. En el caso del ESP32, con el código de Arduino, y
en el caso de un PLC cuando se lleve a producción, con su software controlador.
Figura 36: Diagrama de la arquitectura de la aplicación web y su integración con el sistema inmótico. Fuente: elaboración
propia.
Requerimientos y especificaciones de la conexión
El proyecto, al consistir en un prototipo, funcionará con normalidad dentro de una red de

área local inalábrica (WLAN) de 2.4GHz. Los detalles de la conexión son los siguientes:
101
Conexión Protocolo Velocidad de Velocidad de
carga descarga
Cliente – Servidor web HTTPS 5.29 Mbps 10.88 Mbps
Servidor web – HTTPS 5.29 Mbps 10.88 Mbps

Servidor back-end
Servidor web – MQTT canalizado a 5.29 Mbps 10.88 Mbps

Servidor IoT través de SSL/TLS
Circuito controlador – MQTT canalizado a 5.29 Mbps 10.88 Mbps

Servidor IoT través de SSL/TLS
Circuito controlador – HTTPS 5.29 Mbps 10.88 Mbps

Servidor back-end
Servidor back-end – ODBC (Conectividad 5.29 Mbps 10.88 Mbps

Servidor de base de de base de datos
datos abierta) canalizado a
través de SSL/TLS
Tabla 71: Requerimientos y especificaciones de las conexiones. Fuente: Elaboración propia.
Esquematización del circuito de pruebas
El circuito de pruebas consistirá en la conexión de componentes en el ESP32, que simulará

la conexión de dos ambientes y de dos fuentes de energía. Los ambientes simulados son
el lobby y el restaurante, mientras que las fuentes simuladas serán la turbina 1, ubicado en
el parque eólico 1 y el panel 1, ubicado en el parque solar 1. Los componentes electrónicos
para la simulación del resort son los siguientes:
• 1 motor de corriente continua de 5 Volts para simular la turbina eólica.
• 1 panel solar de 3.3 Volts.
• Reguladores de voltaje de 3.3 Volts para proteger los pines de entrada del ESP32
de las señales del motor y de las fuentes de energía o baterías. Esto se debe que
el motor puede emitir señales de 5 Volts o mayores, dependiendo de la velocidad
de giro, y ocasionarían daños en el pin de entrada si no se regula el voltaje. El
mismo caso también aplica a las baterías o fuentes, ya que manejan un voltaje
mayor para alimentar un circuito extra, pero la parte que está conectada al pin de
entrada debe ser regulada.
• Resistencias para limitar la corriente en los pines de entrada del ESP32, ya que la
corriente máxima de entrada es de 40 mA. Por lo tanto, se deben emplear
102
resistencias de 82.5 Ω (Ohms) como mínimo. Por temas prácticos, se utilizarán
resistencias de 1 kΩ (1000 Ohms).
• 2 placas de pruebas o protoboards para organizar la configuración eléctrica de

prueba por cada ambiente.
• 2 fuentes de alimentación por cada ambiente, también pueden ser baterías.
• 2 conjuntos de interruptores deslizables que simularán las cuchillas eléctricas de

cada ambiente (4 cuchillas para el lobby y 3 para el restaurante).
Figura 37: Esquema del circuito de pruebas. Fuente: Elaboración propia.
Puesta a producción
Una vez que el proyecto cumpla con los requisitos de pruebas, rendimiento y que responde
a la problemática del cliente; estará listo para su despliegue, es decir, ponerlo a producción,
el equipo tratará de aprender y adaptarse a las herramientas, ya que también serán
necesarias durante el periodo de mantenimiento.
Herramientas para el despliegue de la aplicación
1. Docker
Es una herramienta que permite ejecutar procesos aislada de los demás procesos
de la computadora, sin importar las características que la máquina tiene por debajo
como el sistema operativo y demás características que complican la ejecución de
esos procesos, que están muy por fuera del alcance del desarrollo de aplicaciones.
103
En síntesis, se puede decir que Docker elimina la incompatibilidad de los entornos
de ejecución.
Con esta herramienta se permitirá automatizar el entorno del despliegue de la

aplicación .NET Core una vez implementados los servidores.
2. Amazon Web Services (AWS)
AWS es una plataforma de múltiples servicios y herramientas para la creación de

entornos de computación en la nube (cloud computing). Estos servicios proveen
soluciones a varios indicadores de la infraestructura de TI del proyecto.
Los servicios de AWS a utilizar para el proyecto son:
• Amazon Relational Database Service: Servicio de tipo PaaS (Plataforma

como servicio) de gestión de base de datos. Para el despliegue de la base
de datos MySQL.
• AWS EC2 (Elastic Computer Cloud): Servicio de tipo IaaS (Infraestructura

como servicio) que permite alquilar máquinas virtuales para la ejecución de
aplicaciones y de tamaño modificable, de manera que el consumo de
recursos se adapta al uso. Se empleará para la creación del servidor IoT, al
cual se le instalará el bróker Mosquitto, tal como se configuró en la
Raspberry Pi.
• Amazon ECS (Elastic Container Service): Servicio de tipo IaaS de

administración de contenedores escalable para la manipulación,
administración y protección de aplicaciones de contenedores de Docker en
un clúster. Será necesario para el despliegue de la APIs creadas en .NET
Core.
• Amazon S3 (Simple Storage Service): Servicio de tipo IaaS que cuenta

con recursos de computación escalables basado en web. Se utilizará para
desplegar la aplicación Angular.
Herramientas para el sistema eléctrico
Para complementar la aplicación web desplegada con el sistema inmótico en producción,

será necesario contar con equipos especiales para procesos industriales, ya que el
controlador ESP32 en producción llegaría a funcionar máximo para un sistema domótico.
1. PLC (Controlador Lógico Programable)
Un controlador lógico programable es una computadora especial para la

automatización de procesos industriales, según Álvarez y Mejía, donde equipos y
104
máquinas se activan a partir de una serie de órdenes o condiciones durante el
proceso. El PLC tiene entradas y salidas digitales integrados. Las entradas que se
conectan pueden ser pulsadores, interruptores, sensores de cualquier índole, entre
otros; mientras que en las salidas digitales se conectan actuadores digitales como
controladores de potencia, válvulas, lámparas y resistencias eléctricas, que solo
pueden tomar dos estados: todo o nada. La activación de entradas y salidas
requieren de un control lógico, donde las salidas dependen de las entradas en un
cierto momento, pero el control lógico depende de los estados de las entradas y las
salidas como de los tiempos de ejecución o de la cantidad de veces que se ejecutó
un evento (2017, p. 11).
El PLC, por supuesto, maneja altos valores de corriente y voltaje, que son los que
utilizan los equipos industriales para funcionar, como los sensores y los dispositivos
de salida. El caso aplica también para las fuentes de energía renovable, que son
equipos que emiten altos valores de corriente y voltaje, por lo cual deben ser
controlados.
Respecto a la interacción con la aplicación web, el PLC contará con dos

funcionalidades extra: cliente MQTT y cliente HTTP. La funcionalidad de cliente
MQTT es el que le admitirá publicar los estados de los ambientes y fuentes de
energía en la red eléctrica y enviar los datos de consumo y de producción de
energía. Con respecto a la funcionalidad de cliente HTTP, será necesario para
guardar los datos de producción y consumo de energía diarios en la base de datos
a través de la API mediante la petición al back-end, por lo que también requiere que
envíe datos en formato JSON.
2. Sensores y equipos de entrada
La implementación incluirá también los dispositivos de entrada que irán conectados

al PLC para tomar sus datos y enviarlas a la aplicación web, tales como los
sensores de corriente, cuchillas o llaves eléctricas y medidores de potencia.
Evaluación de la propuesta del sistema inmótico
La evaluación consistió de una encuesta realizada a 26 trabajadores del área de control y

mantenimiento de la red eléctrica del resort, entre personales de mantenimiento,
supervisores y gerentes; quienes serán los usuarios finales una vez que el sistema esté
puesto a producción. En la siguiente tabla se muestran las preguntas elaboradas para la
encuesta.
Pre-test
105
Indicador Pregunta Opciones
Gestión de órdenes de ¿Qué tan eficiente a) Muy poco eficiente

reparación sin el sistema considera al control de las b) Poco eficiente
órdenes de reparación?
c) Regularmente
eficiente
d) Eficiente
e) Muy eficiente
Detalle de los datos de ¿Qué tan preciso considera a) Muy poco preciso
consumo de energía sin el que son los datos de b) Poco preciso
sistema consumo de energía a partir
c) Regularmente
de los medidores?
preciso
d) Preciso
e) Muy preciso
Utilidad de los datos de ¿Qué tan útil considera que a) Muy poco útil
consumo de energía sin el son los datos de consumo b) Poco útil
sistema de energía a partir de los
c) Regularmente útil
medidores?
d) Útil
e) Muy útil
producción de energía sin el que son los datos de b) Poco preciso
sistema producción de energía a
c) Regularmente
partir de los medidores?
preciso
d) Preciso
e) Muy preciso
producción de energía sin son los datos de b) Poco útil
el sistema producción de energía a
partir de los medidores?
d) Útil
e) Muy útil
Tabla 72: Encuesta de evaluación en el preprueba. Fuente: Elaboración propia.
106
Post-test
Indicador Pregunta Opciones
Gestión de órdenes de ¿Qué tan eficiente a) Muy poco eficiente

reparación considera al control de las b) Poco eficiente
órdenes de reparación por
c) Regularmente
el sistema?
eficiente
d) Eficiente
e) Muy eficiente
consumo de energía que son los datos de b) Poco preciso
consumo de energía
c) Regularmente
generados por el sistema?
preciso
d) Preciso
e) Muy preciso
consumo de energía con el son los datos de consumo b) Poco útil
sistema de energía generados por
el sistema?
d) Útil
e) Muy útil
producción de energía que son los datos de b) Poco preciso
producción de energía
c) Regularmente
preciso
d) Preciso
e) Muy preciso
producción de energía con son los datos de b) Poco útil
el sistema producción de energía
d) Útil
e) Muy útil
107
Generación de reportes ¿Qué calidad considera a) Muy baja calidad
que tienen los reportes b) Baja calidad
generales de consumo y
c) Calidad normal
producción de energía?
d) Buena calidad
e) Muy buena calidad
Visualización del flujo de ¿Qué tan interactiva cree a) Muy poco

energía que es la vista del flujo de interactivo
energía en tiempo real? b) Poco interactivo
c) Regularmente
interactivo
d) Interactivo
e) Muy interactivo
Tabla 73: Encuesta de evaluación en el posprueba. Fuente: Elaboración propia.
Método de análisis
Para realizar las encuestas, se utilizó la plataforma Google Forms. De esta forma se pudo
dirigirse al personal y poder recopilar los datos de forma rápida para su posterior análisis.
Figura 38: Encuesta del pre-test en Google Forms. Fuente: Elaboración propia.
108
Figura 39: Encuesta del post-test en Google Forms. Fuente: Elaboración propia.
Para el análisis, se utilizó el programa IBM SPSS, que permitirá interpretar los datos para
traer los resultados de la encuesta.
Figura 40: Recopilación de datos de las encuestas en el software SPSS. Fuente: Elaboración propia.
Sin embargo, se requirió estimar la confiabilidad de los instrumentos de ambas encuestas.

Por lo tanto, se realizó el análisis de fiabilidad a través del cálculo del alfa de Cronbach
tanto de la encuesta de la preprueba como del posprueba.
Como se puede observar en las figuras, ambas encuestas obtuvieron un alfa de Cronbach
iguales a 0.874 y 0.867, lo que significa que los dos instrumentos son muy fiables e indican
una buena consistencia interna (Publicando, 2015, p.62).
109
Figura 41: Medición de fiabilidad del pre-test.
Figura 42: Medición de fiabilidad del post-test.
Cabe resaltar que los indicadores, al ser medidas a través de una escala Likert, son de
puntaje máximo de 5. Puesto que a que un indicador pertenece a una prueba, se utilizará
para compararla con el indicador equivalente en la otra prueba.
En el programa SPSS se nombraron las variables correspondientes a los indicadores de la

siguiente manera:
110
Indicador Nombre de la variable en SPSS
Gestión de órdenes de reparación sin el control_orden_reparacion

sistema
Detalle de los datos de consumo de nivel_detalle_consumo_energia

Utilidad de los datos de consumo de nivel_utilidad_consumo_energia

Detalle de los datos de producción de nivel_detalle_produccion_energia

Utilidad de los datos de producción de nivel_utilidad_produccion_energia

Gestión de órdenes de reparación control_orden_reparacion_sist
Detalle de los datos de consumo de nivel_detalle_consumo_energia_sist

energía
Utilidad de los datos de consumo de nivel_utilidad_consumo_energia_sist

energía con el sistema
Detalle de los datos de producción de nivel_detalle_produccion_energia_sist

energía
Utilidad de los datos de producción de nivel_utilidad_produccion_energia_sist

energía con el sistema
Generación de reportes nivel_calidad_reportes
Visualización del flujo de energía nivel_interaccion_flujo_energia

Tabla 74: Nombre de variables en SPSS. Fuente: Elaboración propia.
111
RESULTADOS
A continuación, se detallan las frecuencias por cada indicador del monitoreo de energía
renovable, antes y después de la propuesta del sistema.
Pre-test
Gestión de órdenes de reparación sin el sistema
Estadísticos
¿Qué tan eficiente considera al control
de las órdenes de reparación?
N Válido 26
Perdidos 0
Media 1,73
Mediana 2,00
Moda 2
Desviación estándar ,667
Varianza ,445
Rango 2
Tabla 75: Estadísticos de la variable control_orden_reparacion.
¿Qué tan eficiente considera al control de las órdenes de reparación?
Porcentaje Porcentaje
Frecuencia Porcentaje válido acumulado
Válido Muy poco eficiente 10 38,5 38,5 38,5
Poco eficiente 13 50,0 50,0 88,5
Regularmente eficiente 3 11,5 11,5 100,0
Total 26 100,0 100,0

Tabla 76: Frecuencia de la variable control_orden_reparacion.
112
Figura 43: Frecuencia de la variable control_orden_reparacion.
Detalle de los datos de consumo de energía sin el sistema
Estadísticos
¿Qué tan preciso considera que son los
datos de consumo de energía a partir
de los medidores?
N Válido 26
Perdidos 0
Media 1,88
Mediana 2,00
Moda 2
Varianza ,266
Rango 2
Tabla 77: Estadísticos de la variable nivel_detalle_consumo_energia.
¿Qué tan preciso considera que son los datos de consumo de energía a partir de los
medidores?
Válido Muy poco preciso 5 19,2 19,2 19,2
Poco preciso 19 73,1 73,1 92,3
Regularmente preciso 2 7,7 7,7 100,0
Total 26 100,0 100,0

Tabla 78: Frecuencia de la variable nivel_detalle_consumo_energia.
113
Figura 44: Frecuencia de la variable nivel_detalle_consumo_energia.
Utilidad de los datos de consumo de energía sin el sistema
Estadísticos
¿Qué tan útil considera que son los
datos de consumo de energía a partir
de los medidores?
N Válido 26
Perdidos 0
Media 1,96
Mediana 2,00
Moda 2
Varianza ,518
Rango 3
Tabla 79: Estadísticos de la variable nivel_utilidad_consumo_energia.
¿Qué tan útil considera que son los datos de consumo de energía a partir de los
medidores?
Válido Muy poco útil 6 23,1 23,1 23,1
Poco útil 16 61,5 61,5 84,6
Regularmente útil 3 11,5 11,5 96,2
Útil 1 3,8 3,8 100,0
Total 26 100,0 100,0

Tabla 80: Frecuencia de la variable nivel_utilidad_consumo_energia.
114
Figura 45: Frecuencia de la variable nivel_utilidad_consumo_energia.
Detalle de los datos de producción de energía sin el sistema
Estadísticos
datos de producción de energía a partir
de los medidores?
N Válido 26
Perdidos 0
Media 1,96
Mediana 2,00
Moda 2
Varianza ,438
Rango 2
Tabla 81: Estadísticos de la variable nivel_detalle_produccion_energia.
¿Qué tan preciso considera que son los datos de producción de energía a partir de los
medidores?
Válido Muy poco preciso 6 23,1 23,1 23,1
Poco preciso 15 57,7 57,7 80,8
Regularmente preciso 5 19,2 19,2 100,0
Total 26 100,0 100,0

Tabla 82: Frecuencia de la variable nivel_detalle_produccion_energia.
115
Figura 46: Frecuencia de la variable nivel_detalle_produccion_energia.
Utilidad de los datos de producción de energía sin el sistema
Estadísticos
datos de producción de energía a partir
de los medidores?
N Válido 26
Perdidos 0
Media 2,04
Mediana 2,00
Moda 2
Varianza ,598
Rango 3
Tabla 83: Estadísticos de la variable nivel_utilidad_produccion_energia.
¿Qué tan útil considera que son los datos de producción de energía a partir de los
medidores?
Válido Muy poco útil 6 23,1 23,1 23,1
Poco útil 14 53,8 53,8 76,9
Regularmente útil 5 19,2 19,2 96,2
Útil 1 3,8 3,8 100,0
Total 26 100,0 100,0

Tabla 84: Frecuencia de la variable nivel_utilidad_produccion_energia.
116
Figura 47: Frecuencia de la variable nivel_utilidad_produccion_energia.
Post-test
Gestión de órdenes de reparación
Estadísticos
¿Qué tan eficiente considera al control
de las órdenes de reparación por el
sistema?
N Válido 26
Perdidos 0
Media 4,46
Mediana 4,00
Moda 4
Varianza ,258
Rango 1
Tabla 85: Estadísticos de la variable control_orden_reparacion_sist.
¿Qué tan eficiente considera al control de las órdenes de reparación por el sistema?
Válido Eficiente 14 53,8 53,8 53,8
Muy eficiente 12 46,2 46,2 100,0
Total 26 100,0 100,0

Tabla 86: Frecuencia de la variable control_orden_reparacion_sist.
117
Figura 48: Frecuencia de la variable control_orden_reparacion_sist.
Detalle de los datos de consumo de energía
Estadísticos
datos de consumo de energía
N Válido 26
Perdidos 0
Media 4,38
Mediana 4,00
Moda 4
Varianza ,246
Rango 1
Tabla 87: Estadísticos de la variable nivel_detalle_consumo_energia_sist.
¿Qué tan preciso considera que son los datos de consumo de energía generados por
el sistema?
Válido Preciso 16 61,5 61,5 61,5
Muy preciso 10 38,5 38,5 100,0
Total 26 100,0 100,0

Tabla 88: Frecuencia de la variable nivel_detalle_consumo_energia_sist.
118
Figura 49: Frecuencia de la variable nivel_detalle_consumo_energia_sist.
Utilidad de los datos de consumo de energía con el sistema
Estadísticos
datos de consumo de energía
N Válido 26
Perdidos 0
Media 4,38
Mediana 4,00
Moda 4
Varianza ,246
Rango 1
Tabla 89: Estadísticos de la variable nivel_utilidad_consumo_energia_sist.
¿Qué tan útil considera que son los datos de consumo de energía generados por
el sistema?
Válido Útil 16 61,5 61,5 61,5
Muy útil 10 38,5 38,5 100,0
Total 26 100,0 100,0

Tabla 90: Frecuencia de la variable nivel_utilidad_consumo_energia_sist.
119
Figura 50: Frecuencia de la variable nivel_utilidad_consumo_energia_sist.
Detalle de los datos de producción de energía
Estadísticos
datos de producción de energía
N Válido 26
Perdidos 0
Media 4,38
Mediana 4,00
Moda 4
Varianza ,246
Rango 1
Tabla 91: Estadísticos de la variable nivel_detalle_produccion_energia_sist.
¿Qué tan preciso considera que son los datos de producción de energía generados
por el sistema?
Válido Preciso 16 61,5 61,5 61,5
Muy preciso 10 38,5 38,5 100,0
Total 26 100,0 100,0

Tabla 92: Frecuencia de la variable nivel_detalle_produccion_energia_sist.
120
Figura 51: Frecuencia de la variable nivel_detalle_produccion_energia_sist.
Utilidad de los datos de producción de energía con el sistema
Estadísticos
datos de producción de energía
N Válido 26
Perdidos 0
Media 4,35
Mediana 4,00
Moda 4
Varianza ,235
Rango 1
Tabla 93: Estadísticos de la variable nivel_utilidad_produccion_energia_sist.
¿Qué tan útil considera que son los datos de producción de energía generados
por el sistema?
Válido Útil 17 65,4 65,4 65,4
Muy útil 9 34,6 34,6 100,0
Total 26 100,0 100,0

Tabla 94: Frecuencia de la variable nivel_utilidad_produccion_energia_sist.
121
Figura 52: Frecuencia de la variable nivel_utilidad_produccion_energia_sist.
Generación de reportes
Estadísticos
¿Qué calidad considera que tienen los
reportes generales de consumo y
producción de energía?
N Válido 26
Perdidos 0
Media 4,54
Mediana 5,00
Moda 5
Varianza ,338
Rango 2
Tabla 95: Estadísticos de la variable nivel_calidad_reportes.
¿Qué calidad considera que tienen los reportes generales de consumo y producción de
energía?
Válido Calidad normal 1 3,8 3,8 3,8
Buena calidad 10 38,5 38,5 42,3
Muy buena calidad 15 57,7 57,7 100,0
Total 26 100,0 100,0

Tabla 96: Frecuencia de la variable nivel_calidad_reportes.
122
Figura 53: Frecuencia de la variable nivel_calidad_reportes.
Visualización del flujo de energía
Estadísticos
¿Qué tan interactiva cree que es la
vista del flujo de energía en tiempo
real?
N Válido 26
Perdidos 0
Media 4,77
Mediana 5,00
Moda 5
Varianza ,185
Rango 1
Tabla 97: Estadísticos de la variable nivel_interaccion_flujo_energia.
¿Qué tan interactiva cree que es la vista del flujo de energía en tiempo real?
Válido Interactivo 6 23,1 23,1 23,1
Muy interactivo 20 76,9 76,9 100,0
Total 26 100,0 100,0

Tabla 98: Frecuencia de la variable nivel_interaccion_flujo_energia.
123
Figura 54: Frecuencia de la variable nivel_interaccion_flujo_energia.
Comparación de resultados de las pruebas
Gestión de órdenes de reparación
Figura 55: Histograma de la variable control_orden_reparacion.
124
Figura 56: Histograma de la variable control_orden_reparacion_sist.
Se concluye que la gestión de órdenes de reparación era poco eficiente antes de emplear
el sistema inmótico; después, luego de emplear el sistema inmótico, la gestión de
órdenes de reparación es eficiente.
Detalle de los datos de consumo de energía
Figura 57: Histograma de la variable nivel_detalle_consumo_energia.
125
Figura 58: Histograma de la variable nivel_detalle_consumo_energia_sist.
Se concluye que el detalle de los datos de consumo de energía era poco preciso antes de
emplear el sistema inmótico; después, luego de emplear el sistema inmótico, es preciso.
Utilidad de los datos de consumo de energía
Figura 59: Histograma de la variable nivel_utilidad_consumo_energia.
126
Figura 60: Histograma de la variable nivel_utilidad_consumo_energia_sist.
Se concluye que los datos de consumo de energía eran poco útiles antes de emplear el
sistema inmótico; después, luego de emplear el sistema inmótico, son útiles.
Detalle de los datos de producción de energía
Figura 61: Histograma de la variable nivel_detalle_produccion_energia.
127
Figura 62: Histograma de la variable nivel_detalle_produccion_energia_sist.
Se concluye que el detalle de los datos de producción de energía era poco preciso antes
de emplear el sistema inmótico; después, luego de emplear el sistema inmótico, es preciso.
Utilidad de los datos de producción de energía
Figura 63: Histograma de la variable nivel_utilidad_produccion_energia.
128
Figura 64: Histograma de la variable nivel_utilidad_produccion_energia_sist.
Se concluye que los datos de producción de energía eran poco útiles antes de emplear el
sistema inmótico; después, luego de emplear el sistema inmótico, son útiles.
Generación de reportes
Figura 65: Histograma de la variable nivel_calidad_reportes.
Así mismo, se concluye que la calidad de los reportes generados por el sistema inmótico
son muy buenos, permitiendo ver a detalle los parámetros requeridos para la toma de
decisiones.
129
Visualización del flujo de energía
Figura 66: Histograma de la variable nivel_interaccion_flujo_energia.
Así mismo, se concluye que hay una mejora de visualización del flujo de energía con el
sistema inmótico al considerarlo muy interactiva, ya que le permite al personal de
mantenimiento revisar constantemente el estado tanto del consumo como de la producción
de energía en tiempo real.
A partir del análisis realizado en el programa SPSS, se lograron contrastar las pruebas para
encontrar diferencias significativas en los indicadores reflejadas en la mejora del monitoreo
de energía renovable. Mientras tanto el sistema inmótico cumple con las expectativas del
negocio, aparte de la mejora, con brindar información valiosa para la toma de decisiones
mediante la implementación de medidores, controladores y sensores capaces de brindar
datos y enviarlas a la aplicación web para procesarlos y almacenarlos.
DISCUSIÓN
Orowode et. al (2018) mencionó el control de energía en tiempo real empleando la energía
solar, además de controles de carga para las baterías. Puesto que el sistema está diseñado
para una oficina, el uso de una tarjeta Arduino es suficiente, ya que, al no tratarse de una
zona industrializada, el control no es muy complejo. Es ahí donde Belcredi, Modernel y
Sosa (2015), a través del concepto y el uso del hardware y software Open Source,
menciona la colaboración con futuras investigaciones, ya que se pueden crear PLCs a base
de tarjetas controladoras de Arduino o Raspberry Pi. Chiñas (2017), por otro lado, planteó
un sistema de monitoreo, supervisión y adquisición de datos basado en la web con un
Arduino y un analizador de redes eléctricas. Si bien es cierto que se puede emplear una
130
tarjeta Open Source junto con un analizador para darle una mano y ampliar su capacidad
de análisis, valga la redundancia, el desarrollo de controladores potentes permitiría a los
programadores de hardware involucrarse en el mundo de la electrónica y trabajar en
proyectos más grandes.
Peláez y Jiménez (2018) plantearon una red local basada en protocolos de comunicación
por línea de potencia, donde se transmiten los datos a través de la red eléctrica y el
protocolo TCP/IP, garantizando la transmisión de datos entre dispositivos y la interfaz web.
Mientras tanto, Bejarano (2015) estableció el uso de la fibra óptica extendida con el
estándar GPON. Ambos planteamientos fueron aplicados para el suministro y medición de
energía de los consumidores. Sin embargo, al ser sistemas que trabajan directamente con
el hardware, es indispensable que los equipos estén físicamente conectados, permitiendo
que la escalabilidad esté sujeta al hardware. Esto conlleva a que requieren del
mantenimiento del hardware para su correcto funcionamiento.
Canaza (2018) establece el uso de sensores conectados a un controlador para la

adquisición de datos de un panel fotovoltaico y determinar las condiciones ambientales de
la región Puno para el verdadero desenvolvimiento de los paneles fotovoltaicos. De la
misma manera, Sánchez (2015), implementa un sistema para la medición de variables
climatológicas para la toma de decisiones con respecto a la fabricación de equipos de
energía renovable, garantizando su correcto funcionamiento y adaptabilidad al entorno en
donde se instalará. Entrando a un nivel más profundo, se pueden aplicar medidores y
sensores en los controladores para medir la producción de energía y monitorear su correcto
funcionamiento y desempeño.
Respecto al intercambio de datos entre controlador, red e interfaz, Romero (2015) parte
del uso del GSM en el sistema de monitoreo para poder controlarlo a distancia, ya sean
sitios muy alejados o de acceso restringido. A pesar de que ayuda mucho en la disposición
de los datos, no hay un control centralizado de éstos. Es por ello que, Benique (2017) utiliza
el protocolo OPC para la integración de un sistema industrial, además que garantiza la
compatibilidad de los equipos. Al igual que MQTT, hay un mejor control de las aplicaciones
que se tratarán de conectar al servidor.
En cuanto a la aplicación web, Rosado (2018) menciona un entorno de programación del

PLC que cuenta con herramientas para el desarrollo y despliegue de la aplicación web. Si
bien hace al desarrollo y la visualización de parámetros más simple, sigue estando sujeta
a la configuración del PLC, lo cual no sería tan personalizado ni completo como una
aplicación SCADA hecha con tecnologías web y que realiza operaciones en una base de
datos.
131
CONCLUSIONES
Como se pudo ver en la presente tesis, la automatización del monitoreo de las energías
renovables en el resort se pudo realizar con el sistema inmótico a través del uso de un
controlador, sensores, medidores, etc. para la toma de datos y de una aplicación web para
su procesamiento.
De esta forma se pudo mejorar el proceso de detección y gestión de fallos, automatizar la

adquisición de datos de consumo y producción de energía, mejorar los reportes de
consumo y producción de energía para una mejor toma de decisiones y monitorear la
energía en tiempo real.
Como se pudo comprobar con la evaluación de la propuesta, el personal de mantenimiento

considera eficiente el control de órdenes de reparación, además de considerar precisos y
útiles a los datos de consumo y producción de energía, con una mejor calidad de
información.
En el caso de la interacción con el sistema, debido a la percepción que considera el

personal, se puede deducir que el sistema brinda una mejora en la experiencia de usuario,
de manera que el proceso de monitoreo sea más sencillo con una interfaz amigable.
132
RECOMENDACIONES
Este proyecto se llevó a cabo a partir de la idea de automatizar el monitoreo de la red

eléctrica del resort, que implementa energías renovables de tipo eólica como solar, para
que esté funcional las 24 horas del día, situación que no sería posible con un control
manual.
Debido a que esta investigación abarcó el desarrollo del prototipo, servirá de base las fases
posteriores para trabajar con los profesionales de IoT respecto a las conexiones entre los
equipos eléctricos y la configuración del PLC para el intercambio de datos con la aplicación
web. Por lo tanto, es necesario que se sigan los protocolos de comunicación ya
establecidos entre el controlador y la aplicación web, así como entre el front-end y el back-
end, de tal forma que se evitarán ajustes muy forzados en el cronograma como en el
presupuesto.
Respecto a futuros cambios que solo impliquen al software, es necesario que se justifiquen
sus impactos en la lógica de negocio y en la experiencia de usuario. Así se sabrán si esos
cambios significarían una mejora, por ejemplo, en la escalabilidad del proyecto.
En cuanto a los cambios que impliquen a la red eléctrica, se deben analizar antes si son
respecto a la escalabilidad, porque también impactarían a la aplicación web. Es a partir de
ahí donde impliquen registros de nuevas fuentes, cambios en el mapa, etc.
Prosiguiendo con la escalabilidad del proyecto, se recomienda al equipo de desarrollo que

considere en su documentación los flujos de la aplicación web, la información de los
servicios del back-end y su relación para saber qué flujo llama a qué servicio y qué datos
intercambian. En este mismo punto también se le recomienda documentar los topics del
bróker MQTT, la relación con los flujos que las utilizan y los datos que intercambian. Se
debe tener un registro de las peticiones HTTP que realiza el PLC al back-end. En cuanto a
la base de datos, su relación con los servicios del back-end. Con estas recomendaciones,
el equipo estará más preparado ante los cambios y se le facilitaría más el desarrollo.
Al resort se le recomienda realizar sus operaciones considerando la energía invertida, ya

que lo tendrán registrado y lo podrán consultar en cualquier momento, permitiéndoles
pronosticar cuánta energía necesitarían.
Cabe resaltar que el empleo de energías renovables no supone que se deje de ahorrar. El
resort debe mantener esa cultura eco amigable que lo caracteriza, que es en este caso el
consumo responsable, ya que es parte de su marca personal.
133
Como se puede notar, el sistema inmótico no se ajusta a algunos tipos de energía
renovable, sino que pueden trabajar con una gran variedad y en conjunto. Llevándolo al
plano sostenible, el sistema inmótico cumple con los objetivos de impulsar la energía
asequible y limpia, el crecimiento económico y el aumento del empleo en distintas zonas
del país, la innovación tecnológica, el respeto a la naturaleza y las comunidades
sostenibles. Es ahí donde el resort pueda significar de ejemplo para otros centros de su
misma índole o quizás de otras industrias para impulsar el desarrollo sostenible.
134
REFERENCIAS
Portal de Turismo. (22 de enero del 2020). MINCETUR estima crecimiento del sector
turismo en 10% este 2020. Recuperado de https://portaldeturismo.pe/noticia/mincetur-
estima-crecimiento-del-sector-turismo-en-10-este-2020/
Ministerio de Comercio Exterior y Turismo (MINCETUR) (julio del 2016). Medición

económica del Turismo. Recuperado de https://www.mincetur.gob.pe/wp-
content/uploads/documentos/turismo/publicaciones/MEDICION_ECONOMICA_TURISMO
_ALTA.pdf
Organismo Supervisor de la Inversión en Energía y Minería (OSINERGMIN) (noviembre

del 2019). Energías renovables: Experiencia y perspectivas en la ruta del Perú hacia la
transición energética. Recuperado de
https://www.osinergmin.gob.pe/seccion/centro_documental/Institucional/Estudios_Econo
micos/Libros/Osinergmin-Energias-Renovables-Experiencia-Perspectivas.pdf
Jimenez, T. (diciembre del 2014). Energías renovables y turismo comunitario: una apuesta
conjunta para el desarrollo humano sostenible de las comunidades rurales. Revista
Energética, 44(1). Recuperado de
https://revistas.unal.edu.co/index.php/energetica/article/view/45487
Ministerio de Agricultura y Riego (MINAGRI) (s.f.). Energía Renovable. Recuperado de

https://www.minagri.gob.pe/portal/45-sector-agrario/recurso-energetico/337-energia-
renovable
Stack Overflow. (2019). Stack Overflow Developer Survey 2019. Recuperado de

https://insights.stackoverflow.com/survey/2019
W3schools. (s.f.). AJAX Introduction. Recuperado de

https://www.w3schools.com/xml/ajax_intro.asp
Gómez, R. (febrero del 2020). Diseño e implementación de una red de sensores basada
en protocolos IoT para monitorización de mercancías. Tesis de maestría. Universidad
Autónoma de Madrid, Madrid, España. Recuperado de http://hdl.handle.net/10486/690544
Delta Volt. (s.f.). Energía hidroeléctrica, fuente renovable - Energía solar y eólica en Perú.
Recuperado de https://deltavolt.pe/energia-renovable/renovable-peru
Toscani, M. (22 de junio del 2019). ¿Qué es un hotel resort? Diferencias entre hotel y resort.
Recuperado de http://expertoenhoteles.com/4024/hotel-resort-diferencias-hotel-resort
Diferencia entre Hotel y Resort. (2018, March 6). Recuperado de

https://www.cataloniahotels.com/es/blog/diferencia-entre-hotel-y-resort/
135
Peláez, E. A., Jiménez, P. F. (2018). Diseño de un Sistema de Medición y Monitoreo del
Consumo de Energía por Circuitos en el Hogar, Mediante Tecnología de Comunicación por
Línea de Potencia. Tesis de Pregrado. Universidad del Azuay, Cuenca, Ecuador.
Recuperado de http://dspace.uazuay.edu.ec/bitstream/datos/7930/1/13668.pdf
Orovwode, H., Wara, S., Mercy, T. J., Abudu, M., Adoghe, A., & Ayara, W. (2018).
Development and Implementation of a Web Based Sustainable Alternative Energy Supply
for a Retrofitted Office. 2018 IEEE PES/IAS PowerAfrica.
doi:10.1109/powerafrica.2018.8521132
Belcredi, G, Modernell, P y Sosa, N. (2015). Controlador de energía domiciliario para una

Red Eléctrica Inteligente. Tesis de grado. Universidad de la República, Uruguay.
Recuperado de https://www.colibri.udelar.edu.uy/jspui/handle/20.500.12008/9666
Bejarano, C. A. (2015). Plataforma Unificada De Comunicaciones Multiservicio “Smart Grid”

Para El Monitoreo Y Control De Los Procesos De Suministro Eléctrico En La República
Argentina. Tesis de Maestría. Instituto Tecnológico De Buenos Aires, Buenos Aires,
Argentina. Recuperado de
https://s3.amazonaws.com/academia.edu.documents/50329517
Chiñas, C. D. (junio del 2017). Diseño Y Desarrollo De Un Sistema De Monitoreo Basado

En La Web Para Una Plataforma Híbrida De Energías Renovables. Tesis de Maestría.
Universidad de Guadalajara, Jalisco, México. Recuperado de
http://148.202.168.188/visor/pdfjs/viewer.jsp?in=j&pdf=20.500.12104/73571/1/MCUTONA
LA00054.pdf
Canaza, D. (2018). Desarrollo de un sistema de control para la medición experimental de

la eficiencia en tiempo real de un sistema fotovoltaico (38.4 Watts) en el departamento de
Puno. Tesis de Pregrado. Universidad Nacional del Altiplano, Puno. Recuperado de
http://repositorio.unap.edu.pe/handle/UNAP/8052
Sánchez, M. J. (2015). Modelo matemático del sistema de medición de variables

climatológicas usando un microcontrolador. Universidad Señor de Sipán, 6 (2). Recuperado
de http://revistas.uss.edu.pe/index.php/tzh/article/view/9
Romero, D. A. (agosto del 2015). Diseño de un sistema de monitoreo de parámetros

eléctricos basados en tecnología GSM para un riogenerador PUCP. Tesis de Pregrado.
Pontificia Universidad Católica del Perú, Lima, Perú. Recuperado de
http://tesis.pucp.edu.pe/repositorio/handle/20.500.12404/6230
136
Rosado, D. E. (2018). Desarrollo de un Prototipo de Monitoreo y Supervisión de Costo por
Producto Fabricado por la Empresa Embotelladora San Miguel del Sur S.A.C. Tesis de
Pregrado. Universidad Católica de Santa María, Arequipa, Perú. Recuperado de
http://tesis.ucsm.edu.pe/repositorio/handle/UCSM/8429
Benique, P. P. (2017). Implementación del sistema web de supervisión, control y

adquisición de Datos - Scada en la empresa de generación eléctrica Machupicchu. Tesis
de Pregrado. Universidad Andina del Cusco, Cusco, Perú. Recuperado de
http://repositorio.uandina.edu.pe/handle/UAC/998
Hernandez, R., Fernandez, C., Baptista, M. (2013). Metodología de la investigación (6ta

edición). México: McGraw Hill
Ramírez, L., Arcila, A., Buriticá, L &, Castrillón, J. (2004). Paradigmas y modelos de
Investigación (2da ed.) [archivo PDF]. Recuperado de
http://virtual.funlam.edu.co/repositorio/sites/default/files/repositorioarchivos/2011/02/0008
paradigmasymodelos.771.pdf
Ourahou, M., Ayrir, W., EL Hassouni, B., & Haddi, A. (2018). Review on smart grid control
and reliability in presence of renewable energies: Challenges and prospects. Mathematics
and Computers in Simulation. doi:10.1016/j.matcom.2018.11.009
Li, S., Luo, F., Yang, J., Ranzi, G., & Wen, J. (2019). A personalized electricity tariff
recommender system based on advanced metering infrastructure and collaborative filtering.
International Journal of Electrical Power & Energy Systems, 113, 403–410.
doi:10.1016/j.ijepes.2019.05.042
Ciuffoletti, A. (2017). OCCI-IoT: An API to Deploy and Operate an IoT Infrastructure. IEEE
Internet of Things Journal, 4(5), 1341–1348. doi:10.1109/jiot.2017.2734068
MQTT. (s.f.). MQTT. Recuperado de http://mqtt.org
Moghimi, M., Liu, J., Jamborsalamati, P., Rafi, F., Rahman, S., Hossain, J., Stegen, S., et
al. (2018). Internet of Things Platform for Energy Management in Multi-Microgrid System to
Improve Neutral Current Compensation. Energies, 11(11), 3102. MDPI AG. Recuperado de
http://dx.doi.org/10.3390/en11113102
OWASP (2017). OWASP Top 10 – 2017: Los diez riesgos más críticos en Aplicaciones
Web. Recuperado de https://wiki.owasp.org/images/5/5e/OWASP-Top-10-2017-es.pdf
Hernández, R. (2012). Tecnología domótica para el control de una vivienda. Tesis de

Pregrado. Universidad Politécnica de Cartagena, Cartagena, España. Recuperado de
http://g/bitstream/handle/10317/2793
137
Jones et al. (2015). JSON Web Token. Recuperado de https://www.rfc-
editor.org/rfc/pdfrfc/rfc7519.txt.pdf
Sánchez Cunalata, D. F. (2016). Diseño e implementación de un sistema de domótica

basado en la tecnología smart bus KNX para el control de iluminación, audio y seguridad,
mediante un enlace web Apps, Quito. Tesis de Pregrado. Escuela Politécnica Nacional,
Quito, Ecuador. Recuperado de: http://bibdigital.epn.edu.ec/handle/15000/15357
Laínez, J. (2014). Desarrollo de Software Ágil: Extreme Programming y Scrum (1ra

edición). Estados Unidos: Createspace Independent Publishing Platform.
IBM. (s. f.). Seguridad de MQTT. IBM Knowledge Center. Recuperado de

https://www.ibm.com/support/knowledgecenter/es/SSFKSJ_7.5.0/com.ibm.mm.tc.doc/tc0
0150_.htm
https://www.itg.es/presentamos-la-solucion-iot-y-big-data-que-permite-gestionar-
microrredes-electricas-con-energias-renovables/
Microsoft. (14 de abril del 2016). Documentation for Visual Studio Code. Recuperado de
https://code.visualstudio.com/docs
Robles, V. (18 de diciembre 2018). ¿Qué es Angular y para qué sirve? Recuperado de
https://victorroblesweb.es/2017/08/05/que-es-angular-y-para-que-sirve/
Caceres, M. (26 de julio del 2016). ¿Qué es TypeScript? Recuperado de

https://devcode.la/blog/que-es-typescript/
Eckstein, J., & Baumeister, H. (2004). Extreme Programming and Agile Processes in
Software Engineering: 5th International Conference, XP 2004, Garmisch-Partenkirchen,
Germany, June 6-10, ... (Lecture Notes in Computer Science (3092)) (2004.a ed.). Springer.
Recuperado de
ftp://nozdr.ru/biblio/kolxoz/Cs/CsLn/E/Extreme%20Programming%20and%20Agile%20Pro
cesses%20in%20Software%20Engineering,%205%20conf.,%20XP%202004(LNCS3092,
%20Springer,%202004)(ISBN%203540221379)(371s)_CsLn_.pdf#page=171
Wells, D. (2006a). Extreme Programming Rules. Extreme Programming. Recuperado de

http://www.extremeprogramming.org/rules.html
Wells, D. (2006b). Project Velocity. Extreme Programming. Recuperado de

http://www.extremeprogramming.org/rules/velocity.html
Wells, D. (2006c). Release Planning. Extreme Programming. Recuperado de

http://www.extremeprogramming.org/rules/planninggame.html
138
Wells, D. (2006d). Iteration Planning. Extreme Programming. Recuperado de
http://www.extremeprogramming.org/rules/iterationplanning.html
Wells, D. (2006e). CRC Cards. Extreme Programming. Recuperado de

http://www.extremeprogramming.org/rules/crccards.html
Álvarez, J. & Mejía, J. (2017). TIA PORTAL. Aplicaciones de PLC. Instituto Tecnológico
Metropolitano.
Cálculo e interpretación del Alfa de Cronbach para el caso de validación de la
consistencia interna de un cuestionario, con dos posibles escalas tipo Likert (2015). Revista
Publicando, 2(1), 62-77. ISSN 1390-9304
139

2019 - Toscano Rojas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

2019 - Toscano Rojas

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA

Carrera de Ingeniería Informática y de Sistemas

PROPUESTA DE UN SISTEMA INMÓTICO PARA

Tesis para optar el Título Profesional de Ingeniero

PIERO ALFONZO TOSCANO ROJAS

Figura 2: Frameworks (marcos de trabajo) de desarrollo web que continúan siendo

Figura 3: Figura 3: Funcionamiento de AJAX. ..................................................................26

Figura 4: Estructura del protocolo MQTT. ........................................................................32

Figura 5: Rutas de ataque de aplicaciones web. ..............................................................34

Figura 6: Diagrama de diseño preprueba/posprueba de un grupo. ..................................40

Figura 7: Diagrama del ciclo de vida de un proyecto XP. .................................................45

Figura 8: Diagrama del ciclo de la iteración en la metodología XP. ..................................51

Figura 9: Diagrama de Gantt para el desarrollo del proyecto.. .........................................72

Figura 10: Interfaz de Visual Studio Code.. ......................................................................83

Figura 14: Pantalla de inicio de PlatformIO en Visual Studio Code. .................................88

Figura 15: Raspberry Pi 4 Modelo B. ...............................................................................89

Figura 16: Acceso al sistema.. .........................................................................................90

Figura 25: Gráfico consumo – tiempo. .............................................................................94

Figura 28: Gráfico producción – tiempo. ..........................................................................96

Figura 30: Reporte de historial de consumo de energía de un ambiente particular del

Figura 32: Reporte de historial de producción de energía de una fuente de energía en

Figura 34: Diseño de la base de datos.. ...........................................................................99

Figura 35: Listado de las peticiones HTTP en Postman.. .................................................99

Figura 36: Diagrama de la arquitectura de la aplicación web y su integración con el

Figura 37: Esquema del circuito de pruebas.. ................................................................103

Figura 38: Encuesta del pre-test en Google Forms.. ......................................................108

Figura 39: Encuesta del post-test en Google Forms.. ....................................................109

Figura 40: Recopilación de datos de las encuestas en el software SPSS.. ....................109

Figura 41: Medición de fiabilidad del pre-test. ................................................................110

Figura 42: Medición de fiabilidad del post-test. ..............................................................110

Figura 43: Frecuencia de la variable control_orden_reparacion. ....................................113

Figura 44: Frecuencia de la variable nivel_detalle_consumo_energia............................114

Figura 45: Frecuencia de la variable nivel_utilidad_consumo_energia. ..........................115

Figura 46: Frecuencia de la variable nivel_detalle_produccion_energia.........................116

Figura 47: Frecuencia de la variable nivel_utilidad_produccion_energia. .......................117

Figura 48: Frecuencia de la variable control_orden_reparacion_sist. .............................118

Figura 50: Frecuencia de la variable nivel_utilidad_consumo_energia_sist. ..................120

Figura 51: Frecuencia de la variable nivel_detalle_produccion_energia_sist. ................121

Figura 52: Frecuencia de la variable nivel_utilidad_produccion_energia_sist.................122

Figura 53: Frecuencia de la variable nivel_calidad_reportes. .........................................123

Figura 54: Frecuencia de la variable nivel_interaccion_flujo_energia. ............................124

Figura 55: Histograma de la variable control_orden_reparacion. ...................................124

Figura 56: Histograma de la variable control_orden_reparacion_sist. ............................125

Figura 57: Histograma de la variable nivel_detalle_consumo_energia. ..........................125

Figura 58: Histograma de la variable nivel_detalle_consumo_energia_sist. ...................126

Figura 59: Histograma de la variable nivel_utilidad_consumo_energia. .........................126

Figura 60: Histograma de la variable nivel_utilidad_consumo_energia_sist. ..................127

Figura 61: Histograma de la variable nivel_detalle_produccion_energia. .......................127

Figura 62: Histograma de la variable nivel_detalle_produccion_energia_sist. ................128

Figura 63: Histograma de la variable nivel_utilidad_produccion_energia. ......................128

Figura 64: Histograma de la variable nivel_utilidad_produccion_energia_sist. ...............129

Figura 65: Histograma de la variable nivel_calidad_reportes. ........................................129

Figura 66: Histograma de la variable nivel_interaccion_flujo_energia. ...........................130

Tabla 2: Indicadores de la variable dependiente.. ............................................................42

Tabla 3: Historia de usuario H01.. ....................................................................................46

Tabla 4: Historia de usuario H02.. ....................................................................................47

Tabla 5: Historia de usuario H03.. ....................................................................................47

Tabla 6: Historia de usuario H04.. ....................................................................................47

Tabla 7: Historia de usuario H05.. ....................................................................................48

Tabla 8: Historia de usuario H06.. ....................................................................................48

Tabla 9: Historia de usuario H07.. ....................................................................................48

Tabla 10: Historia de usuario H08.. ..................................................................................49

Tabla 11: Historia de usuario H09.. ..................................................................................49