Desarrollo de una sala inteligente con sistema de control domótico en la Universidad de Oriente

UNIVERSIDAD DE ORIENTE
NÚCLEO DE ANZOÁTEGUI
ESCUELA DE INGENIERÍA Y CIENCIAS APLICADAS
DEPARTAMENTO DE COMPUTACIÓN Y SISTEMAS
“DESARROLLO DE UNA SALA INTELIGENTE CON SISTEMA

DE CONTROL DOMÓTICO UBICADA EN EL
DEPARTAMENTO DE ASESORIA ACADEMICA Y
PROYECTO SABER DE LA UNIVERSIDAD DE ORIENTE
NUCLEO ANZOATEGUI”
Autores:
Br. Julio Cesar Carao Zambrano Br. José Saúl Zambrano Peche.
Trabajo de grado presentado en la Universidad de Oriente como requisito

parcial para optar al título de
INGENIERO EN COMPUTACIÓN.
Barcelona, NOVIEMBRE 2016


ASESORADO POR:
Ing. Pedro Dorta


JURADO CALIFICADOR:
Ing. Pedro Dorta

Asesor Académico
Ing. Víctor Mujica Ing. Stefano Larese

Jurado Principal Jurado Principal

RESOLUCIÓN
De acuerdo al artículo 44 del reglamento de trabajos de grado de la

Universidad de Oriente:
“Los trabajos de grado son de exclusiva propiedad de la

Universidad de Oriente y solo podrán ser utilizados a otros fines con el
consentimiento del Consejo de Núcleo respectivo, quien lo participara al
Consejo Universitario”
iv
DEDICATORIA
A mis amados padres Ing. Saúl Zambrano y Lcda. Zenaida peche

por ser “el alfa y omega” en mi vida, por otorgarme valores, ética, moral y
educación, porque sin ellos. Simplemente no estaría donde estoy.
A mis hermanos por contribuir en mi desarrollo como persona, por

apoyarme en todos los proyectos que me he propuesto por adversos que
parezcan.
José Saúl Zambrano Peche
v
AGRADECIMIENTOS
Agradezco a Dios por estar presente y bendecir cada proyecto que

llega a mi vida.
A Zenaida Peche por ser la mejor Madre, pero también el mejor

Padre, por obsequiarme la vida, por darme la educación más valiosa que
una persona pueda desear, por comprenderme y apoyarme en todo, por
sacrificar cualquier cosa por mi bienestar y el de mis hermanos. Por eso e
infinitas cosas más te estaré en deuda toda la vida, puesto que si existe
mi éxito es por ti. Te amo.
A mi amado Padre, porque pese a que el destino te saco de mi vida

muy temprano, todas tus memorias, actos y enseñanzas quedaron
guardados en mi base de datos para construir el hombre que soy hoy,
este éxito también te pertenece.
A mis abuelos María Angélica, José Aníbal, “Don Martin” y Enma.

Por ser generadores de una educación impecable, plagada de valores y
buenas costumbres, la cual herede gracias a Uds.
A mis hermanos Jaime, chino, María, Enma, Elsi y Wilfredo. Porque

en todo momento cuento con su apoyo para cualquier cosa, por ser porta
voces de educación de calidad y porque en gran medida, Uds. también
son mis padres.
A mis hermanos de la vida Miguel, Hilaria, Cesar, Jordán y Mejías

por ser cómplices participativos en cada reto y proyecto que asumo en la
vida, por su apoyo incondicional y sus buenos consejos. Ahora podemos
celebrar por este éxito hermanos.
A Zuleimi Gómez, por apoyarme de forma incondicional en cada

paso que doy, por comprenderme, apoyarme y darme un máximo de
cariño en cada aspecto por el que está rodeado mi vida.
vi
A Xiomarly y Xiomara, por abrirme la puerta de su casa y
considerarme uno más de los suyos, por siempre tener un consejo o una
palabra de aliento en los momentos buenos y no tan buenos, hago
extensivos estos agradecimientos a otros miembros de esta hermosa
familia, como Sofi, Ricardo, Aurelis, Jadi, Pancho; a todos muchas
gracias.
Agradezco mucho a mis tíos como Rodolfo, Mondinga, Luis,

Maigualida, Doris y todos los demás los cuales de una u otra manera han
contribuido en mi crecimiento personal.
A mis primos hermanos, Gerardo, Petete, Coro, Pilon, entre otros a

los cuales me encuentro muy agradecido.
A mi compañero de tesis y por obras del destino también mi

sobrino, Julio Cesar, por contribuir al éxito de este y muchos más
proyectos.
A mi tutor Pedro Dorta por otorgarme parte de sus conocimientos

sin esperar nada a cambio, este éxito también es tuyo.
A mis socios en materia de trabajo Tato y Andrés por estar en

disposición de ayudar en cualquier aspecto, en todo momento.
A mis eternos compañeros del Coro Universitario entre los cuales

puedo destacar a Alisito, “La chiqui”, Andrea, Jesús, Daniela, Natera,
Alfredo y por supuesto al maestro Rafael y Pedro los cuales fueron una
2da familia cargada de vivencias y conocimientos. A todos les estoy muy
agradecido.
A mis compañeros de carrera. Mariam, Fanny, Félix, Valentina,

Doris, Mafer, Francisco, Stephani, Osman, Adel, Jesús, Marcos, Gabriel,
Roismer, a todos los cuales lamentablemente no puedo nombrar en su
totalidad, pero agradezco profundamente su compañía académica, así
como extra académica.
vii
A mis Mentores Zuli, Tirso, Victor, Stefano, Dalvin, “Pepe” entre
otros por ser multiplicadores del mejor conocimiento que un estudiante
puede desear. Porque gracias a Uds. la academia es lo que es.
Por ultimo agradezco profundamente a todos mis familiares,

amigos, compañeros de clases, etc. los cuales se hace imposible
destacar en estas líneas, que de una u otra manera han contribuido en mi
crecimiento profesional.
José Saúl Zambrano Peche
viii
DEDICATORIA
A Dios, Por haberme permitido llegar hasta este punto y haberme dado
salud para lograr mis objetivos, además de su infinita bondad y amor.
A mi madre Lcda. Enma Zambrano, Por haberme apoyado en todo

momento, por sus consejos, sus valores, por la motivación constante que
me ha permitido ser una persona de bien, pero más que nada, por su
amor.
A mi padre Lcdo. Julio Carao, Por los ejemplos de perseverancia y

constancia que lo caracterizan y que me ha infundado siempre, por el
valor mostrado para salir adelante y por su amor.
A mis familiares, mi hermana Arianna Valentina por ser el ejemplo de

una hermana a pesar de ser menor, la cual aprendí aciertos y de
momentos difíciles; mis tíos, abuelos, primos y aquellos que participaron
directa o indirectamente en la elaboración de esta tesis.
¡Gracias a ustedes!
Julio Cesar Carao Zambrano
ix
AGRADECIMIENTOS
A Dios Todopoderoso, te doy gracias a ti padre por darme la

fuerza necesaria para alcanzar esta meta tan anhelada y por regalarme
una vida llena de bendiciones.
A mi Novia Lcda. Yeniree Rojas que es mi fuente de cariño, apoyo,

lealtad, fuerza, energía, sabiduría, sinceridad, respeto, alegrías, en donde
las dos somos el uno para el otro. Aunque a veces tengamos nuestras
diferencias, gracias amor por estar siempre conmigo.
A mi asesor Ing. Pedro Dorta, por tenerme tanta paciencia y

apoyarme en este proyecto aportándome su conocimiento y experiencia.
A la Universidad de Oriente por haber sido escalón para un sueño

y ser testigo de unos hermosos años de mi vida que han sido plasmado
en tus rincones.
A todos mis profesores, gracias por impartir sus conocimientos

ayudándome a llegar donde estoy ahora.
A mis amigos, por ese apoyo en mi formación profesional y que

hasta ahora, seguimos siendo amigo.

Julio Cesar Carao Zambrano
x
Contenido
CAPITULO I.XIV
1.1.- EL PROBLEMA...................................................................................17
1.2. OBJETIVOS.......................................................................................21
1.2.1. Objetivo General........................................................................21
1.2.2. Objetivos Específicos................................................................21
CAPITULO II - MARCO TEORICO. 22
2.1. ANTECEDENTES................................................................................22
2.2.- BASES CONCEPTUALES....................................................................24
2.2.1. Ambiente...................................................................................24
2.2.2. Ambiente Inteligente..................................................................24
2.2.3. Aplicaciones y Características De Los Ambientes Inteligentes.
.............................................................................................................24
2.2.4. Domótica...................................................................................25
2.2.5. Características de la domótica/inmótica...................................25
2.2.6. Funciones de la domótica (Loja, 2013).....................................26
2.2.7. Medios de Transmisión / Bus....................................................28
2.2.8. Dispositivos...............................................................................29
2.2.9. Estándares................................................................................30
2.2.10. Los Protocolos de Domótica...................................................31
2.2.11. ¿Cómo actúan los Sistemas de Domótica?............................31
2.2.12. Aspectos de un Sistema de Domótica....................................31
2.2.12. Arduino....................................................................................32
2.2.16. Ventajas del uso de Arduino...................................................33
2.2.17. Tipos de placas y shield..........................................................34
2.2.18. Definición de software.............................................................35
2.2.19. Desarrollo del Software...........................................................35
2.2.20. Proceso del desarrollo de Software........................................36
2.2.21. Arquitectura del software.........................................................37
2.2.22. Lenguaje de programación.....................................................37
xi
2.2.23. Programación orientada a objetos (POO)...............................38
2.2.24. Modelo Vista Controlador........................................................38
2.2.25. Sistemas embebidos...............................................................38
2.2.26. Metodología ROPES (Objetos veloces orientados a procesos
para software embebido).....................................................................39
2.2.27. Etapas de la Metodología ROPES (Objetos veloces orientados
a procesos para software embebido)..................................................39
CAPÍTULO III - MARCO METODOLÓGICO. 41
3.1. TIPO DE INVESTIGACIÓN.....................................................................41

3.2. DISEÑO DE LA INVESTIGACIÓN...........................................................41
3.2.1. Etapas del Proyecto..................................................................41
3.3. TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN DE DATOS...................42
3.4. POBLACIÓN Y MUESTRA....................................................................43
CAPITULO IV – RESULTADOS 45
4.1. FASE DE ANALISIS.......................................................................45

4.1.1. ANALISIS DE LOS REQUERIMIENTOS..................................45
4.1.2. ANALISIS DEL SISTEMA.........................................................61
4.1.3. ANALISIS DE OBJETOS..........................................................64
4.2. FASE DE DISEÑO..........................................................................73
4.2.1. MODELO DEL DISEÑO ARQUITECTONICO..........................73
4.2.2. MODELO DEL DISEÑO MECANICISTA..................................73
4.2.3. MODELO DEL DISEÑO DETALLADO.....................................74
4.2.3.1. DIAGRAMA DE FLUJO..........................................................74
4.3. FASE DE TRADUCCIÓN...............................................................79
4.3.1. DISPOSITIVOS Y HERRAMIENTAS........................................79
4.3.2. DIAGRAMA CIRCUITAL...........................................................81
4.3.3. CODIGO FUENTE....................................................................83
4.3.4. PANTALLAS DE LA APLICACION...........................................93
4.3. FASE DE PRUEBAS......................................................................99
4.3.1. PRUEBAS DE INTEGRACION.................................................99
xii
4.3.2. PRUEBAS DE VALIDACION..................................................102
4.3.3. PRUEBA DE COMUNICACION..............................................105
ÍNDICE DE FIGURAS
xiii
Figura 2.1. Ciclo de Vida de ROPES.........................................................39
Figura 4.2. Diagrama de caso de uso general del sistema “SIUM”...........51
Figura 4.3. Diagrama de secuencia de escenario Agregar Ambiente
Fuente: Elaboración propia........................................................................52
Figura 4.4. Diagrama de secuencia de escenario Modificar Ambiente.....53
Figura 4.5. Diagrama de secuencia de escenario Eliminar Ambiente.......54
Figura 4.6. Diagrama de secuencia de escenario Seleccionar Ambiente. 55
Figura 4.8. Diagrama de secuencia de escenario Activar Sistema de
Riesgo........................................................................................................57
Figura 4.9. Diagrama de secuencia de escenario Monitorear Cámaras.. .58
Figura 4.10. Diagrama de secuencia de escenario Energía Sustentable. 59
Figura 4.11. Diagrama de secuencia de escenario Gestionar
Configuración.............................................................................................60
Figura 4.12. Diagrama de Despliegue general sistema “SIUM”................61
Figura 4.13. Diagrama de Componentes del sistema “SIUM” …………
...............................................................................................................….62
Figura 4.14. Diagrama de Componentes del sistema “SIUM”...................64
Figura 4.15. Diagrama de Dominio del sistema “SIUM”............................65
Figura 4.16. Diagrama de Actividades para caso de uso “Seleccionar
Ambiente” implícito en el sistema “SIUM”..................................................66
Figura 4.17. Diagrama de Actividades para caso de uso “Gestionar
Seguridad” implícito en el sistema “SIUM”.................................................68
Figura 4.20. Diagrama de Colaboración para escenario “Agregar
Figura 4.21. Diagrama de Colaboración para escenario “Seleccionar
Figura 4.22. Diagrama de Colaboración para escenario “Modificar
Figura 4.23. Diagrama de Colaboración para escenario “Eliminar
xiv
Figura 4.24. Diagrama de Colaboración para escenario “Activar sistema
de riesgo” implícito en el sistema “SIUM”..................................................72
Figura 4.25. Diagrama de Colaboración para escenario “Monitorear de
cámaras de seguridad” implícito en el sistema “SIUM”.............................73
Figura 4.26. Diagrama de flujo, sistema “SIUM”........................................75
Figura 4.27. Topología de red, sistema “SIUM”.........................................78
Figura 4.28. Tablas de base de datos, sistema “SIUM”............................79
Figura 4.29. Diagrama Circuital, sistema “SIUM”......................................81
Figura 4.30. Esquemático de circuito, sistema “SIUM”..............................82
Figura 4.30. Pantalla Inicio.........................................................................94
Figura 4.31. Pantalla Agregar Ambiente....................................................95
Figura 4.32. Pantalla Eliminar Ambiente....................................................95
Figura 4.33. Pantalla Cámaras de Seguridad............................................96
Figura 4.34. Pantalla Sensores..................................................................97
Figura 4.35. Pantalla Calendario................................................................97
Figura 4.36. Pantalla Configuración – Agregar Usuario............................98
Figura 4.38. Prueba de Integración – Sensor de Temperatura...............100
Figura 4.39. Prueba de Integración – Sensor de Movimiento.................101
Figura 4.40. Prueba de Integración – Cámaras de Seguridad................102
Figura 4.41. Prueba de Integración – Sensor de Movimiento.................103
Figura 4.42. Prueba de Validación – Campos de texto (Log in)..............104
Figura 4.43. Prueba de Validación –Campos de texto (Agregar Ambiente).
..................................................................................................................104
Figura 4.44. Prueba de Comunicación....................................................105
Figura 4.45. Prueba de Comunicación, Pagina Web-PhpMyAdmin-
Arduino.....................................................................................................106
Figura 4.46. Maquetado Sala SIUM.........................................................106
xv
ÍNDICE DE TABLAS
Tabla 2.1. Características comunes entre la domótica e inmótica

(Elaboración Propia)..................................................................................26
Tabla 2.2. Ventajas de Arduino (Arduino WEB Oficial 2015

http:/www.arduino.cc/). (Fuente: Elaboración propia)...............................33
Tabla 4.1. Actores del sistema. (Fuente: Elaboración propia)...................49
Tabla 4.2. Identificación de los casos de uso (Fuente: Elaboración propia).

....................................................................................................................50
xvi
CAPITULO I.
1.1.- El problema.
Según el diccionario de la RAE (Real Academia
Española) domótica viene de la unión de las palabras domus (que
significa casa en latín) y tica (de automática, palabra en griego, 'que
funciona por sí sola').
La domótica es la automatización y control centralizado y/o remoto

de aparatos y sistemas eléctricos y electrotécnicos en la vivienda. Los
objetivos principales de la domótica son aumentar el confort, ahorrar
energía y mejorar la seguridad.
El concepto domótica se refiere a la automatización y control

(encendido / apagado, apertura / cierre y regulación) de aparatos y
sistemas de instalaciones eléctricas y electrotécnicos (iluminación,
climatización, persianas y toldos, puertas y ventanas motorizados, el
riego, entre otros) de forma centralizada y/o remota. El objetivo del uso de
la domótica es el aumento del confort, el ahorro energético y la mejora de
la seguridad personal y patrimonial en la vivienda.
Se propone la implementación de una sala inteligente con sistema

de control domótico para esta casa de estudio. Brindándole ayuda a la
comunidad universitaria especialmente incluyendo a personas con
discapacidad que residen en el núcleo.
Actualmente la Universidad de Oriente núcleo Anzoátegui no

cuenta con instalaciones que ayuden a las personas con discapacidad,
tampoco cuenta con un lugar en donde estas personas puedan estudiar o
ejercer sus labores de forma cómoda sin poder brindarles ayuda a sus
limitantes.
18
Los objetivos de este proyecto serán: Estudiar la situación actual,

recopilar información técnica y aspectos relacionados del espacio donde
se implementará el sistema dentro del departamento de Asesoría
académica y proyecto saber de la Universidad de Oriente. Evaluar y
seleccionar la alternativa tecnológica que tenga mejor relación costo –
calidad para la implementación del sistema. Diseñar y crear la
arquitectura de los sub-sistemas implícitos dentro del sistema domótico
del proyecto. Brindando así un espacio que pueda solventar con ayuda de
la tecnología algunas de las limitantes que tenga la comunidad
universitaria.
Hoy en día, disponer de un ambiente capaz de ofrecer el confort y

la seguridad que permita alcanzar la calidad de estudio o trabajo deseado,
acompañado a su vez, de un ahorro energético, es posible alcanzarlo
utilizando la domótica. Un sistema domótico ofrece aplicaciones prácticas
que son de gran utilidad en el día a día aportando una mayor comodidad y
eficiencia tanto empresarial como académica. Ya lo experimentado por las
comunicaciones en los últimos años se ha llegado a la automatización
total de un espacio dando lugar a lo que hoy en día se conoce como
ambientes inteligentes.
Es de conocimiento general que los espacios con estas

características (Inteligentes) no existen dentro de la Universidad De
Oriente Núcleo Anzoátegui, motivo por el cual mantiene alejada a “la casa
más alta” del oriente del país de la vanguardia tecnológica en aspectos
como los antes mencionados. Además, la alta inseguridad y delincuencia
presentes actualmente en el campus universitario conlleva a la búsqueda
de nuevos métodos más eficientes para el resguardo de las personas y
sus propiedades con el fin de proporcionar bienestar, mayor tranquilidad y
seguridad.
19
El proyecto saber es una entidad que, a través de los años, debido

a la demanda de ingresos al sistema de educación superior ha venido
creciendo de manera vertiginosa, grandes sectores de la población han
ido alcanzando niveles de educación básica y diversificada. Llevando así
al uso inevitable de la implementación de filtros académicos en los
sistemas de admisión que lleva a la exclusión de ciudadanos de las
comunidades e individuos menos favorecidos en la escala social; para un
joven procedente de una familia de los sectores populares con
características de pobreza crítica o pobreza estructural, ingresar a una
carrera universitaria se hace prácticamente imposible.
Por esta razón es necesaria la creación de una sala moderna que

permita cubrir las necesidades tecnológicas a los bachilleres que forman
parte del “Proyecto SABER”.
El desarrollo de esta investigación en su primera fase busca una

adaptación de una sala “Piloto” operativa usando los conceptos de
domótica orientados a cumplir valiosas tareas en áreas del ambiente
inteligente hacia necesidades de protección de equipos básicos e
imprescindibles para el Departamento De Asesoría Académica y Proyecto
Saber del Núcleo Anzoátegui, así como alternativas de ahorro de energía
eléctrica por concepto de Iluminación, Aire Acondicionado y ventilación,
además de supervisar alarmas que indiquen inconvenientes dentro de
dicha sala.
La misión de este proyecto será desarrollar una sala “piloto” que

cumpla las características de un ambiente inteligente y sea flexible a las
necesidades de los usuarios en un momento determinado, donde dichos
ambientes sean dinámicos con la virtud de auto modificación o auto
adaptación dependiendo las exigencias o tipos de tareas a realizar, entre
las cuales pudiéramos destacar, conferencia o video-conferencia, aula
didáctica, sala de comunicaciones, entre otros.
20
La visión de este proyecto será la implementación de una sala

“Piloto” 100% operativa bajo la supervisión de un personal capacitado
para su mantenimiento y con los elementos tecnológicos necesarios para
tener la capacidad de “Auto-defensa”, donde por medio de sensores,
cámaras, alarmas, entre otros se generen las acciones necesarias para
evitar que un ente externo pueda vulnerar la seguridad de la sala, de igual
forma que pueda ser utilizado bajo cualquier escenario que la academia
lo requiera y sea un factor multiplicador para más espacios con estas
mismas características dentro de la universidad.
La importancia del desarrollo de proyectos de este tipo radica

directamente sobre el alcance del mismo ya que no es solo el hecho de
crear una sala piloto con innovadoras características como: sonorización
aplicada a la adaptación de un ambiente ideal o la autonomía de tareas
utilizando controladores, si no que sea el punto de partida para que otros
departamentos de la Universidad de Oriente tomen la iniciativa de
planificar, evaluar, controlar y ejecutar proyectos similares.
Por último es importante agregar que para poder desarrollar este

proyecto de manera formal se modelará el problema usando una
metodología ampliamente utilizada para él diseño e implementación de
sistemas embebidos, como lo es ROPES (Objetos veloces orientados a
procesos para software embebido), la cual propone una serie de fases
secuenciales y se apoya en los paradigmas de la ingeniería de software,
adoptando métodos de especificación, análisis, diseño e implementación
de estándares y el lenguaje de representación más relevante actualmente
como es UML.
21
1.2. Objetivos.
1.2.1. Objetivo General

Desarrollar una sala inteligente con sistema de control domótico
ubicada en el departamento de Asesoría Académica y Proyecto SABER
de la Universidad de Oriente núcleo Anzoátegui.
1.2.2. Objetivos Específicos

Recopilar requisitos funcionales y no funcionales necesarios para la
implantación del sistema.
Diseñar la arquitectura de los sub-sistemas implícitos a nivel de

software del sistema domótico.
Diseñar la arquitectura de los sub-sistemas implícitos a nivel de

hardware del sistema domótico.
Desarrollar la estructura y funcionalidad de la aplicación para el

control del sistema domótico.
Integrar los distintos módulos que engloban el sistema.
Evaluar las pruebas del sistema.

CAPITULO II - MARCO TEORICO.
2.1. Antecedentes.
Bastidas, N. (2008). Desarrollo de un sistema de redes

inalámbricas de alta capacidad (RIDAC) para los servicios de voz, datos
en los taladros de producción de PDVSA Gas Anaco. Trabajo de Grado
de Maestría. Universidad de Oriente, Puerto la Cruz. Al comparar los
basamentos teóricos establecidos a través de los distintos estándares
técnicos con el sistema actual de comunicaciones inalámbricas mediante
el cual se presta el servicio de voz/datos para el control de los taladros de
producción Gas Anaco, con el objeto de desarrollar otro sistema de redes
inalámbricas de alta capacidad que lo sustituya; se puede establecer que
existe una alta factibilidad de realizar este desarrollo con la tecnología
existente actualmente en el mercado.
Buonaffina, R. (2009). Diseño de la red de soporte para la

transmisión de datos gerenciales en el núcleo Nueva Esparta de la
Universidad de Oriente campus Guatamare. Trabajo de Grado de
Maestría. Universidad de Oriente, Puerto la Cruz. La UDONE ha tenido
un gran crecimiento a través de los años, y en consecuencia ha venido
ampliando su visión y sus horizontes, fortaleciéndose y constituyéndose
en ejemplar muestra de mística por el trabajo. Hoy en día sigue creciendo
poniendo en marcha la escuela de Educación con el programa de
Educación Integral, dotada con una nueva infraestructura que no se
puede quedar aislada tecnológica y comunicacionalmente.
Marcano, D. (2009). Diseño de una plataforma de voz sobre IP,

para minimizar costos telefónicos, incrementar la capacidad de
comunicación y facilitar los procesos de intercambio de información entre
23
la administración central del Banco Confederado S. A y cada una de sus

agencias. Trabajo de Grado de Maestría. Universidad de Oriente, Puerto
la Cruz. El confederado, Banco comercial es una institución financiera que
actualmente cuenta con una sede para la administración central en la
ciudad de Porlamar y una red de agencias alrededor de todo el territorio
nacional.
Álvarez, R. (2010). Modelo para determinar la capacidad de

Cómputo intensivo requerida en el procesamiento sísmico como
herramienta de planificación en PDVSA. Trabajo de Grado de Maestría.
Universidad de Oriente, Puerto la Cruz. El Centro de Procesamiento
Geofísico (CPG) es la unidad encargada de brindar apoyo a los procesos
de negocios de exploración de PDVSA. Para ello cuenta con una
plataforma tecnológica de cómputo intensivo, capaz de procesar una gran
cantidad de operaciones de punto flotante por segundo, y es la Gerencia
de Automatización, Informática y Telecomunicaciones, el ente encargado
de garantizar la disponibilidad de los servicios a los negocios y filiales que
hacen vida en el país. Actualmente las capacidades de la plataforma no
cubren las demandas debido a que se están adquiriendo datos sísmicos
3D marinos y no se garantizan tiempos de respuestas aceptables. Debido
a esto es necesario adquirir nuevos equipos, pero se desconoce cuál es
la capacidad que se requiere.
24
2.2.- Bases conceptuales.
2.2.1. Ambiente.
Según el diccionario de la RAE (Real Academia Española) El
Ambiente hace referencia a “Que rodea a un cuerpo o circula a su
alrededor”. Entonces los ambientes o entornos inteligentes se definen
como espacios con sistemas integrados y tecnologías de la información y
de la comunicación que crean entornos interactivos, que aportan la
informática en el mundo físico. Según Steventon y Wright, "entornos
inteligentes son entornos en los que el cálculo se utiliza para mejorar las
actividades ordinarias de manera imperceptible. Una de las fuerzas
motrices del creciente interés en ambientes altamente interactivos es
hacer que no sólo los equipos funcionen de manera sencilla, sino hacerlos
esencialmente invisibles al usuario".
2.2.2. Ambiente Inteligente.

El concepto de Ambiente Inteligente según RAE (Real Academia
Española) dice que está asociado al de Computación Ubicua y se podría
definir como aquel entorno en el que los usuarios interactúan de forma
transparente con multitud de dispositivos conectados entre ellos
intercambiando información y servicios. Este concepto está íntimamente
relacionado con la creación de tecnología con capacidades de cálculo y
comunicación, siempre integrada con los usuarios. El entorno, el
Ambiente Inteligente, debe ser capaz de reconocer y responder a la
presencia y necesidades de los diferentes individuos que interactúan con
el entorno. Para ello es necesario desarrollar tecnologías de “inteligencia
distribuida”, terminales y sensores, biometría y acceso multi-interfaz.
2.2.3. Aplicaciones y Características De Los Ambientes Inteligentes.

Según CASADOMO Algunos ejemplos de las aplicaciones o
características asociadas a esta conceptualización pudieran ser:
Sistemas empotrados para discapacitados.

25
Interacción sensorial vía voz.

Sistemas de entretenimiento doméstico capaces de responder a
las órdenes dadas directamente por la voz humana y crear
fantasías y ambientes digitales para juegos de realidad virtual.
Sistemas basados en avatares inteligentes, soportados por
sistemas expertos, capaces de ayudar a especialistas de un tema
particular en el diseño de sistemas muy complejos, como por
ejemplo la iluminación de un gran aeropuerto.
Control de acceso biométrico de personas a entornos inteligentes.
Reconocimiento de actividades humanas.
2.2.4. Domótica.
La domótica según el sitio web CASADOMO es la automatización y
control centralizado y/o remoto de aparatos y sistemas eléctricos y
electrotécnicos en la vivienda. Los objetivos principales de la domótica es
aumentar el confort, ahorrar energía y mejorar la seguridad.
El concepto domótica se refiere a la automatización y control

(encendido / apagado, apertura / cierre y regulación) de aparatos y
sistemas de instalaciones eléctricas y electrotécnicos (iluminación,
climatización, persianas y toldos, puertas y ventanas motorizados, el
riego, entre otros) de forma centralizada y/o remota. El objetivo del uso de
la domótica es el aumento del confort, el ahorro energético y la mejora de
la seguridad personal y patrimonial en la vivienda.
2.2.5. Características de la domótica/inmótica.

Como se puede observar en las definiciones anteriores, el
concepto de domótica e inmótica son muy parecidos, teniendo como
única diferencia el enfoque de su aplicación ya que la domótica busca la
calidad de vida en el hogar y la inmótica busca la comodidad en
edificaciones no designadas a la vivienda. Las características comunes de
la domótica/inmótica, se pueden apreciar en la tabla 1.
26
Tabla 2.1. Características comunes entre la domótica e inmótica

(Elaboración Propia).
Integración Todo el sistema es controlado por

computadora, con ayuda de una aplicación.
Permite relacionar distintos elementos, con
Interrelación los que el usuario podrá tomar la mejor
decisión a la hora de actuar.
Con sólo acceder a la aplicación, el usuario
estará informado del estado y los eventos
Facilidad de uso que se presentaron en el inmueble en un
tiempo determinado, así como manipular
desde allí y en simples pasos los
dispositivos a su conveniencia.
Para interactuar con el ambiente del
Control Remoto inmueble solo se necesita de un dispositivo
con la aplicación y sus respectivos
permisos.
Los mensajes entre dispositivos llegan a su
Fiabilidad destino de manera interactiva, por lo que
favorece la autonomía del usuario.
2.2.6. Funciones de la domótica (Loja, 2013).

Un sistema domótico cuenta con funciones que brindan beneficios
y ventajas a los usuarios, como:
Ahorro de Energía.
El sistema se puede adecuar para que a determinadas horas

ponga en funcionamiento algún tipo de elemento o que encienda o
apague las luces según sea necesario, de esta forma habrá un aumento
de ahorro eléctrico.
Aumento del confort.

27
Mediante la administración de los dispositivos se puede actuar

sobre ellos directamente, utilizando sus Switch o pulsadores, o si se
prefiere para mayor comodidad, mediante mandos a distancia se pueden
controlar dichos dispositivos ya sean luces, persianas o bien
electrodomésticos.
Aumento de la seguridad.
Mediante el sistema se pueden realizar simulaciones de presencia

en la vivienda, así como detectores de intrusión, movimiento, fuga de
agua entre otros, el sistema mediante una central puede dar aviso a una
central de alarmas o bien a teléfonos particulares programados en caso
de que haya una intrusión o alguna avería técnica, además de poder
conocer el estado del recinto desde cualquier lugar del mundo.
Facilidad en las comunicaciones.
Las aplicaciones de comunicaciones contemplan el intercambio de

información, tanto entre personas como entre éstas y los equipos del
sistema. Algunos ejemplos (telefonía mediante el uso de centrales
domésticas, mantenimiento de los equipos e instalaciones desde un lugar
remoto).
Arquitectura Domótica.
La Arquitectura de los sistemas de domótica hace referencia a la

estructura de su red. Cisco Define la clasificación en base de donde
reside la “inteligencia” del sistema domótico. Las principales arquitecturas
son:
I. Arquitectura Centralizada – En un sistema de domótica de

arquitectura centralizada, un controlador centralizado, envía la
información a los actuadores e interfaces según el programa, la
configuración y la información que recibe de los sensores, sistemas
interconectados y usuarios.
28
II. Arquitectura Descentralizada – En un sistema de domótica de

Arquitectura Descentralizada, hay varios controladores,
interconectados por un bus, que envía información entre ellos y a
los actuadores e interfaces conectados a los controladores, según
el programa, la configuración y la información que recibe de los
sensores, sistemas interconectados y usuarios.
III. Arquitectura Distribuida - En un sistema de domótica de
arquitectura distribuida, cada sensor y actuador es también un
controlador capaz de actuar y enviar información al sistema según
el programa, la configuración, la información que capta por sí
mismo y la que recibe de los otros dispositivos del sistema.
IV. Arquitectura Híbrida / Mixta – En un sistema de domótica de
arquitectura híbrida (también denominado arquitectura mixta) se
combinan las arquitecturas de los sistemas centralizadas,
descentralizadas y distribuidas. A la vez que puede disponer de un
controlador central o varios controladores descentralizados, los
dispositivos de interfaces, sensores y actuadores pueden también
ser controladores (como en un sistema “distribuido”) y procesar la
información según el programa, la configuración, la información
que capta por sí mismo, y tanto actuar como enviarla a otros
dispositivos de la red, sin que necesariamente pasa por otro
controlador.
2.2.7. Medios de Transmisión / Bus.

Según la IEEE los medios de transmisión de la información,
interconexión y control, entre los distintos dispositivos de los sistemas de
domótica pueden ser de varios tipos. Los principales medios de
transmisión son:
Cableado Propio – La transmisión por un cableado propio es el

medio más común para los sistemas de domótica, principalmente
29
son del tipo: par apantallado, par trenzado (1 a 4 pares), coaxial o

fibra óptica.
Cableado Compartido – Varias soluciones utilizan cables
compartidos y/o redes existentes para la transmisión de su
información, por ejemplo, la red eléctrica (corrientes portadoras), la
red telefónica o la red de datos.
Inalámbrica – Muchos sistemas de domótica utilizan soluciones de
transmisión inalámbrica entre los distintos dispositivos,
principalmente tecnologías de radiofrecuencia o infrarrojo.
2.2.8. Dispositivos.
La amplitud de una solución de domótica puede variar desde un
único dispositivo, que realiza una sola acción, hasta amplios sistemas que
controlan prácticamente todas las instalaciones dentro de la vivienda. Los
distintos dispositivos de los sistemas de domótica se pueden clasificar en
los siguientes grupos:
Controlador – Los controladores son los dispositivos que

gestionan el sistema según la programación y la información que
reciben. Puede haber un controlador solo, o varios distribuidos por
el sistema.
Actuador – El actuador es un dispositivo capaz de ejecutar y/o
recibir una orden del controlador y realizar una acción sobre un
aparato o sistema (encendido/apagado, subida/bajada,
apertura/cierre, entre otros).
Sensor – El sensor es el dispositivo que monitoriza el entorno
captando información que transmite al sistema (sensores de agua,
gas, humo, temperatura, viento, humedad, lluvia, iluminación, entre
otros).
Bus – Es el medio de transmisión que transporta la información
entre los distintos dispositivos por un cableado propio, por la red de
30
otros sistemas (red eléctrica, red telefónica, red de datos) o de

forma inalámbrica.
Interface – Las interfaces refieren a los dispositivos (pantallas,
móvil, Internet, conectores) y los formatos (binario, audio) en que
se muestra la información del sistema para los usuarios (u otros
sistemas) y donde los mismos pueden interactuar con el sistema.
2.2.9. Estándares.
X10: Protocolo de comunicaciones para el control remoto de
dispositivos eléctricos, hace uso de los enchufes eléctricos, sin
necesidad de nuevo cableado. Puede funcionar correctamente
para la mayoría de los usuarios domésticos. Es de código abierto y
el más difundido. Poco fiable frente a ruidos eléctricos.
KNX/EIB: Bus de Instalación Europeo con más de 20 años y más
de 100 fabricantes de productos compatibles entre sí.
ZigBee: Protocolo estándar, recogido en el IEEE 802.15.4, de
comunicaciones inalámbrico.
OSGi: Open Services Gateway Initiative. Especificaciones abiertas
de software que permita diseñar plataformas compatibles que
puedan proporcionar múltiples servicios. Ha sido pensada para su
compatibilidad con Jini o UPnP.
LonWorks: Plataforma estandarizada para el control de edificios,
viviendas, industria y transporte.
Universal Plug and Play (UPnP): Arquitectura software abierta y
distribuida que permite el intercambio de información y datos a los
dispositivos conectados a una red.
Modbus Protocolo abierto: permite la comunicación a través de
RS485 (Modbus RTU) o a través de ethernet (Modbus TCP). Es el
protocolo libre que lleva más años en el mercado y que dispone de
un mayor número de fabricantes de dispositivos, lejos de des
31
actualizarse, los fabricantes siguen lanzando al mercado

dispositivos con este protocolo continuamente.
2.2.10. Los Protocolos de Domótica.

Los protocolos de comunicación son los procedimientos utilizados
por los sistemas de domótica para la comunicación entre todos los
dispositivos con la capacidad de “controlador”.
Existen una gran variedad de protocolos, algunos específicamente

desarrollados para la domótica y otros protocolos con su origen en otros
sectores, pero adaptados para los sistemas de domótica. Los protocolos
pueden ser del tipo estándar abierto (uso libre para todos), estándar bajo
licencia (abierto para todos bajo licencia) o propietario (uso exclusivo del
fabricante o los fabricantes propietarios).
2.2.11. ¿Cómo actúan los Sistemas de Domótica?

Los sistemas de domótica actúan sobre, e interactúan con, los
aparatos y sistemas eléctricos de la vivienda según:
El programa y su configuración.
La información recogida por los sensores del sistema.
La información proporcionada por otros sistemas interconectados.
La interacción directa por parte de los usuarios.
2.2.12. Aspectos de un Sistema de Domótica.

Para una elección de sistema de domótica adecuada (para una
vivienda o una promoción de varias viviendas con zonas comunes, entre
otros) es preciso tener en cuenta los siguientes aspectos:
Tipología y Tamaño – La tipología del proyecto arquitectónico

(apartamento, adosado, vivienda unifamiliar), y su tamaño.
Nueva o Construida – Si la vivienda no se ha construido todavía
hay prácticamente libertad total para incorporar cualquier sistema,
32
pero si la vivienda está ya construida, hay que tener en cuenta la

obra civil que conllevan los distintos sistemas.
Las Funcionalidades – La funcionalidad necesaria de un sistema
de domótica suele basarse en la estructura familiar (o la
composición de los habitantes) y sus hábitos y si el uso es para
primera vivienda, segunda vivienda o vivienda para alquiler, entre
otros.
La Integración – Además de los aparatos que se controlan
directamente con el sistema de domótica hay que definir con que
otros sistemas del hogar digital se quiere interactuar, como: luces,
aires acondicionados, entre otros dispositivos inteligentes.
Los Interfaces – Hay una gran variedad de interfaces, como
pulsadores, pantallas táctiles, voz, presencia, móvil, Web, entre
otros. para elegir e implementar. Los distintos sistemas disponen
de distintos interfaces.
El Presupuesto – El coste varía mucho entre los distintos
sistemas, y hay que equilibrar el presupuesto con diferentes
factores que se desean cumplir.
Reconfiguración y Mantenimiento – Hay que tener en cuenta con
qué facilidad se puede reconfigurar el sistema por parte del usuario
y por otro lado los servicios de mantenimiento y post venta que
ofrecen los fabricantes y los integradores de sistemas.
2.2.13. Arduino.
Arduino es una plataforma de prototipo electrónico de código
abierto (open-source) de hardware libre, por lo que es de libre distribución
y utilización, basada en una placa con un microcontrolador y un entorno
de desarrollo. Las placas se pueden ensamblar a mano o encargarlas pre-
ensambladas. El entorno de desarrollo Arduino es multiplataforma y
además se puede descargar gratuitamente desde la página web de
Arduino (Arduino Web-Oficial, 2015).
33
2.2.14. Ventajas del uso de Arduino.

Arduino, además de simplificar el proceso de trabajar con
microcontroladores, ofrece algunas ventajas que se muestra en la tabla
2.2.
Tabla 2.2. Ventajas de Arduino (Arduino WEB Oficial 2015

http:/www.arduino.cc/). (Fuente: Elaboración propia)
La versión más cara de un módulo de

Arduino puede ser montada a mano, e
Accesible incluso ya ensamblada es más
económica que las demás plataformas.
El software de Arduino se ejecuta en
sistemas operativos Windows, Macintosh
Multiplataforma OSX y GNU/Linux. La mayoría de los
sistemas microcontroladores están
limitados a Windows.
El entorno de programación de Arduino
Entorno de programación es fácil de usar para principiantes y lo
simple y directa suficientemente flexible para los usuarios
avanzados.
Software ampliable y de El software Arduino está publicado bajo
código abierto una licencia libre. El lenguaje puede
ampliarse a través de librerías de C++.
Los planos de los módulos están
Hardware ampliable y de publicados bajo licencia Creative
código abierto Commons, por lo que diseñadores de
circuitos pueden hacer su propia versión
del módulo, ampliándolo u optimizándolo.
34
2.2.15. Tipos de placas y shield.

Hay muchas versiones de Arduino, en forma y tamaño. Esto nos
ayuda en la variedad de aplicaciones que se les puede dar. Estas son las
más conocidas (Arduino Web-Oficial, 2015), algunos de ellos son:
Mega: La más grande y potente placa Arduino. Esta placa basada en el

microcontrolador ATmega1280, tiene 54 entradas/salidas digitales (de las
cuales 14 proporcionan salida PWM), 16 entradas digitales, 4 UARTS
(puertos serie por hardware), un cristal oscilador de 16MHz, conexión
USB, entrada de corriente, conector ICSP y botón de reset. Se conecta al
PC con el cable USB o y se puede alimentar con un trasformador o
batería para empezar.
Nano: Es una placa pequeña y compacta, diseñada para usar

directamente en placas de desarrollo, se conecta al ordenador con un
cable Mini-B USB. Está basada en el microcontrolador ATmega328
(Arduino Nano 3.0) o ATmega168 (Arduino Nano 2.x).
Uno: Arduino Uno es una placa basada en el ATmega328. Cuenta con 14

pines entradas/ salidas digitales (de las cuales 6 se puede utilizar como
salidas PWM), 6 entradas analógicas, un resonador cerámico 16 MHz,
una conexión USB, un conector de alimentación, una cabecera ICSP, y un
botón de reset.
Los Shields son placas que se colocan encima de la placa Arduino

para ampliar y agregar una nueva función para que sea controlada desde
Arduino. Estas son las más conocidas (Arduino Web-Oficial, 2015),
algunas de ellas son:
Shield Ethernet: Este shield permite a una placa Arduino conectarse a

una red Ethernet y tener acceso a y desde Internet. Está basada en el
chip Ethernet Wiznet W5100. El Wiznet W5100 provee de una pila de red
IP que soporta TCP y UDP. Soporta hasta cuatro conexiones de sockets
simultáneas. Usa la librería Ethernet para escribir programas que se
35
conecten a internet usando la shield. La Ethernet shield dispone de unos

conectores que permiten conectar a su vez otras placas encima y
apilarlas sobre la placa Arduino. Arduino usa los pines digitales 10, 11, 12,
y 13 (SPI) para comunicarse con el W5100 en la Ethernet shield. Estos
pines no pueden ser usados para entradas/salidas genéricas. La shield
provee un conector Ethernet estándar RJ45. El botón de reset en la shield
resetea ambos, el W5100 y la placa Arduino.
Bluetooth Shield: Este Shield está diseñado para integrar una

comunicación bluetooth a Arduino, y comunicarse con diferentes
dispositivos como computadores, Celulares, Etc.
2.2.16. Definición de software.

El software de computadora es el producto que los ingenieros de
software construyen y después mantienen en el largo plazo. Incluye los
programas que se ejecutan dentro de una computadora de cualquier
tamaño y arquitectura, el contenido que se presenta conforme los
programas se ejecutan y los documentos, tanto físicos como virtuales,
que engloban todas las formas de medios electrónicos (Pressman, 2007).
2.2.17. Desarrollo del Software.

Cuando se desarrolla un software intervienen muchas personas,
como es el cliente quién es el que tiene el problema en su empresa y
desea que sea solucionado, para esto existe el analista de sistema quien
es el encargado de hacerle llegar todos los requerimientos y necesidades
que tiene el cliente a los programadores quienes son las personas
encargadas de realizar lo que es la codificación . Es así como intervienen
varias personas, ya que una sola persona no podría determinar todo los
requerimientos necesarios del sistema.
36
2.2.18. Proceso del desarrollo de Software.

El proceso de desarrollo del software se basa en una serie de
pasos o fases secuenciales, a continuación se desarrollara una breve
explicación de este desarrollo.
El primer paso del proceso es el análisis, es aquí donde el analista

se pone en contacto con la empresa para ver cómo está
conformada, a que se dedica, saber todas las actividades que
realiza en sí, conocer la empresa de manera general para
posteriormente ver cuáles son sus necesidades o requerimientos
que la empresa tiene en ese momento para poder realizar un
análisis de la misma.
El segundo paso es el de diseño aquí entran todo el diseño del
sistema es decir las pantallas, base de datos, todo esto debe
cumplir con ciertos estándares los cuales se toman en cuenta para
poder desarrollar el diseño con calidad y así poder ofrecer un
diseño amigable en cuestión de colores, tamaños de botones,
cajas de texto, entre otros.
El tercer paso es la codificación; es aquí donde se desarrolla todo
el código del sistema por parte del programador esto se hace ya
dependiendo de cada programador ya que cada programador tiene
sus bases o formas para realizarlo pero en si deben todos llegar al
mismo objetivo de ofrecerle funcionalidad al sistema siempre y
cuando apegándose a las especificaciones del cliente.
El cuarto paso son las pruebas, es donde al sistema se pone a
prueba como su palabra lo dice para así poder saber cuáles son
los posibles errores que se están generando del sistema y con ello
mejorarlo para eliminar todos los errores que se puedan presentar
porque un programa con menor error mayor calidad puede llegar a
tener.
37
El quinto y último paso es la instalación; una vez realizadas

las pruebas correspondientes al sistema y haberlo corregido
totalmente se procede a la instalación del mismo ya en la
empresa para su uso correspondiente, todo con la finalidad de que
los procesos se realicen de una manera más eficiente
eliminando costos, tiempo y esfuerzo dentro de la organización.
Para aplicar la mejora a todo lo anterior es necesario aplicar ciertas

pruebas, las cuales se deberán de probar cada etapa
del desarrollo del software, dichas pruebas se deben de realizar de forma
paralela y de forma continua probando la unidad del programa,
la integración del diseño físico, probando el sistema en cuestión al diseño
lógico y por ultimo prueba de aceptación esta se realiza en base a los
requerimientos que se obtuvieron anteriormente, este es un proceso de
prueba sencilla y muy utilizada.
Como conclusión se puede decir que con el mantenimiento

oportuno se garantiza la calidad del producto.
2.2.19. Arquitectura del software.

La arquitectura de un sistema de software es la estructura o
estructuras del sistema, que incluye elementos de software, las
propiedades externamente visibles de esos elementos y la relación entre
ellos. (IEEE1471, 2000).
2.2.20. Lenguaje de programación.

Cuando el procesador es una computadora, el algoritmo se ha de
expresar en un formato que se denomina programa. Un programa se
escribe en un lenguaje de programación y las operaciones que conducen
a expresar un algoritmo en forma de programa se llama programación.
Así pues, los lenguajes utilizados para escribir programas de
computadoras son los lenguajes de programación y programadores son
los escritores y diseñadores de programas (Aguilar, 2000).
38
2.2.21. Programación orientada a objetos (POO).

La Programación Orientada a Objetos (POO) es una forma de
enfocar la tarea de programación. La Programación Orientada a Objetos
toma las mejores ideas de la programación estructurada y la combina, con
nuevos y poderosos conceptos que animan o alientan una nueva visión
de la tarea de la programación. La Programación Orientada a Objetos
permite descomponer fácilmente un problema en subgrupos de partes
relacionadas. Entonces, puede traducir estos subgrupos en unidades
auto-contenidas llamadas Objetos (Itapizaco, 2009).
2.2.22. Modelo Vista Controlador.

El modelo–vista–controlador (MVC) es un patrón de arquitectura de
software, que separa los datos y la lógica de negocio de una aplicación de
la interfaz de usuario y el módulo encargado de gestionar los eventos y
las comunicaciones. Para ello MVC propone la construcción de tres
componentes distintos que son el modelo, la vista y el controlador, es
decir, por un lado, define componentes para la representación de la
información, y por otro lado para la interacción del usuario. Este patrón de
arquitectura de software se basa en las ideas de reutilización de código y
la separación de conceptos, características que buscan facilitar la tarea
de desarrollo de aplicaciones y su posterior mantenimiento.
2.2.23. Sistemas embebidos.

Se entiende por sistemas embebidos a una combinación de
hardware y software de computadora, sumado tal vez a algunas piezas
mecánicas, este tipo de sistemas están diseñados para tener una o
algunas pocas funciones dedicadas. Es común el uso de estos
dispositivos, pero pocos se dan cuenta que hay un procesador y un
programa ejecutándose que les permite funcionar.
39
2.2.24. Metodología ROPES (Objetos veloces orientados a procesos

para software embebido)
La metodología ROPES (Rapid Object Oriented Process for Embedded

Systems) propone un proceso completo para el desarrollo de sistemas
empotrados, está basada en UML (Unified Modeling Language) por lo que
posee un modelo de vida iterativo. ROPES, (Douglass, 1999) además de
tener como propósito la mejorar y ordenamiento de lo que se desea
realizar, también permite llevar a cabo los siguientes puntos:
Incrementar la calidad del producto.
Mejorar la atención y repetición de los esfuerzos de desarrollo.
Disminuir el esfuerzo demandado para desarrollar el producto final

con el nivel requerido de calidad.
Permite la reutilización.
Estabilidad y capacidad de mantenimiento.
Mejora la previsibilidad del proyecto en términos de: esfuerzo y

tiempo de programación.
Conjuntamente, por ser un proceso orientado a objetos, ROPES,

adquiere todas las ventajas de este tipo de aplicaciones. De esta manera,
se asegura que el sistema que se está analizando será de calidad, y
logrado con menos esfuerzos.
2.2.25. Etapas de la Metodología ROPES (Objetos veloces orientados

a procesos para software embebido)
ROPES, (Douglass, 1999) cuenta con cuatro fases: análisis, diseño,

traslación y pruebas, siendo los artefactos resultantes de cada fase,
40
modelos o diagramas UML que se refinan o corrigen en las fases

siguientes.
Las fases trabajan sobre un modelo organizado del sistema, que

internamente consiste en un conjunto de abstracciones que colaboran
para llevar acabo la descripción del mismo, en un nivel de detalles y
madurez deseado. Estas fases se pueden apreciar en la figura 1.
Cada fase identificada en el modelo de ROPES está organizada en

un ciclo de vida iterativo. Cada prototipo implementa uno o más casos de
uso organizados por el de mayor riesgo, lo que permite la exploración
temprana de los mismos, minimizando él número de modelos que deben
ser modificados por causa de estos riesgos.
Cada uno de estos prototipos es ejecutable y puede ser probado. El punto

clave de esta tecnología que hace rápido y eficiente al proceso es la
traslación automática de estos modelos en código ejecutable, reduciendo
el tiempo necesario para realizar iteraciones completas de semanas o
meses a días y horas.
Figura 2.1. Ciclo de Vida de ROPES

41
Fuente: Pacheco M. Franco D. (2016)

Análisis: se Identifican las características y requisitos esenciales para
obtener todas las posibles soluciones. Se llevan a cabo tres tipos de
análisis. Un análisis de requisitos, en el que se especifican los requisitos
funcionales y no funcionales del sistema. En segundo lugar, el análisis de
sistema, se realiza la división de responsabilidades entre el hardware y el
software, la arquitectura de alto nivel del sistema y los algoritmos de
control necesarios. Y por último el análisis de objetos, el cual comprende
dos grandes tareas, en una, se determinan los modelos estructurales de
los objetos que han de componer el sistema y en la otra, se modela su
comportamiento mediante colaboraciones o diagramas de secuencias.
Diseño: Se agregan los elementos necesarios al análisis para que

definan una solución particular óptima. En la fase de diseño se llevan a
cabo los diseños de la arquitectura, mecanismos y el detallado. La
generación de código ejecutable a partir del diseño del sistema.
Traducción: Se realiza la construcción de una realización ejecutable e

implantable del diseño que comprende la generación de código ejecutable
a partir del diseño del sistema
Pruebas: Se verifica que la traducción es equivalente al diseño. Valida

que la implementación cumple los criterios de corrección identificados en
el análisis. De igual forma se comprueba la conformidad de la aplicación,
sea para encontrar defectos o para observar un cierto nivel funcional.
Incluye pruebas de integración y de validación
Es posible implantar estas etapas también a través de un ciclo de

vida estándar o un ciclo de vida en espiral. Abarca etapas tempranas, qué
tienen una visión general de los proyectos de sistema y la implementación
de éstos.
CAPÍTULO III - MARCO METODOLÓGICO.
3.1. Tipo de Investigación.

Basados en la definición Según Hernández (2004), en donde los
estudios descriptivos miden, evalúan o recolectan datos sobre diversos
aspectos, dimensiones o componentes del fenómeno a investigar. El
estudio está fundamentado en una investigación de tipo descriptiva.
3.2. Diseño de la Investigación.

Según Gutiérrez (1991) el diseño de la investigación se refiere al
conjunto de decisiones, pasos, esquemas y actividades a realizar en el
curso de la investigación. La realización de esta investigación se
fundamenta en un diseño de campo, el cual consiste en la observación
directa del problema objeto de la investigación. La investigación se basa
en la observación directa, donde se interactuará directamente con los
administradores de los diferentes subsistemas y se observará
directamente el comportamiento de los equipos que formaran parte de la
plataforma tecnológica del Edificio Administrativo de Exploración.
La investigación se realizará de acuerdo a la ejecución de las

siguientes etapas:
3.2.1. Etapas del Proyecto.

Etapa I. Revisión Bibliográfica
En esta etapa se revisará la información relacionada con el tema a

desarrollar (revistas, informes técnicos, manuales, entre otros) que
permitirán adquirir conocimientos necesarios para el óptimo desarrollo del
estudio a realizar.
43
Etapa II. Análisis.
En esta etapa se realizarán tres tareas básicas que serían la

obtención de los requisitos, análisis del sistema y análisis de objetos con
el propósito de tener una descripción general de la sala inteligente.
Etapa III: Diseño
En esta etapa se modelará de manera formal mediante el uso de

artefactos descritos por la metodología (Artefactos UML), de forma que se
tenga una visión clara del funcionamiento del sistema y subsistemas
implícitos, esta etapa se divide en dos partes, una orientada al software y
otra al hardware.
Etapa IV: Traducción
En esta etapa se realizará la construcción de la estructura y

funcionalidad de la aplicación, así como la integración de los distintos
módulos que abarca la arquitectura del sistema domótico, con el objetivo
de lograr una plataforma eficiente, flexible y confiable.
Etapa V: Pruebas
Se realizarán distintos tipos de pruebas al sistema con el fin de

evaluar la seguridad de la aplicación, así como su pleno funcionamiento.
3.3. Técnicas e instrumentos de recolección de datos.

Para el desarrollo de este proyecto se utilizarán las siguientes
técnicas para la recopilación de datos:
Observación: esta técnica consiste en ver y oír todo lo vinculado

al sistema en estudio. Se utilizará una guía de observación en la
cual se registrará toda la información recopilada.
Revisión documental: esta consiste en la revisión de textos,
documentos o artículos que contengan información teórica acerca
del comportamiento del sistema en estudio.
44
Entrevista: está técnica consiste en una conversación entre el

entrevistado y el entrevistador. Para la aplicación de esta técnica
se diseñarán cuestionarios de preguntas abiertas.
Lenguaje unificado de modelado (UML): El UML proporciona los
diagramas que pueden utilizarse para el análisis y diseño al nivel
software, y proyectos basados en sistemas embebidos, es una
técnica muy importante a tener en cuenta en el desarrollo de
software ya que ayuda a tener una mejor comprensión de la
estructura del sistema.
Técnicas y herramientas de programación de aplicaciones
web: Se utilizarán lenguajes y Entornos de Desarrollo Integrado
(IDE) orientados a la creación de aplicaciones de manipulación vía
web bajo el paradigma de Programación Orientada a Objetos
(POO).
Metodología ROPES: Es una metodología basada en un ciclo de
vida iterativo que utiliza UML para representar sus diagramas y
permite la creación de prototipos de forma fácil y rápida.
3.4. Población y Muestra.

La población está representada por 253 estudiantes que tienen la
ayuda del proyecto saber. La muestra se define según Jiménez C, (1983)
como una parte o subconjunto de una población normalmente
seleccionada de tal modo que ponga de manifiesto las propiedades de la
población. Su característica más importante es la representatividad, es
decir, que sea una parte típica de la población en la o las características
que son relevantes para la investigación.
Teniendo en cuenta lo anterior, se puede decir, que la muestra

para la presente investigación está dada por 9 usuarios de servicios
logísticos y telecomunicaciones que son los encargados de administrar
los diferentes sub-sistemas en estudio, el criterio para la selección de
esta muestra se basó en escoger de cada sub-sistema en estudio un
45
número de usuarios que desde el punto de vista de uso de los sistemas

puedan representar toda la problemática existente, de esta manera se
puede obtener una visión global de toda la gerencia de Exploración sin
repercutir en información redundante al tomar toda la población como
muestra.
CAPITULO IV – RESULTADOS
4.1. FASE DE ANALISIS.

La principal meta de esta fase es la del arranque del proyecto en sí.
Todos y cada uno de los análisis pertinentes de la información recabada
tienen lugar al comienzo de esta etapa, para poder obtener los requisitos
necesarios que permitan debido a lo expuesto en el planteamiento del
problema justificar el desarrollo del sistema.
En esta fase se estudiaron a fondo y se recabaron de forma clara

los requisitos necesarios para llevar a cabo la implementación del
proyecto, Se usaron diversos artefactos UML sugeridos por la
metodología usada para documentar tales requerimientos. Entre estos
pudiéramos destacar la presencia de Diagramas de caso de uso,
diagramas de comunicación, diagramas de secuencia, diagrama de
dominio, entre otros; Divididos en 3 sub fases con características propias
como lo son Análisis de los requerimientos, Análisis de sistema y Análisis
de objetos las cuales juntas logran construir Análisis como una fase
robusta y a prueba de fallos
También es importante destacar que se realizó un análisis de los

posibles riesgos a los cuales puede estar sometido el sistema, esto
debido a que siempre hay que tomar en cuenta los posibles escenarios en
los cuales la aplicación pudiera incurrir en fallas.
4.1.1. ANALISIS DE LOS REQUERIMIENTOS.

El análisis de requerimientos extrae los requisitos del cliente. El
cliente puede ser cualquier persona que tiene la responsabilidad de definir
lo que hace el sistema. Para el caso particular de esta aplicación se
establecieron los requisitos funcionales y no funcionales de forma textual,
47
también se apoyó en la utilización de diagramas de caso de uso para

visualizar de forma clara cada funcionalidad del proyecto.
4.1.1.1. REQUERIMIENTOS DEL SISTEMA.

Para lograr este objetivo se hizo necesario el conocimiento de las
características del sistema, los procesos que se deben cumplir y las
necesidades de satisfacer, Para la elaboración correcta de esta fase fue
necesaria, además, la identificación de aquellos requisitos ambiguos e
incompletos de los funcionales y no funcionales.
La información encontrada de un profundo análisis de procesos

que ocurren en la aplicación para el manejo de sus actividades, se divide
y resume de la siguiente manera:
El sistema debe permitir el acceso solo a usuarios que estén

definidos en el sistema
Solo podrá agregar, modificar, eliminar usuarios el

administrador del sistema.
El sistema debe tener la capacidad de permitir la

visualización de cámaras de seguridad.
Permitir el manejo de climatización de forma automatizada.
Permitir el manejo de iluminación de forma automatizada
Manejo de alertas por mensajes de textos y correo

electrónicos.
El sistema debe tener la capacidad de manejar la energía de
forma sustentable.
Por otra parte, los requisitos no funcionales los cuales especifican

la propiedad del sistema, restricciones, rendimiento, mantenimiento,
48
extensibilidad o fiabilidad. Se puede entender que dicho requisito no

puede asociarse a ningún caso de uso específico determinado, sin
embargo, cada uno de ellos tienen impacto sobre varios casos de uso o
ninguno. Por esta razón también son importantes al momento del
conocimiento y análisis de un sistema. A continuación, se muestra los
requisitos no funcionales del sistema:
Extensible: Se tomó en cuenta que el sistema debe permitir la

incorporación de nuevas funcionalidades en su estructura, el
ingreso de futuras ampliaciones y el soporte de mayor cantidad de
datos a través del tiempo.
Mantenible: El sistema permitirá el mantenimiento y ampliación de
la funcionalidad del mismo.
Transparencia: El sistema ofrece la posibilidad de ser accesible a
una revisión por alguien distinto a quien lo ha creado y que la
documentación del sistema sea clara.
Amigable: El diseño de la interfaz de usuario posee una interfaz
amigable, de forma que resulte de fácil entendimiento para los
usuarios.
Seguridad: Proporcionara la seguridad necesaria de los datos
manejados.
Preventivo: Se ofrece la utilidad de emitir aviso a cualquier tipo de
cambios realizados al sistema.
Eficiencia: Su estructura fue diseñada de tal forma que pueda
agilizar los procesos cotidianos para lograr aumentar la
productividad en los trabajos realizados, y disminuir los tiempos de
ocio ocasionado por el retardo en la respuesta del sistema.
4.1.1.2. ANALISIS DE RIESGOS.

49
En la metodología ROPES es importante reconocer los riesgos

más importantes o críticos en la fase de Análisis ya que esto garantiza
acabar con los mismos en una etapa temprana del proyecto.
Para la identificación de los riesgos se recabo información de las

características que debe poseer el sistema empotrado para que se
garantice su pleno funcionamiento, tomando en cuenta que los aspectos
referentes a requisitos estarán dirigidos por casos de uso, el cual se
centra en la arquitectura. Se pudieron identificar los siguientes riesgos.
Violación del sistema al momento de visualizar la información no

autorizada al usuario que haya ingresado al sistema, es por esto
que se establece el uso de contraseña y nombre de usuario para
ingresar de manera correcta.
La posibilidad de fallas de alimentación al sistema, por lo que se

debería proponer un posible medio alterno de generación de
electricidad.
Teniendo en cuenta los riesgos identificados, se desarrollarán los

casos de uso y demás diagramas UML necesarios para llegar a un
balance entre los requisitos del sistema y las condiciones que deben
cumplir, para así eliminar o disminuir los riesgos.
4.1.1.3 DIAGRAMA DE DOMINIO.
En el siguiente diagrama se muestra una perspectiva de las clases

conceptuales respecto al funcionamiento del sistema. Se encuentra
representado por la figura 4.1.
50
Figura 4.1 Diagrama de Dominio del sistema “SIUM”

Fuente. Elaboración propia.
51
4.1.1.4 CASOS DE USO.
4.1.1.4.1.1 Identificación de los actores del sistema.
El contexto del sistema luego de ser analizado permite entonces,

identificar los actores del sistema. Los actores, son personas, sistemas, o
hardware que interactúan con el sistema, quienes hacen uso de la
funcionabilidad de la misma o aportan funcionalidad, por lo tanto, pueden
obtener o ingresar información. Un sistema externo es considerado un
actor que actúa con el sistema. Básicamente los actores son los terceros
que interactúan con el sistema y los casos de uso definen la forma en la
que ellos van a ser utilizados. En la tabla 4.1 se muestran los actores del
sistema y sus funciones.
Tabla 4.1. Actores del sistema. (Fuente: Elaboración propia).
ACTOR FUNCIONES
Es el súper usuario en el sistema,
quien activa los flujos de
actividades en el sistema, su
Administrador función es activar los distintos tipos
de ambiente, puede recibir alertas
del sistema, así como visualizar las
cámaras de seguridad dentro del
espacio.
Se trata de usuarios que han sido
ingresados al sistema por la
creación y autorización del
“Administrador”, el cual solo tiene
Usuario acceso limitado al sistema,
específicamente Solo puede
seleccionar ambientes
52
predeterminados descritos en el
sistema.
Este actor es de suma importancia
ya que siendo un actor externo se
Sensor encarga de capturar toda la
información de los eventos o
fenómenos que suceden en la sala
para luego pueda ser procesada por
el controlador, como temperatura,
movimiento, entre otros.
4.1.1.4.2.2 Identificación de los casos de uso.
Un caso de uso es un modo de utilizar el sistema, si se sabe

describir todos los casos de uso, se sabrá lo que debe hacer el sistema.
En el modelo de caso de uso del sistema SIUM se podrá observar su
descripción en la tabla 4.2, donde se muestran los casos de uso, sus
descripciones y actores.
Tabla 4.2. Identificación de los casos de uso (Fuente: Elaboración propia).

53
CASO DE USO DESCRIPCIÓN ACTORES

En este se realizan las
operaciones de Administrador
selección de ambiente, Sensor
las cuales buscan
Gestionar Ambiente adaptaciones ideales
de iluminación y
climatización,
dependiendo de un
escenario determinado.
En este flujo se realizan
las acciones de Administrador
Gestionar Seguridad monitoreo de sensores Sensor
que permiten activar el
sistema de riesgo y
ahorro de energía como
a su vez monitoreo de
cámaras de seguridad.
Este caso de uso
especifica toda la toma Sensor
Gestionar Energía de decisiones
Sustentable necesarias para que el
consumo de energía del
sistema sea la ideal.
Se realizan las
Gestionar operaciones básicas a Administrador
Configuraciones nivel de configuración
de usuario
A continuación, en la figura 4.2 se muestra el diagrama de caso de uso
generalas del sistema SIUM donde se muestra en detalle lo expuesto en
las tablas anteriores sobre cada caso de uso general, los actores que
intervienen y las relaciones que existen entre cada uno de ellos.
54
Figura 4.2. Diagrama de caso de uso general del sistema “SIUM”

4.1.1.5. DIAGRAMAS DE SECUENCIAS
En el diagrama 4.3 se muestra la secuencia de pasos que se deben

seguir en el sistema. Este se inicia en el momento en el que el usuario
entra a la aplicación y el sistema carga el formulario. Una vez validados,
son enviados a la base de datos la cual maneja absolutamente todos los
datos del sistema.
55
Figura 4.3. Diagrama de secuencia de escenario Agregar Ambiente

Fuente: Elaboración propia.
Los diagramas de secuencia subsecuentes son auto descriptivos.
La siguiente Figura 4.4 muestra el diagrama de secuencia para el

escenario modificar Ambiente.
56
Figura 4.4. Diagrama de secuencia de escenario Modificar Ambiente


escenario eliminar Ambiente.
57
Figura 4.5. Diagrama de secuencia de escenario Eliminar Ambiente


escenario Seleccionar Ambiente.
58
Figura 4.6. Diagrama de secuencia de escenario Seleccionar Ambiente


escenario Seleccionar Ambiente Usuario.
59
Figura 4.7. Diagrama de secuencia de escenario Seleccionar Ambiente

escenario Activar Sistema De Riesgo.
60
Figura 4.8. Diagrama de secuencia de escenario Activar Sistema de

Riesgo

escenario Monitorear Cámaras.
61
Figura 4.9. Diagrama de secuencia de escenario Monitorear Cámaras.


escenario Energía Sustentable.
Figura 4.10. Diagrama de secuencia de escenario Energía Sustentable.

62

escenario Gestionar Configuración.
Figura
4.11. Diagrama de secuencia de escenario Gestionar Configuración.
63
4.1.2. ANALISIS DEL SISTEMA.

4.1.2.1 ARQUITECTURA DEL MODELO
4.1.2.1.1 DIAGRAMA DE DESPLIEGUE
Un diagrama de despliegue muestra las relaciones físicas entre los

componentes hardware y software en el sistema final. En la figura 4.12 se
muestra los componentes que describen al sistema en forma
cliente/servidor, así como la comunicación entre ellos.
Figura 4.12. Diagrama de Despliegue general sistema “SIUM”

64
65
4.1.2.1.2 DIAGRAMA DE COMPONENTES
El diagrama de componentes muestra las relaciones lógicas de los

diversos componentes e interfaces que interactúan en el sistema. En la
figura 4.13 se muestra dichos componentes que describen al sistema
SIUM.
Figura 4.13. Diagrama de Componentes del sistema “SIUM”

66
4.1.2.2. ESPECIFICACION DEL SOFTWARE
Tomando en cuenta que este sistema posee una arquitectura

(software/hardware) es importante contemplar cada una de las
responsabilidades que tienen ambas partes del proyecto. En el caso
particular de las especificaciones del software tomaremos en cuenta que
se encargara de gestionar o automatizar el flujo de actividades a
realizarse en la sala, como lo son:
Gestionar la selección de ambiente.

Gestionar la creación de nuevos ambientes.
Gestionar la modificación de ambientes.
Gestionar la eliminación de ambientes.
Ofrecer una plataforma de visualización de las cámaras de
seguridad.
Realizar el manejo de configuraciones a nivel de usuario como:
agregar, modificar, eliminar usuarios.
4.1.2.3. ESPECIFICACION DEL HARDWARE
En el caso particular de las especificaciones del hardware

tomaremos en cuenta que se encargara del manejo de la toma de
decisiones lógica de acuerdo a las señales que reciben y envía el
microcontrolador, entre estas podemos destacar:
Verificación constante del estado de los sensores.

Enviar las señales necesarias para la activación del módulo de
ahorro energético.
El microcontrolador se encargará de establecer la comunicación
entre el software y los diferentes sensores.
67
4.1.3. ANALISIS DE OBJETOS.

4.1.3.1 MODELO ESTRUCTURAL
4.1.3.1.1 DIAGRAMA DE CLASES.
En el diagrama de clase de esta sub-fase, se aprecia las clases

básicas que debe tener el prototipo: actuadores, sensores, usuario,
servidor y reportes. Se encuentra representado por la figura 4.14.
Figura 4.14. Diagrama de Componentes del sistema “SIUM”

68
4.1.3.2 MODELO DE OBJETOS
4.1.3.2.1 DIAGRAMA DE ACTIVIDADES.
En los siguientes diagramas se modelan los aspectos dinámicos de

los casos de usos y mostrando el flujo de control entre actividades. Se
encuentran representados por las siguientes figuras las cuales muestran
un flujo de actividades para escenarios específicos en el sistema.
Diagrama de Actividades para caso de uso “Seleccionar Ambiente”

– Usuario/Administrador, representado por figura 4.15.
Figura 4.15. Diagrama de Actividades para caso de uso “Seleccionar

Ambiente” implícito en el sistema “SIUM”
69
Diagrama de Actividades para caso de uso “Gestionar Ambiente”,

representado por figura 4.16.

70
Diagrama de Actividades para caso de uso “Gestionar Seguridad”,

representado por figura 4.17.

Seguridad” implícito en el sistema “SIUM”
71
Diagrama de Actividades para caso de uso “Gestionar

Configuración”, representado por figura 4.18.

Configuración” implícito en el sistema “SIUM”

72
4.1.3.2.2. DIAGRAMA DE COLABORACION.
En estos diagramas se especifican las interacciones de las

operaciones con determinados objetos en escenarios determinados. A
continuación, se muestran los diagramas de colaboración por escenario
para cada uno de los casos de uso presentes en el sistema.
En el diagrama de colaboración de la figura 4.19 se muestra el

resultado final de las interacciones entre objetos para el caso de uso
“Gestionar Ambiente”, específicamente en el escenario de “Agregar
Ambiente”. Se puede observar que el Administrador una vez dentro de su
interfaz puede acceder a la modalidad de creación de ambiente y
visualizar el resultado de la operación realizada en la misma vista.
Figura 4.19. Diagrama de Colaboración para escenario “Agregar


“Gestionar Ambiente”, específicamente en el escenario de “Seleccionar
Ambiente”. Se puede observar que el Usuario al entrar al sistema tiene
acceso a la vista principal, donde tendrá una lista de opciones de
Ambientes determinados para seleccionar, de ahí puede luego
seleccionar un ítem y visualizar el resultado en la misma vista.
73
Figura 4.20. Diagrama de Colaboración para escenario “Seleccionar


“Gestionar Ambiente”, específicamente en el escenario de “Modificar
Ambiente”. Se puede observar que el Administrador una vez dentro del
sistema tiene la facultad de modificar Ambientes previamente diseñados
en el sistema y una vez realizado todos los cambios puede visualizar una
respuesta automática de la operación que ha realizado.
Figura 4.21. Diagrama de Colaboración para escenario “Modificar

En el siguiente diagrama de colaboración de la figura 4.22 se

muestra el resultado final de las interacciones entre objetos para el caso
de uso “Gestionar Ambiente”, específicamente en el escenario de
“Eliminar Ambiente”. Donde se puede observar que el Administrador una
vez dentro del sistema tiene la facultad de realizar una operación de tipo
“delete” y de esa manera eliminar de la lista de ambientes uno
previamente creado, de igual manera este puede visualizar el resultado
obtenido en la misma vista que se encuentra.
74
Figura 4.22. Diagrama de Colaboración para escenario “Eliminar


de uso “Gestionar Seguridad”, específicamente en el escenario de
“Activar sistema de riesgo”. Donde se puede observar que el
Administrador una vez dentro de esta parte del sistema puede en un
momento determinado accionar un sistema de alerta por violación de
seguridad o riesgo en la integridad de la sala, esto a modo de pruebas ya
que de igual manera el sistema posee la facultad de activar de forma
autónoma este módulo en un posible caso de violación de seguridad o
activación de los sensores de integridad.
Figura 4.23. Diagrama de Colaboración para escenario “Activar sistema

de riesgo” implícito en el sistema “SIUM”

de uso “Gestionar Seguridad”, específicamente en el escenario de
“Monitorear cámaras de seguridad”. Donde se puede observar que el
Administrador una vez haya ingresado un ingreso satisfactorio al sistema
75
tiene la posibilidad de seleccionar la opción de Monitorear cámaras en la

sala y poder visualizar en tiempo real lo que capturan las mismas, todo
esto dentro de la misma vista donde se encuentra.
Figura 4.24. Diagrama de Colaboración para escenario “Monitorear de

cámaras de seguridad” implícito en el sistema “SIUM”
4.2. FASE DE DISEÑO.

Si bien el análisis identifica el modelo lógico o esencial de un sistema,
diseño define una única solución particular que es en cierto sentido "
óptima “. Tres de ellos son actualmente tres sub fases de diseño:
arquitectónico, mecanicistas y detalladas.
4.2.1. MODELO DEL DISEÑO ARQUITECTONICO.

Para efecto del sistema SIUM el diseño arquitectónico nos definió las
decisiones y las estrategias que afectarían la mayor parte o la totalidad de
los componentes de software, tales como diagrama de clases, diagrama
de componentes, diagramas de secuencias, diagrama de comunicación,
entre otros. Pero debido a que todos los requisitos y casos fueron
identificados de forma clara en la fase de análisis, no se crearon nuevos
diagramas de este tipo ya que sería redundante.
4.2.2. MODELO DEL DISEÑO MECANICISTA.

En el sistema el diseño mecanicista elabora colaboraciones individuales
mediante la adición de objetos para unir el mecanismo de juntas y
optimizar su funcionamiento. Sin embargo, se hace innecesario la
76
reutilización de los diagramas que la metodología expone (Diagrama de

clases, diagrama de componentes, diagrama de comunicación, entre
otros) debido a que todos los requisitos fueron identificados en primera
instancia en la fase de análisis.
4.2.3. MODELO DEL DISEÑO DETALLADO.

En el diseño detallado del sistema SIUM se definió el interior de la
estructura y comportamiento de las clases individuales. Esto incluye la
estructuración de datos interna y Detalles del algoritmo.
4.2.3.1. DIAGRAMA DE FLUJO.

La siguiente imagen representada por la figura 4.25, nos muestra
en forma de flujo de actividades y decisiones una aproximación del
funcionamiento del sistema, en él se puede visualizar cada una de las
operaciones del sistema, así como las posibles rutinas en las cuales
puede entrar el sistema de control en un momento determinado.
77
Figura 4.25. Diagrama de flujo, sistema “SIUM”

78
4.2.3.2. PSEUDOCODIGO.
4.2.3.2.1. Pseudocódigo de microcontrolador Arduino Mega 2560.

PROGRAMA: Recibir datos de los sensores.
ENTORNO: pines, valor actual, valor nuevo, base de datos, alarma.
ALGORITMO:
INICIO
RECIBIR pines, valor actual
SI valor actual DEL pin ES MAYOR O IGUAL al valor nuevo
ACTUALIZAR LA base de datos
SINO
NO ACTUALIZAR BASE DE DATOS.
FIN
PROGRAMA: Actualización Ambiente.

ENTORNO: pin, estado actual, estado anterior, base de datos.
ALGORITMO:
INICIO
CONEXIÓN CON LA base de datos
RECIBIR pin, estado actual
SI estado actual DEL pin ES DIFERENTE AL estado anterior DEL pin
MOSTRAR estado actual DEL pin
HACER estado anterior DEL pin IGUAL AL estado actual DEL pin
SINO
NO HUBO ACTUALIZACIÓN AMBIENTE
FIN
4.2.3.2.2. Pseudocódigo de los controladores de la página web.

PROGRAMA: configuración Automática.
ALGORITMO:
INICIO
CONEXIÓN CON LA base de datos
RECIBIR pin, estado actual
SI estado actual DEL pin ES DIFERENTE AL estado anterior DEL pin
MOSTRAR estado actual DEL pin
HACER estado anterior DEL pin IGUAL AL estado actual DEL pin
SINO
NO HUBO ACTUALIZACIÓN AMBIENTE
FIN
INICIO LOGIN
SI RECIBE alias, clave ENTONCES
HACE solicitud de verificacion de usuario
SI es el usuario ENTONCES
SI la clave y el usuario son correctos ENTONCES
Permitir entrada
SINO mandar menesaje de error
HACE solicitud de actualizar datos de inicio de sesion
SI fue exitosa la solicitud ENTONCES
Verifica el tipo de ambiente
SINO envía error
SINO error al recibir los datos
79
FIN LOGIN
INICIO LOGOUT
RECIBE tipo de logout
Cerrar sesión
SI tipo es igual a 0 ENTONCES
REDIRIGE a login 0
FIN LOGOUT
INICIO configuracionAmbiente
SI RECIBE id_Ambiente ENTONCES
HACE solicitud de mostrarTiposDeAmbientes
MIENTRAS recibe SeleccionDeAmbiente ENTONCES
Muestramensaje Ambiente Seleccionado
SINO escribir "no recibe"
FIN configuracionManual
INICIO actualizarPasswordUsuario
SI RECIBE idUsuario, password1,
HACE solicitud de NuevaPassword
SI NuevaPassword ENTONCES
SI clave1!=clave2 ENTONCES
Mostrar "Clave actualizada con éxito"
SINO mostrar "Verifique sus datos”
SINO mostrar " Error, por favor intentar de nuevo"
FIN actualizarPasswordUsuario
INICIO actualizarDatosUsuario
SI RECIBE idUsuario, password1,
HACE solicitud de NuevoNombre O NuevoApellido O NuevoCorreo
SI NuevoNombre ENTONCES
SI Nombre1!=Nombre2 ENTONCES
Mostrar "Nombre actualizado con éxito"
SI NuevoApellido ENTONCES
SI Apellido1!=Apellido2 ENTONCES
Mostrar "Apellido actualizado con éxito"
SI NuevoCorreo ENTONCES
SI Correo1!=Correo2 ENTONCES
Mostrar "Correo actualizado con éxito"
SINO mostrar " Error, por favor intentar de nuevo"
FIN actualizarDatosUsuario
INICIO REPORTES
HACE solicitud de obtener datos de consultaPDF
SI tiene los resultados ENTONCES
MIENTRAS haya datos
Prepara campos del pdf
RETORNA pdf
FIN REPORTES
80
4.2.3.3. TOPOLOGIA DE RED.
Para efectos del sistema de control se estableció una topología de

red compuesta por diversos dispositivos que hacen posible la
comunicación entre todos los periféricos necesarios para que el sistema
SIUM se levante, en la figura 4.26 se pueden observar dichos
dispositivos, así como la comunicación de los mismos.
Figura 4.26. Topología de red, sistema “SIUM”

4.2.3.4. TABLAS DE BASES DE DATOS.
Para el manejo de los datos dentro del sistema se utilizó el

manejador PHP MyAdmin, el cual autogenera las tablas necesarias para
abordar las operaciones que requiere el sistema. En la figura 4.27 se
pueden observar cada una de las tablas de las que se vale el sistema
para realizar sus consultas.
81
Figura 4.27. Tablas de base de datos, sistema “SIUM”

4.3. FASE DE TRADUCCIÓN.
4.3.1. DISPOSITIVOS Y HERRAMIENTAS.

Para modelar de forma correcta lo que propone el sistema SIUM se
hizo necesaria la implementación de diversos dispositivos y programas,
como sensores, actuadores y periféricos, así como algunas herramientas
de software que ayudaron en la simulación del mismo, a continuación, se
muestra la tabla 4.3, donde se describen brevemente las funciones de
estos equipos.
82
Tabla 4.3. Dispositivos y herramientas (Fuente: Elaboración propia)
Dispositivos de Hardware
Equipo Función
Micro controlador de placa Atmega, este maneja todas
Arduino MEGA 2560 R3 las instrucciones y tomas de decisiones dentro del
sistema
Gestiona la comunicación del microcontrolador con el
Arduino Ethernet Shield resto de los dispositivos del sistema.
Este se configuro como enrutador para gestionar las
Router TP-Link N600 comunicaciones entre los elementos presentes en la red
del sistema.
Módulo Sensor de Utilizado para verificar el estado del clima en la sala.
Temperatura DS18B20
Este usado principalmente como un sensor destinado a
Módulo Sensor de capturar posibles eventos relacionados con la integridad
presencia de la sala.
Este módulo es usado para capturar la presencia de
Módulo Sensor de flama llamas en la sala y por ende generar posibles alertas.
Esta interfaz esta usada en el sistema para conectar el
Módulo Relay sistema de ventilación al sistema de control
Este cumple la función de modelar la verificación del
Módulo Transmisor de movimiento físico en una puerta automatizada y por ende
laser gestionar su apertura.
Sensor de humo Usado para capturar presencia de humo en la sala y en
base a esto gestionar alertas.
Herramientas de Software
Aplicación de diseño de espacios físicos, la cual fue
utilizada para modelar una aproximación de la
SketchUp Pro 2016 distribución de mobiliario y equipos presentes en la sala
SIUM.
Se utilizó para crear el renderizado y generación de video
Cinema 4D de la aproximación de la sala.
Aplicación web que brindo la plataforma para la creación
Draw.io y generación de los distintos diagramas UML.
Aplicación de escritorio que brindo la plataforma para la
Star UML creación y generación de los distintos diagramas UML.
Se utilizó esta plataforma para codificar todas las
Arduino IDE instrucciones a nivel del microcontrolador.
Este IDE, se usó para codificar todas las instancias
Sublime Text necesarias para la aplicación web.
Se usó para gestionar la interacción con la base de datos
PHP My Admin del sistema.
83
4.3.2. DIAGRAMA CIRCUITAL.

Una vez obtenidos artefactos vitales de las fases previas y
adquiridos todos los integrados para construir la maquetación del sistema
empotrado se pudo simular verificar el funcionamiento a nivel de
circuitería, para ello se usó la aplicación la cual ofreció la plataforma para
poder importar y simular todos los sensores y demás elementos utilizados
por el sistema. En las siguientes tomas de pantalla, denotadas por las
figuras 4.28 y 4.29, muestran el diagrama circuital del sistema SIUM, así
como el esquemático del circuito respectivamente.
Figura 4.28. Diagrama Circuital, sistema “SIUM”

84
Figura 4.29. Esquemático de circuito, sistema “SIUM”

85
4.3.3. CODIGO FUENTE.

4.3.3.1 CODIGO FUENTE DE ARDUINO MEGA 2560 R3.
#include <SPI.h>
#include <Ethernet.h>
#include <OneWire.h>
#include <DallasTemperature.h>
byte mac[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFF, 0xEE}; // MAC ARDUINO.
byte ip[] = {192, 168, 0, 101}; //IP ARDUINO.
byte server[] = {192, 168, 0, 100}; //IP PC.
byte gateway[] = {192, 168, 0, 1}; //ROUTER.
byte dns_server[] = {192, 168, 0, 1}; //ROUTER.
EthernetClient client;
//DATOS PARA EL SENSOR DE TEMPERATURA

#define Pin 4 //Se declara el pin donde se conectará la DATA PARA EL
SENSOR DE TEMPERATURA.
OneWire ourWire(Pin);
DallasTemperature sensors(&ourWire);
int valor_temperatura;
//DATOS PARA EL SENSOR DE MOVIMIENTO

int lees = A0;
int counter = 0;
int detect = 20;
int lastValue;
int button = 8;
int valor_movimiento;
//DATOS PARA EL SENSOR DE FUEGO

int ledPin = 13;
int inputPin = 2;
int pirState = LOW;
int val = 0;
int pinSpeaker = 10;
int valor_fuego;
//DATOS PARA EL SENSOR DE HUMO

int pin_mq = 3;
int valor_humo;
//DATOS PARA EL SENSOR DE LASSER

int Laser = 6;
int Detector = 7;
int valor_lasser;
void setup()
{
delay(1000);
pinMode(lees, INPUT);//SENSOR DE MOVIMIENTO
pinMode(button, INPUT);//SENSOR DE MOVIMIENTO
pinMode(ledPin, OUTPUT);//SENSOR DE FUEGO
pinMode(inputPin, INPUT);//SENSOR DE FUEGO
pinMode(pinSpeaker, OUTPUT);//SENSOR DE FUEGO
pinMode(pin_mq, INPUT);//SENSOR DE HUMO
pinMode(Laser, OUTPUT);//SENSOR DE LASSER
pinMode(Detector, INPUT);//SENSOR DETECTOR
digitalWrite(button, HIGH); //SENSOR DE MOVIMIENTO.
86
sensors.begin(); //Se inicia el sensor de temperatura

pinMode(30, OUTPUT); //LEDS
pinMode(32, OUTPUT);//LEDS
pinMode(9,OUTPUT);//VENTILADOR
Ethernet.begin(mac, ip);
Serial.begin(9600);
}
void loop()
{
Temperatura();
delay(100);
Movimiento();
delay(100);
Fuego();
delay(100);
Humo();
delay(100);
Lasser();
delay(100);
funcionCambioRemoto();
Serial.println();
delay(3000);
}
void Temperatura()
{
sensors.requestTemperatures();
valor_temperatura=sensors.getTempCByIndex(0);
valor_temperatura=valor_temperatura+27;
Serial.print(valor_temperatura);
Serial.println(" grados Centigrados");
if (client.connect(server, 80))
{
client.print("GET /Arduino/ConexionTemperatura.php?valor=");
client.print(valor_temperatura);
client.println(" HTTP/1.0");
client.println();
client.stop();
}
delay(1000);
}
void Movimiento()
{
int a = analogRead(lees);
int buttonState = digitalRead(button);
if(a < detect && lastValue > 1020)
{
Serial.print("Individuo Detectado");
counter ++;
if (client.connect(server, 80)){
valor_movimiento=1;
client.print("GET /Arduino/ConexionMovimiento.php?valor=");
client.print(valor_movimiento);
client.println();
client.stop();
}
87
{
Serial.print("No se Ha detectado Nada");
{
valor_movimiento=0;
client.print("GET /Arduino/ConexionMovimiento.php?valor=");
client.print(valor_movimiento);
client.println();
client.stop();
}
}
if(buttonState == 0)
{
resetCounter();
}
lastValue = a;
delay(2000);
Serial.println();
}
}
void resetCounter()
{
counter = 0 ;
delay(1000);
}
void Fuego()
{
val = digitalRead(inputPin);
if (val == HIGH)
{
digitalWrite(ledPin, HIGH);
playTone(300, 160);
delay(150);
if (pirState == LOW)
{
Serial.println("FUEGO DETECTADO!");
pirState = HIGH;
{
valor_fuego=1;
client.print("GET /Arduino/ConexionFuego.php?valor=");
client.print(valor_fuego);
client.println();
client.stop();
}
}
}//FIN IF
else
{
digitalWrite(ledPin, LOW); // turn LED OFF
playTone(0, 0);
delay(300);
if (pirState == HIGH)
{
88
Serial.println("FUEGO NO DETECTATDO!");
pirState = LOW;
{
valor_fuego=0;
client.println();
client.stop();
}
}
else
{
Serial.println("No se ha detectado fuego");
{
valor_fuego=0;
client.println();
client.stop();
}
}
}//FIN ELSE
}
void playTone(long duration, int freq)

{
duration *= 1000;
int period = (1.0 / freq) * 1000000;
long elapsed_time = 0;
while (elapsed_time < duration)
{
digitalWrite(pinSpeaker,HIGH);
delayMicroseconds(period / 2);
digitalWrite(pinSpeaker, LOW);
delayMicroseconds(period / 2);
elapsed_time += (period);
}
}
void Humo()
{
boolean mq_estado = digitalRead(pin_mq);//Leemos el sensor
if(mq_estado) //si la salida del sensor es 1
{
Serial.println("Sin presencia de Humo");
{
valor_humo=0;
client.print("GET /Arduino/ConexionHumo.php?valor=");
client.print(valor_humo);
client.println();
client.stop();
}
}
else //si la salida del sensor es 0
{
Serial.println("Humo Dectectado");
{
89
valor_humo=1;
client.print("GET /Arduino/ConexionHumo.php?valor=");
client.print(valor_humo);
client.println();
client.stop();
}
}
delay(2000);
}
void Lasser()
{
digitalWrite(Laser, HIGH);
boolean vale = digitalRead(Detector);
Serial.println("PUERTA CERRADA");
delay(1000);
}
void funcionCambioRemoto()
{
int pin = 0;
int pin2 = 0;
Serial.println("Conectandose a funcionCambioRemoto");
{
client.print("GET /arduino/retorna.php?retorno=");
client.println(1);
client.println("User-Agent: Arduino Mega 2560");
client.println();
pin = client.parseInt();
client.stop();
client.flush();
Serial.print("Id Ambiente: ");
Serial.println(pin);
}
{
client.print("GET /arduino/retorna2.php?retorno=");
client.println(1);
client.println("User-Agent: Arduino Mega 2560");
client.println();
pin2 = client.parseInt();
client.stop();
client.flush();
Serial.print("Porcentaje de luz: ");
Serial.print(pin2);
Serial.println("%");
}
if(pin ==1)
{
Serial.print("Ha Seleccionado el ambiente: Estudio ");
digitalWrite(30, HIGH); // set the LED on
90
digitalWrite(32, LOW); // set the LED on

digitalWrite(9,HIGH);
}
if(pin ==2)
{
Serial.print("Ha Seleccionado el ambiente: Conferencia ");
}
if(pin ==3)
{
Serial.print("Ha Seleccionado el ambiente: Curso ");
}
if(pin ==4)
{
Serial.print("Ha Seleccionado el ambiente: Cerrado ");
digitalWrite(9,LOW);
}
if(pin >=5)
{
Serial.print("Ha Seleccionado el ambiente: Personalizado ");
}
else
{
Serial.println("");
}
}
4.3.3.2. CODIGO FUENTE DE APLICACIÓN WEB.
Login.PHP:
<!DOCTYPE html>
<html lang="es">
<head>
91
<meta charset="UTF-8">
<title>SISTEMA</title>
<meta name="viewport" content="width=device-width, initial-
scale=1">
<link rel="stylesheet" type="text/css"
href="../bootstrap/css/bootstrap.css">
href="../bootstrap/css/bootstrap.min.css">
href="../bootstrap/css/estilo.css">
<script type="text/javascript" src="../bootstrap/js/jquery-
2.2.2.js"></script>
<script type="text/javascript" src="../bootstrap/js/jquery-
2.2.2.min.js"></script>
<script type="text/javascript"
src="../bootstrap/js/bootstrap.js"></script>
<script type="text/javascript"
src="../bootstrap/js/bootstrap.min.js"></script>
</head>
<body>
<p align="center"><img src="../imagenes/logo.png" width="300"
height="220" border="4"></p>
<form class="login" action="../controlador/login.php" method="POST">
<div class="form-group">
<p align="center"><input type="text" class="form-control"
placeholder="USUARIO" name="user" required autofocus></p>
</div>
<div class="form-group">
<p align="center"><input type="password" class="form-control"
placeholder="CONTRASEÑA" name="password" required> </p>
</div>
<p align="center">
<button class="btn btn-info" type="submit" >Aceptar</button>
<button class="btn btn-info" type="submit"
onclick=location="http://localhost/sistema/index.php" >Cancelar</button>
</p>
</form>
<div id="pie">
<hr />
<div align="center"> SISTEMA AUTOMATIZADO SIUM </div>
</div>
</div>
<?php
$mjs=$_GET['sms'];
?>
<div id="myModal" class="modal fade" >
<div class="modal-dialog">
<div class="modal-content ">
<div class="modal-header">
<button type="button" class="close" data-
dismiss="modal">×</button>
<h4 class="modal-title">Informacion</h4>
</div>
<div class="modal-body">
<?php
if($mjs==1){ ?>
92
<p><?php echo 'Bienvenido al Sistema Sium'; ?

></p>
<?php } else if($mjs==2){ ?>
<p><?php echo 'Error, el usuario o contraseña no
coinciden' ?></p>
<p><?php echo 'Usted a cerrado el Sistema Sium,
esperamos que regrese pronto' ?></p>
<p><?php echo 'Usted no esta autorizado para ver esa
informacion' ?></p>
<?php }else if($mjs==5){ ?>
<p><?php echo 'Ambiente Agregado' ?></p>
<?php } ?>
</div>
</div>
</div>
</div>
<?php if($mjs!= null ) {?>
<script>
$("#myModal").modal("show");
</script>
<?php } ?>
SuperAdmin.PHP:
<!DOCTYPE html>
<html lang="es">
<head>
<title>Sistema Sium</title>
scale=1">
href="../../bootstrap/css/bootstrap.css">
href="../../bootstrap/css/bootstrap.min.css">
<script>
if(history.forward(1)){
history.replace(history.forward(1));
}
</script>
<div style="margin:20px 0 0 0; text-align:center;">
</head>
<frameset cols="22%,*" frameborder=0>

<frame name="" src="menu.php"/>
<frame name="principal" src="inicio.php?sms=1"/>
</frameset>
</html>
Superadmin/menú.PHP:
<!DOCTYPE html>
<html lang="es">
<head>
<title>Sistema Sium</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
93
href="../../bootstrap/css/bootstrap.css">
href="../../bootstrap/css/bootstrap.min.css">
href="../../bootstrap/css/estilo2.css">

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<script type="text/javascript" src="../../bootstrap/jquery-
1.3.2.js"></script>
<link rel="stylesheet" href="../../bootstrap/css/styles.css"
type="text/css" charset="utf-8"/>
</head>

<body>
<div class="header"></div>
<div class="scroll"></div>
<ul id="navigation">
<li class="home"><a href="inicio.php" target="principal"
title="Home"></a></li>
<li class="ambientes"><a href="ambiente/op-ambiente.php"
target="principal" title="Ambientes"></a></li>
<li class="camaras"><a href="camaras/op-camaras.php"
target="principal" title="Camaras De Seguridad"></a></li>
<li class="monitoreo_sensores"><a href="reportes.php"
target="principal" title="Monitoreo"></a></li>
<li class="configuracion"><a href="configuracion/op-
configuracion.php" target="principal" title="Configuracion"></a></li>
<li class="salir"
onclick="top.location.href='../../controlador/salir.php'"><a href=""
target="" ><b></b></a>
</ul>
<script type="text/javascript">
$(function() {
$('#navigation a').stop().animate({'marginLeft':'-
85px'},1000);
$('#navigation > li').hover(

function () {
$('a',$(this)).stop().animate({'marginLeft':'-
2px'},200);
},
function () {
$('a',$(this)).stop().animate({'marginLeft':'-
85px'},200);
}
);
});
</script>
</body>
</html>
Ambiente/op-ambiente.PHP:
94
<!DOCTYPE html>
<html lang="es">
<head>
<title>Sistema SIUM</title>
scale=1">
href="../../../bootstrap/css/bootstrap.css">
href="../../../bootstrap/css/bootstrap.min.css">
href="../../../bootstrap/css/estilo1.css">
<p align="center" style="left: 100px;"><img
src="../../../imagenes/logo.png" width="300" height="220"
border="4"></p>
<body>
<BR>
<h2><i>Ambientes</i></h2>
<a href="agregar-ambiente.php?sms=1"
target="principal"><b>  ->Agregar Nuevo Ambiente</b></a>
<BR>
<a href="modificar-ambiente.php" target="principal">  -
><b>Modificar Ambiente</b></a>
<BR>
<a href="eliminar-ambiente.php" target="principal">  -
><b>Eliminar Ambiente</b></a>
<BR>
<a href="seleccionar-ambiente.php"
target="principal">  -><b>Seleccionar Ambiente</b></a>
<br>
</body>
</html>
Cámaras/op-camaras.PHP:
<!DOCTYPE html>
<html lang="es">
<head>
scale=1">
border="4"></p>
<body>
<h2><i>Sistema de Monitoreo</i></h2>
<center><iframe src="http://localhost/sium/camaras.html"
width="1000" height="800"> </iframe></center>
</body>
95
</html>
96
Configuración/op-configuracion.php
<!DOCTYPE html>
<html lang="es">
<head>
scale=1">
border="4"></p>
<body>
<BR>
<h2><i>Configuracion</i></h2>
<a href="agregar-usuario.php?sms=1"
target="principal"><b>  ->Agregar Nuevo Usuario</b></a>
<BR>
<a href="modificar-usuario.php" target="principal">  -
><b>Modificar Usuario</b></a>
<BR>
<a href="eliminar-usuario.php" target="principal">  -
><b>Eliminar Usuario</b></a>
<BR>
<a href="listar-usuario.php" target="principal">  -
><b>Listar Usuarios</b></a>
<br>
</body>
</html>
4.3.4. PANTALLAS DE LA APLICACION.

Una vez traducidos todos los ajustes de la aplicación a nivel de
diseño y codificación se verificaron todos los módulos de la misma para
probar su óptimo funcionamiento, a continuación, se muestran una serie
de imágenes con contenido referente a tomas de pantalla de la aplicación
en funcionamiento en tiempo real.
97
Pantalla Inicio: en la siguiente imagen, denotada por la figura 4.30

se puede observar la pantalla de inicio a la aplicación del sistema,
donde se puede identificar algunos aspectos como el nombre del
Administrador en la esquina superior derecha, así como aspectos
principales de la aplicación como lo es la barra lateral izquierda que
agrupa todas las operaciones posibles, y en la parte central se
muestra un status actual del sistema.
Figura 4.30. Pantalla Inicio.

Pantalla Agregar Ambiente: en la siguiente imagen, denotada por

la figura 4.31 se pueden observar cada uno de los campos
necesarios para que el administrador pueda agregar un ambiente
nuevo con opciones personalizadas.
98
Figura 4.31. Pantalla Agregar Ambiente.

Pantalla Eliminar Ambiente: en la siguiente imagen, denotada por

la figura 4.32 se puede observar como el Administrador una vez
listado los ambientes existentes puede seleccionar el ambiente que
desea eliminar y ejecutar el botón para suprimir la tupla.
Figura 4.32. Pantalla Eliminar Ambiente.

99
Pantalla Cámaras de Seguridad: en la siguiente imagen,

denotada por la figura 4.33 se observa la forma en la que el
Administrador puede visualizar menú del DVR direccionado para
monitoreo de cámaras, esto después de ingresar la dirección de
DNS donde se puede acceder al equipo.
Figura 4.33. Pantalla Cámaras de Seguridad.

Pantalla Sensores: en la siguiente imagen, denotada por la figura

4.34, a la cual tiene acceso tanto el actor Administrador como el
Usuario se observa el comportamiento de los sensores de forma
graficas independientes.
100
Figura 4.34. Pantalla Sensores.

Pantalla Calendario: en la siguiente imagen, denotada por la

figura 4.35, a la cual tiene acceso tanto el actor Administrador
como el Usuario y la cual es un agregado opcional de la aplicación
se observa un amigable calendario con la opción de planificación
de eventos en los cuales el usuario puede crear su agenda
personalizada.
Figura 4.35. Pantalla Calendario.

101
Pantalla Configuración – Agregar Usuario: en la siguiente

imagen, denotada por la figura 4.36, se puede observar los campos
a los que tiene visibilidad el administrador al momento de ingresar
un nuevo usuario que podrá interactuar con el sistema.
Figura 4.36. Pantalla Configuración – Agregar Usuario.

Pantalla Configuración – Listar Usuarios: en la siguiente

imagen, denotada por la figura 4.37, se puede observar la lista de
los usuarios ingresados al sistema, así como la posibilidad de
imprimir tal listado.
Figura 4.37. Pantalla Configuración – Agregar Usuario.

102
4.3. FASE DE PRUEBAS.

Una vez integrados todos los módulos de la aplicación se procedió
a realizar las pruebas de cada unidad del sistema en las cuales se
tomaron en cuenta factores como validaciones de integridad, validaciones
en el tipo de información a ingresar, verificación del motor gráfico
utilizado, entre otros aspectos. Tales pruebas se dividieron en 3 tipos.
Pruebas de Validación, pruebas de integración y pruebas de
comunicación, las cuales se describen a continuación.
4.3.1. PRUEBAS DE INTEGRACION.

Para demostrar la integración de los distintos módulos
pertenecientes a la arquitectura del sistema SIUM se hicieron pruebas en
tiempo real para verificar, agregar y mostrar de forma gráfica en la
documentación del proyecto imágenes del funcionamiento del sistema
que muestran la interacción entre los sensores, la base de datos y la
aplicación web. A continuación, se muestran dichas imágenes.
Prueba de Integración – Sensor de Temperatura: la siguiente

imagen, denotada por la figura 4.38 se puede ver como el dato que
guarda la Variable “Sensor_temperatura” en la base de datos es de
25, por lo que en la página web del sistema SIUM en el Inicio el
sistema está mostrando una temperatura de 25° en la sala. Es
importante agregar que este valor guardado en la base de datos
está siendo procesado y enviado por el Microcontrolador gracias a
la captura de tal información del sensor, el cual fue sometido a un
ambiente controlado con la proximidad de la temperatura mostrada.
103
Figura 4.38. Prueba de Integración – Sensor de Temperatura.

Prueba de Integración – Sensor de Movimiento: la siguiente

imagen, denotada por la figura 4.39 se puede ver como el dato que
guarda la Variable “Sensor_movimiento” en la base de datos es de
0, lo que implicaría un ambiente sin detección de movimiento
alguno, por lo que en la página en la aplicación SIUM en la parte
de reportes se muestra “Sin detección”. Es importante agregar que
este valor guardado en la base de datos está siendo procesado y
enviado por el Microcontrolador gracias a la captura de tal
información del sensor de proximidad, el cual fue sometido a un
ambiente controlado.
104
Figura 4.39. Prueba de Integración – Sensor de Movimiento.

Prueba de Integración – Cámaras de Seguridad: la siguiente

imagen, denotada por la figura 4.40 se puede verificar la
integración del sistema con un módulo externo como lo es un DVR
encargado del monitoreo de cámaras de seguridad. Para ello se
debe ingresar el DNS que está configurado para este equipo en la
red como se muestra en la parte izquierda de la imagen y el
resultado se muestra del lado derecho, el cual no es más que la
interfaz que ofrece el dispositivo de monitoreo.
105
Figura 4.40. Prueba de Integración – Cámaras de Seguridad.

4.3.2. PRUEBAS DE VALIDACION.

Como parte importante de la fase de pruebas se testearon algunas
pantallas y campos importantes pertenecientes a la aplicación del sistema
SIUM, se hicieron pruebas en tiempo real para verificar, agregar y mostrar
de forma gráfica en la documentación del proyecto imágenes del
funcionamiento del sistema que muestran validaciones importantes al
momento de realizar una operación como, por ejemplo. Ingreso con clave
errónea a la aplicación, presionar botón de aceptar con campos vacíos,
entre otras. A continuación, se muestran dichas imágenes.
En la figura 4.41, se muestra una pantalla del sistema donde se

ingresaron datos incorrectos al momento de ingresar al sistema, se puede
evidenciar como se muestra un Modal con el mensaje “Error, el usuario o
contraseña no coinciden”. Esto de vital importancia para el sistema ya que
controla el flujo de entrada al sistema SIUM.
106
Figura 4.41. Prueba de Integración – Sensor de Movimiento.

Por otra parte, se puede evidenciar en las imágenes 4.42 y 4.43

como es el comportamiento del sistema para el caso de que se intente
enviar una información a la base de datos con algún campo vacío, para
este caso en particular se muestra el mensaje “Complete este campo”, en
el TextField donde se supone debería estar información importante para
realizar esta operación. Es importante agregar que esto funciona de forma
dinámica por lo que no es necesario que la aplicación redirección la
página para que el usuario sepa que le falto un campo de texto por llenar.
107
Figura 4.42. Prueba de Validación – Campos de texto (Log in).

Figura 4.43. Prueba de Validación –Campos de texto (Agregar Ambiente).

108
4.3.3. PRUEBA DE COMUNICACION.

En esta parte de la fase de pruebas se verificó la comunicación
efectiva entre los distintos dispositivos e instancias del sistema SIUM,
para ello se utilizó el método PING, el cual es una prueba que mide el
envío y recepción de paquetes de un equipo a otro. En la figura 4.44 se
muestra la ejecución de este comando hacia la dirección ip
192.268.0.101, la cual es la dirección asignada al Microcontrolador en la
red. Se puede notar como cada uno de los paquetes enviados llega a su
destino de forma efectiva y en un tiempo promedio de 197 ms, lo cual se
considera una velocidad optima de interacción. Además de esto se puede
observar la Figura 4.45, donde de se muestra el resultado físico de una
operación realizada en la aplicación, la salida de esta operación puede
evidenciar en la parte izquierda de la imagen que denota la maquetación
del sistema de control inmerso en SIUM. Es importante destacar que el
comando PING es ejecutado desde el servidor el cual tiene una dirección
ip asignada 192.168.0.100 y se comunica con el controlador por medio del
Router. Por lo que se concluye que la comunicación entre los distintos
equipos del sistema está establecida.
Figura 4.44. Prueba de Comunicación.

109
Figura 4.45. Prueba de Comunicación, Pagina Web-PhpMyAdmin-

Arduino.
4.3.4. MAQUETADO DE SENSORES Y SALON DE PRUEBA DE SIUM.

En esta parte de la fase de pruebas se especifica el maquetado
donde se encuentra implementado el sistema sium con los respectivos
sensores y actuadores.
LEYENDA:
Sensores: Temperatura, Humedad,

Movimiento, Aproximación
Cámaras de Seguridad
Sistema De Control Del Sistema

SIUM.
Figura 4.46. MAQUETADO SALA SIUM .

110
CONCLUSIONES
Una vez cumplidas en su totalidad con todas las fases del proceso
de la metodología ROPES, implantado para la construcción del sistema
de control denominado SIUM, basado en un sistema empotrado para el
manejo inteligente de tareas, ambientes y gestión de energía en una sala
determinada. Se puede concluir lo siguiente:
Se comprobó que la Metodología empleada (ROPES), ofrece los

recursos necesarios para desarrollar de forma óptima y a prueba de fallas
cualquier problema propuesto en el área de sistemas de control y
sistemas embebidos. La misma ofrece una gama tan completa como
compleja de artefactos que permiten crear cualquier instancia que se
necesite a un problema dado.
Se denoto cuan efectivos son los artefactos apoyados en UML para

la identificación de los requisitos en las fases iniciales del proyecto ya que
se pudieron identificar de forma clara en un principio y sin cambios
inesperados a medida que se desarrollaba el proyecto.
Se pudo observar que, a diferencia de simples proyectos de

software, al diseñar y crear arquitecturas de sistemas de control, es
indispensable hacer constantes pruebas de comunicación que garanticen
la fiabilidad de los datos que se están capturando en todo momento.
También se puede destacar el hecho de que para sistemas

empotrados es de vital importancia en la fase de traducción realizar los
mecanismos que garanticen la integración de la arquitectura (Hardware -
Software) ya que ambos tienen una relación de vida, “Uno no sobrevive
sin el otro”. O, dicho de otra manera, ambas partes son prácticamente
inútiles sin la presencia de su contra parte.
111
Se comprobó la factibilidad del uso de librerías preestablecidas

para el manejo de módulos de sensores. Esto ya que se usaron librerías
Arduino previamente implementadas las cuales se adaptaron
perfectamente al problema propuesto.
Se pudo observar la efectividad que puede ofrecer la metodología

utilizada para abordar problemas propuestos en el área de sistemas de
control y ofrece todos los mecanismos necesarios para adaptarse y
describir cualquier submoludo en la aplicación, así como ofrecer la
posibilidad de futuras ampliaciones al sistema.
Por último, se pudo comprobar la efectividad de la documentación

obtenida ya que en los recursos ofrecidos en la fase de pruebas por la
metodología se logró comprobar el funcionamiento integral del sistema
SIUM, tanto a nivel de Software como de Hardware.
112
RECOMENDACIONES
Se recomienda que el sistema SIUM sea más que un proyecto de

tesis de grado sea una aplicación abierta a futuras ampliaciones o
mejoras donde se pueda adaptar a las necesidades de los usuarios que
hagan uso de la sala donde dicho sistema este implementada. Ya que al
fin y al cabo esta usa tecnologías vinculadas a la domótica, la cual busca
factores como bienestar, seguridad y comodidad para las personas.
Incentivar a las autoridades competentes a la implantación de este

sistema en las distintas escuelas que componen la Universidad de Oriente
- Núcleo Anzoátegui, así como también los diferentes núcleos de esta
universidad.
Impulsar a los estudiantes el desarrollo de nuevos sistemas

Domóticos dirigidos a valiosas ares áreas de aplicación tales como:
ahorro energético, confort, comunicaciones, entre otras, difundiendo las
capacidades y los beneficios de esta tecnología.
Inspirar a otras universidades a profundizar en el estudio de la

Domótica orientado a la Seguridad, confort, ahorro de energía y la
protección de los bienes.
Promover iniciativas donde el departamento de Computación y

sistemas gestione la apertura de asignaturas electivas vinculadas a esta
área de estudio o cree nuevas áreas donde se evalúen tópicos referentes
a tecnologías como la Domótica la cual representa una solución futurista a
muchas problemáticas de la sociedad actual.
113
BIBLIOGRAFÍA
Aguilar, J. (2000). Fundamentos de la programación, Editorial

McGTraw – Hill. Madrid, España.
Alan Steventon, Steve Wright. (2010). Intelligent Spaces: The

Application of Pervasive ICT, Springer-Verlag, Reino Unido.
Álvarez, R. (2010). Modelo para determinar la capacidad de

Cómputo intensivo requerida en el procesamiento sísmico como
herramienta de planificación en PDVSA. Trabajo de Grado de
Maestría.
Arias F. (1999). El Proyecto de investigación, Editorial Episme,

Caracas, Venezuela.
Bastidas, N. (2008). Desarrollo de un sistema de redes

inalámbricas de alta capacidad (RIDAC) para los servicios de voz,
datos en los taladros de producción de PDVSA Gas Anaco.
Booch, G. Rumbaugh, J. Jacobson, I. (2007). Lenguaje Unificado

de Modelado (UML). Editorial Pearson (2da edición).
Buonaffina, R. (2009). Diseño de la red de soporte para la

transmisión de datos gerenciales en el núcleo Nueva Esparta de la
Universidad de Oriente campus Guatamare.
CEDOM. Asociación Española de Domótica. “Instalaciones

Domóticas, cuaderno de buenas prácticas para promotores y
constructores”. AENOR Ediciones.
114
Gutiérrez, G. (1991). Metodología de las ciencias sociales, Editorial

Harpe & Row Latinoamericana, Mérida. México.
Hernández, R. (2004). Metodología de la investigación, Editorial

McGTraw – Hill.
IEEE 1471 (2000). Documento de Arquitectura de Software.
Jiménez, C. (1983): “Población y muestra. El muestreo”. Pedagogía

Experimental II. Tomo I. UNED. Madrid.
Loja, M. (2013). Estudio y diseño inmotico para el edificio de

biblioteca de la Universidad Politécnica Salesiana sede Cuenca,
implementando la tecnología KONNEX (KNX) para el control de
iluminación, control de accesos y control de seguridad técnica.
Cuenca, Ecuador.
Londoño N. (2009). Una propuesta metodológica para el desarrollo

de Arquitecturas de Software para Robots (MDASR), Medellín
Colombia.
Marcano, D. (2009). Diseño de una plataforma de voz sobre IP,

para minimizar costos telefónicos, incrementar la capacidad de
comunicación y facilitar los procesos de intercambio de información
entre la administración central del Banco Confederado S. A.
Pressman Roger, S. (2007). Ingeniería del Software, un enfoque

práctico, Mc Graw Hill (Sexta Edición). Universidad de Connecticut
EE.UU.
115
Páginas Web.
Casadomo – Todo Sobre La Domótica (2014). [Página web en

línea]. Disponible en: http://www.casadomo.com
Laboratorio de docentes de computación (2014). [Página web en

línea]. Disponible en: http://ldc.usb.ve/
Arduino web – Oficial (2015). [Página web en línea]. Disponible en:

http://www.arduino.cc/

Desarrollo de una sala inteligente con sistema de control domótico en la Universidad de Oriente

Cargado por

Información del documento

Descripción original:

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

Desarrollo de una sala inteligente con sistema de control domótico en la Universidad de Oriente

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE ORIENTE

“DESARROLLO DE UNA SALA INTELIGENTE CON SISTEMA

Trabajo de grado presentado en la Universidad de Oriente como requisito

Barcelona, NOVIEMBRE 2016

“DESARROLLO DE UNA SALA INTELIGENTE CON SISTEMA

Ing. Pedro Dorta

Barcelona, NOVIEMBRE 2016

“DESARROLLO DE UNA SALA INTELIGENTE CON SISTEMA

Ing. Pedro Dorta

Ing. Víctor Mujica Ing. Stefano Larese

Barcelona, NOVIEMBRE 2016

De acuerdo al artículo 44 del reglamento de trabajos de grado de la

“Los trabajos de grado son de exclusiva propiedad de la

A mis amados padres Ing. Saúl Zambrano y Lcda. Zenaida peche

A mis hermanos por contribuir en mi desarrollo como persona, por

José Saúl Zambrano Peche

Agradezco a Dios por estar presente y bendecir cada proyecto que

A Zenaida Peche por ser la mejor Madre, pero también el mejor

A mi amado Padre, porque pese a que el destino te saco de mi vida

A mis abuelos María Angélica, José Aníbal, “Don Martin” y Enma.

A mis hermanos Jaime, chino, María, Enma, Elsi y Wilfredo. Porque

A mis hermanos de la vida Miguel, Hilaria, Cesar, Jordán y Mejías

A Zuleimi Gómez, por apoyarme de forma incondicional en cada

Agradezco mucho a mis tíos como Rodolfo, Mondinga, Luis,

A mis primos hermanos, Gerardo, Petete, Coro, Pilon, entre otros a

A mi compañero de tesis y por obras del destino también mi

A mi tutor Pedro Dorta por otorgarme parte de sus conocimientos

A mis socios en materia de trabajo Tato y Andrés por estar en

A mis eternos compañeros del Coro Universitario entre los cuales

A mis compañeros de carrera. Mariam, Fanny, Félix, Valentina,

Por ultimo agradezco profundamente a todos mis familiares,

José Saúl Zambrano Peche

A mi madre Lcda. Enma Zambrano, Por haberme apoyado en todo

A mi padre Lcdo. Julio Carao, Por los ejemplos de perseverancia y

A mis familiares, mi hermana Arianna Valentina por ser el ejemplo de

Julio Cesar Carao Zambrano

A Dios Todopoderoso, te doy gracias a ti padre por darme la

A mi Novia Lcda. Yeniree Rojas que es mi fuente de cariño, apoyo,

A mi asesor Ing. Pedro Dorta, por tenerme tanta paciencia y

A la Universidad de Oriente por haber sido escalón para un sueño

A todos mis profesores, gracias por impartir sus conocimientos

A mis amigos, por ese apoyo en mi formación profesional y que

Julio Cesar Carao Zambrano

CAPITULO II - MARCO TEORICO. 22

CAPÍTULO III - MARCO METODOLÓGICO. 41

3.1. TIPO DE INVESTIGACIÓN.....................................................................41

4.1. FASE DE ANALISIS.......................................................................45

Tabla 2.1. Características comunes entre la domótica e inmótica

Tabla 2.2. Ventajas de Arduino (Arduino WEB Oficial 2015

Tabla 4.1. Actores del sistema. (Fuente: Elaboración propia)...................49

Tabla 4.2. Identificación de los casos de uso (Fuente: Elaboración propia).

La domótica es la automatización y control centralizado y/o remoto

El concepto domótica se refiere a la automatización y control

Se propone la implementación de una sala inteligente con sistema

Actualmente la Universidad de Oriente núcleo Anzoátegui no

Los objetivos de este proyecto serán: Estudiar la situación actual,

Hoy en día, disponer de un ambiente capaz de ofrecer el confort y

Es de conocimiento general que los espacios con estas

El proyecto saber es una entidad que, a través de los años, debido

Por esta razón es necesaria la creación de una sala moderna que

El desarrollo de esta investigación en su primera fase busca una

La misión de este proyecto será desarrollar una sala “piloto” que