Tesis Final

INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA
UNIDAD PROFESIONAL “ADOLFO LÓPEZ MATEOS” ZACATENCO
SISTEMA DE CONTROL Y MONITOREO REMOTO PARA UNA GRANJA DE

AVES DE PRODUCCIÓN
SEMINARIO
PARA OBETENER EL TÍTULO DE:
INGENIERO EN COMUNICACIONES Y ELECTRÓNICA
PRESENTAN:
ARMANDO HERNÁNDEZ BALDERAS

HÉCTOR FRANCISCO MANDUJANO DURÁN
HÉCTOR DANIEL ROJAS ALMAZAN
ASESOR:
M. EN C. JOSÉ ERNESTO ROJAS LIMA

ING. FRANCISCO HERNÁNDEZ RANGEL
México, CDMX Agosto, 2018

Índice
CAPÍTULO I Conceptos Fundamentales de Redes……………………………………………………………….1
1.1 Protocolos, topologías y servicios………………………………………………………………………...........1
1.1.1 Protocolo de comunicación……………………………………………………………………........1
1.1.2 Topología y medios compartidos.............................................................................................1
1.1.3 Relación entre Servicios y Protocolos.....................................................................................1
1.1.4 Modelos de Referencia............................................................................................................2
1.2 El Modelo OSI...........................................................................................................................................2
1.2.1 Capas Física y Enlace.............................................................................................................4
1.2.2 Capas de Red y Transporte.....................................................................................................6
1.2.3 Capas de Sesión, Presentación y Aplicación...........................................................................6
1.3 El modelo TCP/IP......................................................................................................................................9
1.3.1 Capas Física y Red................................................................................................................10
1.3.2 Capas de Internet y Transporte..............................................................................................10
1.3.3 Capa de Aplicación.................................................................................................................10
1.4 Familia de protocolos TCP/IP..................................................................................................................11
1.4.1 Protocolo de Control de Transmisión.....................................................................................11
1.4.2 Protocolo IP............................................................................................................................12
1.4.2.1 Funciones de IP.....................................................................................................15
1.4.3 Suma de verificación (Checksum)..........................................................................................15
1.4.4 Protocolo UDP........................................................................................................................15
1.4.5 Direccionamiento IP................................................................................................................16
1.5 Protocolo DNS.........................................................................................................................................16
1.5.1 Espacio de Nombres de Dominio...........................................................................................17
1.6 Arquitectura DMZ.....................................................................................................................................18
1.7 Socket......................................................................................................................................................20
1.7.1 Definición de un Socket..........................................................................................................20
CAPITULO II Requerimientos de Hardware, dispositivos de estado sólido y herramientas de programación...22
2.1 Herramientas de programación...............................................................................................................22
2.1.1 Sistema Operativo ANDROID................................................................................................22
2.1.2 Java........................................................................................................................................23
2.1.3 Introducción al desarrollo de aplicaciones en Android Studio................................................25
2.1.3.1 App Manifest.........................................................................................................29
2.1.3.2 Construyendo una App con Android Studio..........................................................30

2.1.4 Python....................................................................................................................................31
2.1.4.1 Lenguaje interpretado ó de script.........................................................................31
2.1.4.2 Transmisión de Datos...........................................................................................31
2.1.5 Servicio no – IP......................................................................................................................32
2.1.5.1 Dyn DNS...............................................................................................................32
2.2 Requerimientos de Hardware..................................................................................................................33
2.2.1 Raspberry Pi...........................................................................................................................33
2.2.2 Microcontrolador MSP430G2553...........................................................................................34
2.2.3 UART......................................................................................................................................35
2.2.4 Modulación por ancho de pulsos (PWM)................................................................................35
2.2.5 Arduino UNO..........................................................................................................................37
2.3 Dispositivos.............................................................................................................................................38
2.3.1 Sensor de temperatura y humedad relativa DHT22...............................................................38
2.3.2 Sensor de luminosidad BH1750.............................................................................................42
2.3.3 MOSFET IRF540....................................................................................................................43
CAPITULO III Arquitectura general del sistema y desarrollo…………………………………………………....45
3.1 App de Control y Monitoreo……………………………………………………………………………….46
3.2 Configuración DNS…………………………………………………………………………………………51
3.3 Configuración de la DMZ…………………………………………………………………………………..52
3.4 Integración de Arduino y el sensor de BH1750………………………………………………………....53
3.5 Integración del MSP430G2553…………………………………………………………………………...55
3.6 Etapa de Potencia……………………………………………………………………………………….....57
3.7 Integración Del Servidor Raspberry Pi…………………………………………………………………...58
3.8 Instalación del sistema………………………………………………………………………………….....62
CAPITULO IV Pruebas realizadas, resultados y costos………………………………………………………....65
4.1 Interfaz de la App finalizada……………………………………………………………………………....65
4.3 Tabla de costos………………………………………………………………………………………….....70
CONCLUSIONES………………………………………………………………………………………………….....71
BIBLIOGRAFIA…………………………………………………………………………………………………….....72
GLOSARIO....................................................................................................................................................73
ANEXO A.......................................................................................................................................................74
ANEXO B.......................................................................................................................................................75
ANEXO C.......................................................................................................................................................77
INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA
UNIDAD PROFESIONAL “ADOLFO LÓPEZ MATEOS” ZACATENCO
SISTEMA DE CONTROL Y MONITOREO REMOTO PARA UNA GRANJA DE

AVES DE PRODUCCIÓN
SEMINARIO
PARA OBETENER EL TÍTULO DE:
INGENIERO EN COMUNICACIONES Y ELECTRÓNICA
PRESENTAN:
ARMANDO HERNÁNDEZ BALDERAS

HÉCTOR FRANCISCO MANDUJANO DURÁN
HÉCTOR DANIEL ROJAS ALMAZAN
ASESOR:
M. EN C. JOSÉ ERNESTO ROJAS LIMA

ING. FRANCISCO HERNÁNDEZ RANGEL
México, CDMX Agosto, 2018

Introducción
Los programas de iluminación son ampliamente utilizados en la avicultura

industrial para mejorar algunos parámetros productivos de las aves domésticas
como lo son la gallina productora de huevo, la gallina reproductora y el pollo de
engorda principalmente.
Estos programas se consideran un manejo importante esencialmente para las
gallinas ponedoras y reproductoras en las etapas de crianza y producción, ya que
la luz estimula ciertas conexiones neuro-hormonales que desencadenan la
producción de huevos, lo cual es indicativo de que se ha alcanzado la madurez
sexual, la cual se da regularmente entre la semana 18 y la semana 20 de vida del
ave.
Al ser la iluminación un factor determinante en el medio ambiente de las aves, se
puede manipular de forma que se logre la adecuada expresión del potencial
genético y así mejorar algunos parámetros tales como: el consumo de
alimento/ave/día, la conversión alimenticia, el porcentaje de postura, el peso
promedio del huevo, la masa del huevo y la ganancia diaria de peso.
Cuando se aplica un mal programa de iluminación sobre estimulando al ave, se
acelera el desarrollo sexual provocando que la gallina detenga su crecimiento
corporal y utilice sus nutrientes para la formación de huevos, lo cual ocasiona
huevos chicos, un ciclo de producción corto y un pico de producción bajo, además
de que al no desarrollarse bien el cuerpo del ave se incrementan los problemas de
prolapsos de cloaca y por lo tanto aumenta el porcentaje de mortalidad y las
pérdidas económicas.
En el caso de las gallinas ponedoras se requiere que la madurez sexual se retrase
para que el ciclo de producción sea mayor y con mayores tamaños de huevo. Esto
se logra aplicando un correcto programa de iluminación de disminución
escalonada en combinación con otro de incremento escalonado, tomando en
cuenta la época en que nacen y a la que llegan a la madurez sexual.
El programa de iluminación se inicia desde el primer día en que el ave llega a la
caseta de crianza, y las horas de luz artificial que se le aplicarán adicionales a la
luz natural, dependerá de las horas de luz que haya en la época en la que nazcan
y en la que vayan a llegar a la madurez sexual.
El programa debe realizarse tomando en cuenta que no se deberá dar más de 22
horas de luz al día al inicio de la crianza, para después ir disminuyendo 15-20
minutos de luz artificial semanalmente hasta llegar a la semana en la que se
espera que se dé la madurez sexual, únicamente con luz natural como fuente de
iluminación, luego se tendrá que ir aumentando de 15-20 minutos semanalmente
i
hasta llegar a un máximo 17 horas luz al día, las cuales se mantendrán constantes
hasta el final de su vida productiva.
Además de la luz, otros factores importantes para un buen porcentaje de
producción es la medición de la temperatura y la humedad relativa, ya que dan la
pauta para saber si las aves están dentro de su ambiente de confort, lo que se
traduce como bienestar animal que a su vez nos da buenos resultados
productivos.
La temperatura dentro de la caseta es algo importante que si se puede, se debe
medir, ya que si la temperatura es muy alta, las aves comenzarán a jadear, se
echarán y bajarán su consumo de alimento, y si por el contrario la temperatura es
muy baja, las aves aumentarán su consumo de alimento y también permanecerán
echadas para no disipar su calor corporal, en ambos casos las aves ocuparán sus
nutrientes y energía para su termorregulación en lugar de ocuparlos para la
producción de huevo y/o carne.
ii
Objetivo
Implementar un sistema para controlar la luminosidad y monitorear la temperatura

y humedad relativa de forma remota, para su aplicación en una granja de aves de
producción.
iii
Justificación
Se pensó en este proyecto porque México es líder mundial en consumo de huevo

sin embargo no lo es así en la producción del mismo, ya que estamos ubicados en
el 4to sitio, por tal motivo se decide atacar esa problemática mediante este
proyecto, buscando aplicar la técnica para construir en combinación con los
dispositivos móviles y la teoría de las comunicaciones, un sistema innovador de
bajo costo, que permita a los productores del sector avícola tener un instrumento
de control y monitoreo a tanta distancia como lo permita la gran red de internet y
las tecnologías de la información, además de aportar al abastecimiento de la
demanda que se genera en el país, lo que evitará a medida de lo que sea posible
la importación de este producto y fomentará el consumo interno, esto beneficiará
al sector primario y por ende a los productores nacionales contribuyendo a la
economía del país.
iv
Índice
CAPÍTULO I Conceptos Fundamentales de Redes……………………………………………………………….1
1.1 Protocolos, topologías y servicios………………………………………………………………………...........1
1.1.1 Protocolo de comunicación……………………………………………………………………........1
1.1.2 Topología y medios compartidos.............................................................................................1
1.1.3 Relación entre Servicios y Protocolos.....................................................................................1
1.1.4 Modelos de Referencia............................................................................................................2
1.2 El Modelo OSI...........................................................................................................................................2
1.2.1 Capas Física y Enlace.............................................................................................................4
1.2.2 Capas de Red y Transporte.....................................................................................................6
1.2.3 Capas de Sesión, Presentación y Aplicación...........................................................................6
1.3 El modelo TCP/IP......................................................................................................................................9
1.3.1 Capas Física y Red................................................................................................................10
1.3.2 Capas de Internet y Transporte..............................................................................................10
1.3.3 Capa de Aplicación.................................................................................................................10
1.4 Familia de protocolos TCP/IP..................................................................................................................11
1.4.1 Protocolo de Control de Transmisión.....................................................................................11
1.4.2 Protocolo IP............................................................................................................................12
1.4.2.1 Funciones de IP.....................................................................................................15
1.4.3 Suma de verificación (Checksum)..........................................................................................15
1.4.4 Protocolo UDP........................................................................................................................15
1.4.5 Direccionamiento IP................................................................................................................16
1.5 Protocolo DNS.........................................................................................................................................16
1.5.1 Espacio de Nombres de Dominio...........................................................................................17
1.6 Arquitectura DMZ.....................................................................................................................................18
1.7 Socket......................................................................................................................................................20
1.7.1 Definición de un Socket..........................................................................................................20
CAPITULO II Requerimientos de Hardware, dispositivos de estado sólido y herramientas de programación...22
2.1 Herramientas de programación...............................................................................................................22
2.1.1 Sistema Operativo ANDROID................................................................................................22
2.1.2 Java........................................................................................................................................23
2.1.3 Introducción al desarrollo de aplicaciones en Android Studio................................................25
2.1.3.1 App Manifest.........................................................................................................29
2.1.3.2 Construyendo una App con Android Studio..........................................................30
v
2.1.4 Python....................................................................................................................................31
2.1.4.1 Lenguaje interpretado ó de script.........................................................................31
2.1.4.2 Transmisión de Datos...........................................................................................31
2.1.5 Servicio no – IP......................................................................................................................32
2.1.5.1 Dyn DNS...............................................................................................................32
2.2 Requerimientos de Hardware..................................................................................................................33
2.2.1 Raspberry Pi...........................................................................................................................33
2.2.2 Microcontrolador MSP430G2553...........................................................................................34
2.2.3 UART......................................................................................................................................35
2.2.4 Modulación por ancho de pulsos (PWM)................................................................................35
2.2.5 Arduino UNO..........................................................................................................................37
2.3 Dispositivos.............................................................................................................................................38
2.3.1 Sensor de temperatura y humedad relativa DHT22...............................................................38
2.3.2 Sensor de luminosidad BH1750.............................................................................................42
2.3.3 MOSFET IRF540....................................................................................................................43
CAPITULO III Arquitectura general del sistema y desarrollo…………………………………………………....45
3.1 App de Control y Monitoreo……………………………………………………………………………….46
3.2 Configuración DNS…………………………………………………………………………………………51
3.3 Configuración de la DMZ…………………………………………………………………………………..52
3.4 Integración de Arduino y el sensor de BH1750………………………………………………………....53
3.5 Integración del MSP430G2553…………………………………………………………………………...55
3.7 Integración Del Servidor Raspberry Pi…………………………………………………………………...58
3.8 Instalación del sistema………………………………………………………………………………….....62
CAPITULO IV Pruebas realizadas, resultados y costos………………………………………………………....65
4.1 Interfaz de la App finalizada……………………………………………………………………………....65
4.3 Tabla de costos………………………………………………………………………………………….....70
CONCLUSIONES………………………………………………………………………………………………….....71
BIBLIOGRAFIA…………………………………………………………………………………………………….....72
GLOSARIO....................................................................................................................................................73
vi
ANEXO A.......................................................................................................................................................74
ANEXO B.......................................................................................................................................................75
ANEXO C.......................................................................................................................................................77
vii
Capítulo 1. Conceptos Fundamentales de Redes
Capítulo 1: Conceptos fundamentales de Redes
1.1 Protocolos, topologías y servicios
El objetivo de una red de comunicación no está relacionado con el contenido de

los datos intercambiados entre estaciones, su propósito es simplemente mover
datos desde una estación fuente hacia un destino. Sin embargo, la red de
comunicaciones debe de servir al transporte de aplicaciones con requerimientos
específicos, que se logra por medio de las diferentes topologías en conjunción de
los servicios y los protocolos que estos utilicen.
1.1.1 Protocolo de comunicación
Las máquinas se comunican empleando convenciones establecidas llamadas

protocolos. Puesto que los sistemas de computadora ofrecen muchas funciones a
los usuarios, se requiere más de un protocolo para apoyar estas funciones [1]. Un
protocolo es un conjunto de reglas y convenciones que gobierna el modo en que
las computadoras intercambian información por un medio de transmisión de red
[2]. Los protocolos existen a diferentes niveles de conexiones. Por ejemplo, el
protocolo de enlace de datos es una especificación de métodos por los que la
comunicación de datos en un enlace se ejecuta en términos de la forma particular
del modo de transmisión, la forma de control y los procedimientos de recuperación
[3].
1.1.2 Topología y medios compartidos
Indirectamente, el tipo de conexión que se haga en la capa física puede influir en

el diseño de la capa de Enlace. Atendiendo al número de equipos que comparten
un medio hay dos posibilidades:
-Conexiones punto a punto: que se establecen entre dos equipos y que no

admiten ser compartidas por terceros.
-Conexiones multipunto: en la que más de dos equipos pueden usar el medio.
Así por ejemplo la fibra óptica no permite fácilmente conexiones multipunto y por el
contrario las conexiones inalámbricas son inherentemente multipunto. Hay
topologías como el anillo, que permiten conectar muchas máquinas a partir de una
serie de conexiones punto a punto.
1.1.3. Relación entre Servicios y Protocolos
Los servicios y los protocolos son conceptos distintos, aunque con frecuencia se
les confunde. Un servicio es un conjunto de (operaciones) primitivas que ofrece
una capa a la que está por encima de ella. El servicio define cuáles son las
1
operaciones que la capa está preparada para ejecutar en beneficio de sus

usuarios, indicando cómo se van a instrumentar estas operaciones.
En contraste, un protocolo es un conjunto de reglas que gobiernan el formato y el

significado de las tramas, paquetes o mensajes que se intercambian entre las
entidades pares dentro de una capa. Las entidades usan protocolos con el fin de
instrumentar sus definiciones de servicios; son libres de cambiar sus protocolos a
voluntad, siempre que no cambien el servicio visible a sus usuarios, de esta
manera el servicio y el protocolo están desacoplados por completo [4], [3].
1.1.4. Modelos de Referencia
Los modelos de referencia de una red conceptualizan el funcionamiento de los

diferentes protocolos de comunicación y las capas que forman una arquitectura
que relacionan de forma interna los distintos programas y equipos. Las dos
arquitecturas importantes de red son: El modelo de referencia OSI y el modelo de
referencia TCP/IP [3], [4].
1.2 El Modelo OSI
OSI (Interconexión de Sistemas Abiertos), conocido como modelo de referencia

OSI, describe como se transfiere la información desde una aplicación de software
en una computadora a través del medio de transmisión, hasta una aplicación de
software de otra computadora. OSI es un modelo conceptual compuesto de siete
capas; en cada una de ellas se especifican funciones de red particulares. Fue
desarrollado por la ISO (Organización Internacional de Estándares) en 1984 y
actualmente se considera el modelo principal de arquitectura para la comunicación
entre computadoras. OSI divide las funciones implicadas en la transferencia de
información entre computadoras de red, en siete grupos de tareas más pequeñas
y fáciles de manejar. A cada una de las siete capas se le asigna una tarea o grupo
de tareas. Cada capa es razonablemente individual, por lo que las tareas
asignadas a cada una de las capas se pueden implementar de manera
independiente. Esto permite que soluciones ofrecidas por una capa se puedan
actualizar sin afectar a las demás [1], [2], [3], [4]. La figura 1.1 siguiente detalla las
siete capas del modelo OSI:
2
Figura 1.1 Ilustra el modelo de referencia OSI de siete capas
Siguiendo el esquema de este modelo se crearon numerosos protocolos. El

advenimiento de protocolos más flexibles donde las capas no están tan
demarcadas y la correspondencia con los niveles no era tan clara, puso a este
esquema en un segundo plano. Sin embargo, sigue siendo muy usado en la
enseñanza como una manera de mostrar cómo puede estructurarse una pila de
protocolos de comunicaciones (sin importar su poca correspondencia con la
realidad). El modelo en sí mismo no puede ser considerado una arquitectura, ya
que no especifica el protocolo que debe ser usado en cada capa, sino que suele
hablarse de modelo de referencia [2]. En el modelo OSI el propósito de cada capa
es proveer los servicios para la siguiente capa superior, resguardando la capa de
los detalles de, cómo los servicios son implementados realmente. Las capas son
abstraídas de tal manera que cada capa cree que se está comunicando con la
capa asociada en la otra computadora, cuando realmente cada capa se comunica
sólo con las capas adyacentes de la misma computadora. A continuación, en la
figura 1.2 se muestra la comunicación entre dos Host.
3
Figura 1.2 Comunicación entre dos Host con el modelo OSI
La arquitectura del OSI consta de siete niveles o capas en las que se especifican
de la siguiente manera:
1.2.1 Capas Física y Enlace
La capa física tiene que ver con la transmisión de bits por un canal de
comunicación. Define las especificaciones eléctricas, mecánicas, de
procedimientos funcionales para activar, mantener y desactivar el enlace físico
entre sistemas de redes de comunicaciones [4]. Las especificaciones de la capa
física definen características como niveles de voltaje, temporización de cambios
de voltaje, velocidades de transferencia de información, distancias máximas de
transmisión y conectores físicos [2]. Sus principales funciones se pueden resumir
como:
- Definir el medio o medios físicos por los que va a viajar la comunicación:

cable de pares trenzados, coaxial, guías de onda, aire, fibra óptica.
- Definir las características materiales (componentes y conectores
mecánicos) y eléctricas (niveles de tensión) que se van a usar en la
transmisión de los datos por los medios físicos.
- Definir las características funcionales de la interfaz (establecimiento,
mantenimiento y liberación del enlace físico). Transmitir el flujo de bits a
través del medio.
- Manejar las señales eléctricas/electromagnéticas.
- Especificar cables, conectores y componentes de interfaz con el medio
de transmisión, polos en un enchufe, etc.
- Garantizar la conexión (aunque no la fiabilidad de ésta).
4
La capa de enlace de datos proporciona el transito confiable de datos a través del

enlace de red. Diferentes especificaciones de la capa de enlace de datos definen
diferentes características de red y protocolo, incluyendo el direccionamiento físico,
la topología de red, la notificación de error, la secuencia de tramas y el control de
flujo [2]. Se encarga de transformar la línea de transmisión común en una línea sin
errores para la capa de red, esto se lleva a cabo dividiendo la entrada de datos en
tramas de asentimiento, por otro lado, se incluye un patrón de bits entre las tramas
de datos. Esta capa también se encarga de solucionar los problemas de reenvío, o
mensajes duplicados cuando hay destrucción de tramas. Por otro lado, es
necesario controlar el tráfico [4]. Un grave problema que se debe controlar es la
transmisión bidireccional de datos. El tema principal son los algoritmos para la
comunicación confiable y eficiente entre dos máquinas adyacentes. El nivel de
enlace trata de detectar y corregir los errores. Normalmente se parte el flujo de bits
en marcos y se calcula un checksum (comprobación de datos) para cada uno. Las
tramas contendrán información como:
- Número de caracteres (un campo del encabezamiento guarda el número.

Pero si el número es cambiado en una transmisión, es difícil recuperar.)
- Caracteres de inicio y fin.
Servicios para el nivel de red
Servicio sin acuses de recibo. La máquina de fuente manda tramas al destino. Es

apropiado si la frecuencia de errores es muy baja o el tráfico es de tiempo real (por
ejemplo, voz). Servicio con acuses de recibo. El recibidor manda un acuse de
recibo al remitente para cada trama recibida.
Control de flujo
Se usan protocolos que prohíben que el remitente pueda enviar tramas sin la
permisión implícita o explícita del recibidor. Por ejemplo, el remitente puede
mandar un número indeterminado de tramas, pero entonces tiene que esperar.
LLC y MAC
El IEEE (Instituto de Ingenieros en Electrónica y Electricidad) ha subdividido la

capa de enlace de datos en dos subcapas: LLC (Control de Enlace de Datos) y
MAC (Control de Acceso a Medios).
La subcapa LLC de la capa de enlace de datos administra las comunicaciones
entre dispositivos unidos por un enlace individual de red. La subcapa LLC está
definida en la especificación IEEE 802.2 y soporta los servicios orientados a la
conexión, utilizados por los protocolos de las capas superiores. El IEEE 802.2
define varios campos en las tramas de la capa de enlace de datos que permiten
que varios protocolos de las capas superiores compartan un solo enlace físico de
datos. La subcapa MAC de la capa de enlace de datos administra el protocolo de
acceso al medio de trasmisión físico de la red. La especificación IEEE MAC define
5
las direcciones MAC, las cuales permiten a múltiples dispositivos identificarse de

manera única entre sí en la capa de enlace datos [2].
1.2.2 Capas de Red y Transporte
Esta capa proporciona el ruteo y funciones relacionadas que permiten a múltiples

enlaces de datos combinarse en una red [2]. El cometido de la capa de red es
hacer que los datos lleguen desde el origen al destino, aun cuando ambos no
estén conectados directamente (direccionamiento lógico). Los dispositivos que
facilitan tal tarea se denominan en castellano como encaminadores, aunque es
más frecuente encontrar el nombre inglés routers y, en ocasiones enrutadores.
Si en la subred se encuentran presentes demasiados paquetes a la vez, se

estorbarán mutuamente, formando cuellos de botella. El control de tal gestión
pertenece también a la capa de red [4]. La PDU (Unidad de Datos de Protocolo)
de la capa 3 es el paquete. Los firewalls actúan sobre esta capa principalmente,
para descartar direcciones de máquinas.
La capa de transporte implementa servicios confiables de datos entre redes,

transparentes a las capas superiores. Entre las funciones habituales de la capa de
transporte se cuentan el control de flujo, el multiplexaje, la administración de
circuitos virtuales y la verificación y recuperación de errores [2].
La función básica de la capa de transporte es aceptar datos, dividirlos en unidades

más pequeñas si es necesario, pasarlos a la capa de red y asegurar que todos los
pedazos lleguen correctamente al otro extremo [4]. El tamaño de los paquetes lo
dicta la arquitectura de red que se utilice. Los protocolos más importantes a este
nivel son TCP y UDP Protocolo de Datagrama de Usuario (mutuamente
excluyentes). En esta capa se proveen servicios de conexión para la capa de
sesión que serán utilizados finalmente por los usuarios de la red al enviar y recibir
paquetes. Estos servicios estarán asociados al tipo de comunicación empleada, la
cual puede ser diferente según el requerimiento que se le haga a la capa de
transporte.
1.2.3 Capas de Sesión, Presentación y Aplicación
Establece, administra y finaliza las sesiones de comunicación entre las entidades

de la capa de presentación. Las sesiones de comunicación constan de solicitudes
y respuestas de servicio que se presentan entre aplicaciones ubicadas en
diferentes dispositivos de red. Estas solicitudes y respuestas están coordinadas
por protocolos de la capa de sesión [2], [4]. Ofrece varios servicios que son
cruciales para la comunicación, como son:
 Control de la sesión a establecer entre el emisor y el receptor (quién

transmite, quién escucha y seguimiento de ésta).
6
 Control de la concurrencia (que dos comunicaciones a la misma operación

crítica no se efectúen al mismo tiempo).
Mantener puntos de verificación (checkpoints), que sirven para que, ante una
interrupción de transmisión por cualquier causa, la misma se pueda reanudar
desde el último punto de verificación en lugar de repetirla desde el principio. Los
protocolos orientados a la conexión que operan en la capa de sesión proporcionan
un entorno donde las computadoras conectadas se ponen de acuerdo sobre los
parámetros relativos a la creación de los puntos de control en los datos, mantienen
un dialogo durante la transferencia de los mismos, y después terminan de forma
simultánea la sesión de transferencia.
En la capa de presentación se brinda una gama de funciones de codificación y

conversación que se aplican a los datos de la capa de aplicación. En particular, y a
diferencia de todas las capas inferiores que se interesen sólo en mover bits de
manera confiable de acá para allá, la capa de presentación se ocupa de la sintaxis
y la semántica de la información que se transmite. Estas funciones aseguran que
la información enviada desde la capa de aplicación de un sistema sea legible por
la capa de aplicación de otro sistema. Algunos ejemplos de esquemas de
codificación y conversación de la capa de presentación influyen formatos de
representación de datos comunes, esquemas de compresión de datos comunes y
esquemas de encriptación de datos comunes [2], [4].
Los formatos de presentación de datos comunes o el uso de formatos estándar de

video, sonido, imagen, permiten el intercambio de datos de aplicación entre
diferentes tipos de sistemas de computadoras. Los esquemas de conversación
utilizan para intercambiar información entre sistemas utilizando diferentes
presentaciones de texto y datos, como EBCDIC y ASCII. Por ejemplo; los datos
escritos en caracteres ASCII se traducirán a un formato más básico y genérico.
Por último, se encuentra la capa de aplicación que es la capa de OSI más cercana
al usuario final, lo cual significa que tanto la capa de aplicación de OSI como el
usuario interactúan de manera directa con la aplicación del software. Esta capa
interactúa con las aplicaciones de software que implementan un componente de
comunicación. Dichos programas de aplicación están fuera del alcance del modelo
OSI. Las funciones de la capa de aplicación incluyen identificación de socios de
comunicación, la determinación de la disponibilidad de recursos y la sincronización
de la comunicación [2].
También se encarga de ofrecer acceso general a la red. Esta capa suministra las
herramientas que el usuario ve. También ofrece los servicios de red relacionados
con estas aplicaciones de usuario, como la gestión de mensajes, la transferencia
de archivos y las consultas a base de datos. La capa de aplicación suministra
cada uno de estos servicios a los distintos programas de aplicación con los que
cuenta el usuario en su computadora. Entre los servicios de intercambio de
7
información que gestiona la capa de aplicación se encuentra la web, los servicios

de correo electrónico (como el protocolo simple de transferencia de correo,
comúnmente conocido como SMTP incluido en TCP IP), así como las aplicaciones
especiales de bases de datos cliente servidor [4].
En la siguiente figura 1.3 se muestra un ejemplo de cómo se pueden transmitir
datos empleando el modelo OSI.
Figura 1.3 Transmisión de Datos en el Modelo OSI [14]
Entre los protocolos (refiriéndose a protocolos genéricos, no a protocolos de la

capa de aplicación de OSI) más conocidos destacan:
- HTTP el protocolo bajo la www.

- FTP, FTAM, (fuera de TCP/IP) transferencia de ficheros
- SMTP (X.400 fuera de TCP/IP) envío y distribución de correo electrónico
- POP/IMAP: reparto de correo al usuario final
- SSH principalmente terminal remoto, aunque en realidad cifra casi cualquier
tipo de transmisión.
- Telnet otro terminal remoto, ha caído en desuso por su inseguridad
intrínseca, ya que las claves viajan sin cifrar por la red.
8
1.3 El modelo TCP/IP
Se han desarrollado diferentes familias de protocolos para comunicación por red

de datos para los sistemas UNIX. El más ampliamente utilizado es el Internet
ProtocolSuite, comúnmente conocido como TCP/IP. Este protocolo permite la
transmisión confiable de datos en un ambiente IP. El protocolo TCP corresponde a
la capa de transporte (Capa 4) del modelo de referencia OSI. Es un protocolo
DARPA que proporciona transmisión fiable de paquetes de datos sobre redes. El
nombre TCP/IP proviene de dos protocolos importantes de la familia, el Protocolo
de Control de Transmisión y el Protocolo de Internet. Todos juntos llegan a ser
más de 100 protocolos diferentes definidos en este conjunto.
El TCP/IP es la base del Internet que sirve para enlazar computadoras que utilizan
diferentes sistemas operativos, incluyendo PC, minicomputadoras y computadoras
centrales sobre redes de área local y área extensa. TCP/IP fue desarrollado y
demostrado por primera vez en 1972 por el departamento de defensa de los
Estados Unidos, ejecutándolo en el ARPANET una red de área extensa del
departamento de defensa [2], [3], [4], [5].
En la figura 1.4 se observa la correspondencia del modelo OSI con TCP/IP.
Figura 1.4 Correspondencia Modelo OSI y Modelo TCP/IP
Al igual que en el modelo OSI, los datos descienden por la pila de protocolos en el
sistema emisor y la escalan en el extremo receptor. Cada capa de la pila añade a
los datos a enviar a la capa inferior, información de control para que el envío sea
correcto. Esta información de control se denomina cabecera, pues se coloca
precediendo a los datos. A la adición de esta información en cada capa se le
denomina encapsulación. Cuando los datos se reciben tiene lugar el proceso
inverso, es decir, según los datos ascienden por la pila, se van eliminando las
cabeceras correspondientes.
Cada capa de la pila tiene su propia forma de entender los datos y, normalmente,
una denominación específica que podemos ver en la tabla 1.1 siguiente. Sin
9
embargo, todos son datos a transmitir, y los términos solo nos indican la
interpretación que cada capa hace de los datos.
TCP UDP
Capa de Aplicación Flujo Mensaje
Capa de Transporte Segmento Paquete
Capa de Internet Datagrama Datagrama
Capa de Acceso a la Red Trama Trama
Tabla 1.1 Comparación de Protocolo TCP y UDP
La arquitectura del TCP/IP consta de cinco niveles o capas en las que se agrupan
los protocolos, y que se relacionan con los niveles OSI de la siguiente manera.
1.3.1 Capas Física y Red
La capa 1 corresponde al análogo al nivel físico del OSI [3], [5].
Los protocolos de la capa 2 o de red especifican la organización de los datos y la

transmisión. Es la interfaz de la red real. TCP/IP no especifica ningún protocolo
concreto, así es que corre por las interfaces conocidas, como
por ejemplo: 802.2, CSMA/CD, X, 25, etc. [3], [5].
1.3.2 Capas de Internet y Transporte
La capa de internet define un formato de paquete y protocolo oficial llamado IP, así
como el mecanismo para reenviar paquetes del transmisor a sus destinos
correspondientes. Es utilizado con esta finalidad por los protocolos del nivel de
transporte [4], [5].
La capa de transporte en TCP/IP coincide con el nivel de transporte del modelo

OSI. Los protocolos de este nivel, tales como TCP y UDP, se encargan de
manejar los datos y especifican proporcionar la fiabilidad necesaria en el
transporte de los mismos [4], [5].
1.3.3 Capa de Aplicación
El modelo TCP/IP no tiene capas de sesión ni de presentación. Aquí se incluyen

protocolos destinados a proporcionar servicios, tales como correo electrónico
(SMTP), transferencia de ficheros (FTP), conexión remota (TELNET) y otros más
recientes como el protocolo HTTP [3], [4], [5].
10
Todas las capas anteriores en este modelo sirven de mera infraestructura de

telecomunicaciones. Por si solas no hacen nada más que mantener en buen
estado el camino para que fluyan los datos, la capa que hace posible que una red
se pueda usar es la capa de aplicación [3].
1.4 Familia de protocolos TCP/IP
Dentro de TCP/IP se emplean una gran variedad de servicios y aún más una gran
cantidad de protocolos que se agrupan para formar familias y de esta forma
proporcionar él envió de datos a través de una red de comunicaciones.
1.4.1 Protocolo de Control de Transmisión
TCP es uno de los protocolos fundamentales en Internet. Fue creado entre los
años 1973 - 1974 por Vint Cerf y Robert Kahn. Muchos programas dentro de una
red de datos compuesta por ordenadores pueden usar TCP para crear conexiones
entre ellos a través de las cuales enviarse un flujo de datos.
El protocolo garantiza que los datos serán entregados en su destino sin errores y
en el mismo orden en que se transmitieron. También proporciona un mecanismo
para distinguir distintas aplicaciones dentro de una misma máquina, a través del
concepto de puerto. TCP da soporte a muchas de las aplicaciones más populares
de Internet, incluidas HTTP, SMTP y SSH [3].
Funciones de TCP
En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de

internet (IP) y la aplicación. TCP añade las funciones necesarias para prestar un
servicio que permita que la comunicación entre dos sistemas se efectúe: libre de
errores, sin pérdidas y con seguridad. Y tiene las siguientes características:
 Conexión orientada - dos computadoras establecen una conexión para

enviar datos. El final del sistema se sincroniza con otra para administrar el
flujo de los paquetes y adapta la congestión a la red.
 Operación full-duplex - Una conexión TCP es un par de circuitos virtuales,
cada uno tiene una dirección. Al sincronizarse pueden utilizar la conexión.
 Verificación de errores - Utiliza técnicas de verificación para que los
paquetes no sean corrompidos, como el checksum.
 Secuencia - Los paquetes son numerados, con esto al llegar a su destino
se puede saber si los paquetes fueron enviados
 Control de flujo - Si al enviar se detecta un desbordamiento de paquetes al
ser recibidos, se realiza un bloqueo, hasta que él envió sea más lento.
 Reconocimiento de paquetes recibidos - Al recibir puede requerir
retransmisión de paquetes. Si se detecta que un paquete recibido no es
reconocido de manera correcta, el remitente reenvía los paquetes.
11
Formato de Segmentación de TCP
Las aplicaciones envían flujos de bytes a la capa TCP para ser enviados a la red.
TCP divide el flujo de bytes llegado de la aplicación en segmentos de tamaño
apropiado; normalmente esta limitación viene impuesta por la unidad máxima de
transferencia (MTU), del nivel de enlace de datos de la red a la que la entidad está
asociada y le añade sus cabeceras. Entonces, TCP pasa el segmento resultante a
la capa IP, donde a través de la red, llega a la capa TCP de la entidad destino.
TCP comprueba que ningún segmento se ha perdido dando a cada uno un
número de secuencia, que es también usado para asegurarse de que los paquetes
han llegado a la entidad destino en el orden correcto. TCP devuelve un
asentimiento por bytes que han sido recibidos correctamente; un temporizador en
la entidad origen del envío causará un timeout si el asentimiento no es recibido en
un tiempo razonable, y el (presuntamente desaparecido) paquete será entonces
retransmitido. TCP revisa que no haya bytes dañados durante el envío usando un
checksum; este es calculado por el emisor antes de cada paquete sea enviado, y
comprobado por el receptor [3].
1.4.2 Protocolo IP
IP comprende el Nivel Internet del Modelo DARPA (La Agencia de Proyectos de

Investigación Avanzados de Defensa) y proporciona la funcionalidad de
interconexión que hace posible la interconexión a gran escala como internet [7]. El
IP es un protocolo de la capa de red (Capa 3) que tiene información de
direccionamiento e información de control que permite el ruteo de paquetes. El IP
se encuentra documentado en el RFC 791 y es el protocolo principal de la capa de
red en el conjunto de protocolos de Internet. Junto con TCP, el protocolo IP
representa el corazón de los protocolos de Internet. El IP tiene dos
responsabilidades principales: ofrecer la entrega de datagramas basada en el
mejor esfuerzo y sin conexión a través de una red; y ofrecer la fragmentación y re-
ensamblado de datagramas para soportar los enlaces de datos con tamaños
diferentes de las MTU [2], [3].
Un datagrama IP tiene 32 bits de longitud y está conformado por un encabezado

de tamaño fijo de 20 bytes y por una sección opcional de longitud variable [4]
como se muestra en la figura 1.5.
12
Figura 1.5 Encabezado IPv4 [4]
El campo Versión tiene una longitud de 4 bits y como su nombre lo indica

proporciona la información acerca de la versión del protocolo IP que se está
utilizando, en este caso IP versión 4. El campo IHL indica la longitud en palabras
de 32 bits y por lo tanto apunta al comienzo de los datos [8]. El campo Tipo de
servicio provee una indicación acerca de cómo debe ser tratado el tráfico de
datagramas a través de una red si es que estos requieren transmisión de alta
prioridad o con alta confiabilidad [8], de tal forma que este campo de 8 bits utiliza
el siguiente orden para realizar las indicaciones que se requieren en la transmisión
de datagramas.
Tabla 1.2 (a) Indicaciones Tabla 1.2 (b) Precedencia
Indicaciones de la sección de Tipo de servicio [8].
En la figura 1.6 se muestra la sección de Tipo de Servicio del protocolo IPv4 que
utiliza las indicaciones anteriormente descritas en la tabla 1.2 (a) que describe los
servicios solicitados para su transmisión y en la tabla 1.2 (b) define el trato de
estos mismos de los 3 primeros bits de precedencia.
13
Figura 1.6 Tipo de Servicio
La sección de Longitud total define la longitud del encabezado y los datos, es

decir, del datagrama completo en octetos abarcando hasta 65535 bytes de
longitud máxima. El campo Identificación es el encargado de asignar una
secuencia de numeración único a cada datagrama enviado a la dirección de host
destino para que este sepa cómo ensamblar los datagramas que conforman la
información transmitida. El bit consecutivo está reservado (con valor cero) y a
continuación vienen dos campos conocidos como Flags o indicadores (por su
traducción al español) que proporcionan el control de la fragmentación donde DF
(Don’t Fragment) si es igual a 0, fragmentara el datagrama, en caso contrario si es
igual a 1, no lo fragmentara; el siguiente indicador MF (More Fragments) si es
igual a 0 indicara que es el último fragmento o si es 1 indicara la existencia de más
fragmentos [4], [8], [9].
El campo Desplazamiento de fragmento indica la posición del fragmento dentro

del datagrama. Tiempo de vida o TTL (Time To Live) proporciona el tiempo en
segundos que permite existir al datagrama dentro de la red, esto puede variar de
tal manera que al pasar por diferentes dispositivos enrutadores estos decrementan
una unidad al contador, aunque el tránsito por dichos dispositivos lo haga en
menos de un segundo [9], [10].
Suma de verificación del encabezado es el campo donde se habilita un código

de detección de errores exclusivamente a la cabecera ya que es un campo que
está en constante cambio debido al tránsito que hace por los diferentes
dispositivos enrutadores. El campo Dirección de origen y Dirección destino
proporcionan la información acerca de la red y el host finales, es decir, su
direccionamiento; finalizando con la cabecera se encuentra el campo de
Opciones que “contiene las opciones solicitadas por el usuario que envía los
datos” [9].
Cabe aclarar que en la figura 1.5 solo se muestra la cabecera de IPv4 por lo que
para que sea un datagrama de IPv4 se agrega el campo Datos por debajo del de
Opciones, que tiene una longitud de hasta 32 bits.
14
1.4.2.1 Funciones de IP
IP es un ejemplo de servicio sin conexiones, permite el intercambio de tráfico entre

dos computadoras anfitrionas sin establecer previamente una llamada. Sin
embargo, esas dos computadoras por lo regular comparten un protocolo de
transporte común orientado a conexiones, Puesto que IP no tiene conexiones,
cabe la posibilidad de que los datagramas se pierdan entre las dos estaciones de
usuario final. Por ejemplo, la puerta IP limita la longitud de la cola y, si se viola
esta longitud máxima de cola, los buffers se desbordan. En esta situación, los
datagramas adicionales se desecharán de la red. Por esta razón, es indispensable
contar con un protocolo de la capa de transporte de nivel más alto (como TCP)
para recuperarse cuando se presentan estos problemas [1], [3].
1.4.3 Suma de verificación (Checksum)
Es una comprobación que se hace para verificar la correcta transmisión de un

fichero; tiene la forma de control de redundancia, y es una medida muy simple
para proteger la integridad de datos, verificando que no hayan sido corrompidos.
Como ejemplo, diremos que, junto con el fichero, normalmente se envía uno
paralelo que contiene la suma binaria de los bits del fichero transmitido. La
verificación consiste en realizar la suma de estos bits y compararlo con la suma ya
realizada en el fichero paralelo. Si la suma coincide entonces se tiene la seguridad
de que esta transmisión se realizó de manera correcta.
La forma más simple de checksum no detecta una variedad de errores;
particularmente no cambiará si:
 Se cambia el orden de los bytes de la información.

 Se agregan o eliminan bytes de valor igual a cero.
 Múltiples errores que se cancelan unos con otros.
1.4.4 Protocolo UDP
Es un protocolo de la capa de transporte (Capa 4) no orientado a la conexión, que

pertenece a la familia de protocolos de internet. El UDP es, básicamente, una
interface entre IP y los protocolos de Internet [2].
Está basado en el intercambio de datagramas que, como TCP, funciona en redes
IP. UDP/IP proporciona muy pocos servicios de recuperación de errores,
ofreciendo en su lugar una manera directa de enviar y recibir datagramas a través
una red IP. Se utiliza sobre todo cuando la velocidad es un factor importante en la
transmisión de la información.
El FTP utiliza TCP/IP, mientras que TFTP utiliza UDP. TFTP son las siglas de
Protocolo de Transferencia de Archivos Triviales, y puesto que es trivial, perder
algo de información en la transferencia no es crucial. Es un protocolo mínimo de
nivel de transporte orientado a mensajes documentado en el RFC 768 de la IETF.
En la familia de protocolos de Internet UDP proporciona una sencilla interfaz entre
la capa de red y la capa de aplicación. UDP no otorga garantías para la entrega de
sus mensajes y el origen UDP no retiene estados de los mensajes UDP que han
15
sido enviados a la red. UDP sólo añade multiplexado de aplicación y suma de

verificación de la cabecera y payload. Cualquier tipo de garantías para la
transmisión de la información, deben ser implementadas en capas superiores.
1.4.5 Direccionamiento IP
Las redes TCP/IP utilizan una dirección de 32 bits para identificar una
computadora anfitriona y la red a la que esa computadora está conectada. La
estructura de la dirección IP es [1]:
Dirección de IP = Dirección de red + Dirección de anfitrión
Una dirección IP es un número que identifica de manera lógica y jerárquica a una

interfaz de un dispositivo (habitualmente una computadora) dentro de una red que
utilice el protocolo IP (Internet Protocol), que corresponde al nivel de red o nivel 3
del modelo de referencia OSI. Una dirección IP es una jerarquía de direcciones y
consiste en dos partes:
 El orden más alto, o el que está más a la izquierda, componen los bits que
especifican a la red.
 El orden más bajo; o el que está más a la derecha, componen los bits que
especifican el host.
Cada LAN o VLAN tiene una dirección que la especifica de las demás; al igual los
hosts que pertenecen a la red también tienen bits que lo identifican dentro de la
red. Estos números son únicos. Las direcciones IP se dividen en clases para
definir las redes de tamaño pequeño, mediano y grande. Hay tres clases de
direcciones IP que una organización puede recibir de parte de la Internet: clase A,
clase B y clase C. En la actualidad, Internet reserva las direcciones de clase A
para los gobiernos de todo el mundo y las direcciones de clase B para las
medianas empresas. Se otorgan direcciones de clase C para todos los demás
solicitantes. Cada clase de red permite una cantidad fija de equipos (hosts).
1.5 Protocolo DNS
Todos los hosts con TCP/IP tienen una dirección IP única que se utiliza para la
comunicación con otros equipos de la red. Una computadora trabaja fácilmente
con direcciones IP, pero no las personas; los usuarios suelen identificar los
sistemas por un nombre [7].
El Servicio de Nombres de Dominio DNS es una base de datos distribuida y
jerárquica que almacena información asociada a nombres de dominio enredes
como Internet. Aunque como base de datos el DNS es capaz de asociar diferentes
tipos de información a cada nombre, los usos más comunes son la asignación de
nombres de dominio a direcciones IP y la localización de los servidores de correo
electrónico de cada dominio.
16
El sistema de nombres de dominios en Internet es un sistema distribuido,

jerárquico, replicado y tolerante a fallas. Aunque parece muy difícil lograr todos
esos objetivos, la solución no es tan compleja en realidad. El punto central se basa
en un árbol que define la jerarquía entre los dominios y los sub-dominios. En un
nombre de dominio, la jerarquía se lee de derecha a izquierda [5], [6].
Tabla 1.3 Direcciones de Internet y sus clases
Por ejemplo, en dcc.uchile.ci, el dominio más alto es ci. Para que exista una raíz
del árbol, se puede ver como si existiera un punto al final del nombre:
dcc.uchile.ci.
y todos los dominios están bajo esa raíz (también llamada punto). Cada
componente del dominio (y también la raíz) tiene un servidor primario y varios
servidores secundarios. Todos estos servidores tienen la misma autoridad para
responder por ese dominio, pero el primario es el único con derecho para hacer
modificaciones en él. Por ello, el primario tiene la copia maestra y los secundarios
copian la información desde él. El servidor de nombres es un programa que
típicamente es una versión de BIND.
En general es mucho mejor traer la última versión desde Internet (www.isc.org)

que usar la que viene con el Sistema Operativo, porque es un servidor que ha
cambiado mucho a lo largo del tiempo. La raíz del sistema de dominios es servida
por algunos servidores bien conocidos. Todo servidor de nombres debe ser
configurado con la lista de los servidores raíz bien conocidos (en general lo vienen
de fábrica). Estos servidores dicen qué dominios de primer nivel existen y cuáles
son sus servidores de nombres. Recursivamente, los servidores de esos dominios
dicen qué sub-dominios existen y cuáles son sus servidores.
1.5.1 Espacio de Nombres de Dominio
Un nombre de dominio usualmente consiste en dos o más partes (técnicamente

etiquetas), separadas por puntos cuando se las escribe en forma de texto. Por
ejemplo, www.mahomedalid.org
 A la etiqueta ubicada más a la derecha se le llama dominio de nivel superior

(inglés <Top Level Domain). Como org en www.mahomedalid.org
17
 Cada etiqueta a la izquierda especifica una subdivisión o subdominio.

Nótese que "subdominio” expresa dependencia relativa, no dependencia
absoluta. En teoría, esta subdivisión puede tener hasta 127 niveles, y cada
etiqueta contener hasta 63 caracteres, pero restringido a que la longitud
total del nombre del dominio no exceda los 255 caracteres, aunque en la
práctica los dominios son casi siempre mucho más cortos.
 Finalmente, la parte más a la izquierda del dominio suele expresar el
nombre de la máquina (en inglés hostname). El resto del nombre de
dominio simplemente especifica la manera de crear una ruta lógica a la
información requerida. Por ejemplo, el dominio es.Wikipedia.org tendría el
nombre de la máquina .es", aunque en este caso no se refiere a una
máquina física en particular.
El espacio de nombres de dominio es un espacio de nombres jerárquico,

estructurado en árbol que empieza en una raíz sin nombre para todas las
operaciones DNS [7]. Cada dominio o subdominio tiene una o más zonas de
autoridad que publican la información acerca del dominio y los nombres de
servicios de cualquier dominio incluido. La jerarquía de las zonas de autoridad
coincide con la jerarquía de los dominios. Al inicio de esa jerarquía se encuentra
los servidores raíz: los servidores que responden cuando se busca resolver un
dominio de primer y segundo nivel.
En la figura 1.5 se muestra la estructura del espacio de nombres de dominio de
Internet.
Figura 1.7 Espacio de nombres de dominio de Internet [4].
1.6 Arquitectura DMZ

Cuando ciertas máquinas de la red interna tienen que ser accesibles desde el
exterior (servidor web, un servidor de mensajería, un servidor FTP público, etc.),
normalmente es necesario crear una nueva política para una nueva red, accesible
tanto desde la red interna como desde el exterior, sin correr el riesgo de
18
comprometer la seguridad de la empresa. Se habla entonces de una "Zona

Desmilitarizada" (DMZ) para designar esta zona aislada que aloja aplicaciones a
disposición del público. El DMZ sirve como una zona intermedia entre la red a
proteger y la red hostil.
El objetivo principal, es que todo el tráfico externo se comunique solamente con la
DMZ. La DMZ no se puede comunicar con la red interna, previniendo posibles
ataques en caso de algún intruso gane control de la DMZ
Los firewalls permiten definir reglas de acceso entre dos redes. Sin embargo, en la
práctica, las empresas tienen generalmente varias subredes con políticas de
seguridad diferentes. Es la razón por la cual es necesario instalar arquitecturas de
sistemas firewall que permitan aislar las diferentes redes de la empresa: se habla
entonces de compartir las “redes"(el término aislar es utilizado frecuentemente
también). Figura 1.6.
Figura 1.8 Diagrama de una red típica que usa una DMZ con un cortafuego
19
1.7 Socket
Los Socket aparecieron a principios de los 80 con el sistema UNIX de Berkeley,
para proporcionar un medio de comunicación a los procesos, con el fin de
proporcionar un medio de comunicación entre ellos. Los sockets, si hacemos un
símil, tienen la misma función que la que pudiera tener la comunicación por correo
o por teléfono (de un buzón se extraen mensajes completos, mientras que el
teléfono permite el envío de flujos de información que no tienen una estructura
claramente definida; esta dualidad se encuentra en los sockets). El socket, por
tanto, ofrece dos puntos de contacto entre distintas aplicaciones, a través de los
cuales estas se comunican. Otra característica importante de los puntos de
comunicación concierne al conjunto de otros puntos que permite acceder. La
noción de dominio de un socket permite definir el conjunto de sockets con los
cuales se podrá establecer una comunicación por medio de él [5], [6], [11].
1.7.1 Definición de un Socket

Un socket es un punto de comunicación por el cual un proceso puede emitir o
recibir información. En el interior de un proceso, un socket se identifica por un
descriptor de la misma naturaleza que los que identifican los archivos, al igual que
todos los procesos del sistema UNIX de Berkeley. La comunicación mediante
sockets es una interfaz (o servicio) con la capa de transporte (nivel 4) de la
jerarquía OSI. La filosofía de la división por capas de un sistema es encapsular,
dentro de cada una de ellas, detalles que conciernen sólo a cada capa, y
presentársela al usuario de tal forma que este pueda trabajar con ella sin
necesidad de conocer sus detalles de implementación. La interfaz de acceso a la
capa de transporte del sistema UNIX de Berkeley no está totalmente aislada de las
capas inferiores, por lo que, a la hora de trabajar con sockets, es necesario
conocer algunos detalles sobre esas capas. En concreto, a la hora de establecer
una conexión mediante sockets, es necesario conocer la familia o dominio de la
conexión, y el tipo de conexión. La creación de un socket se realizará por la
primitiva socket, cuyo valor de vuelta es un descriptor sobre el cual es posible
realizar operaciones de escritura y lectura [5], [6]. Un socket permite la
comunicación en los dos sentidos (conexión full-dúplex). Figura 1.9.
20
Figura 1.9: Comunicación entre procesos Sockets, Cliente/Servidor
21
Capítulo 2. Requerimientos de Hardware, dispositivos de estado sólido y
herramientas de programación
Capítulo 2: Requerimientos de Hardware, dispositivos de estado
sólido y herramientas de programación.
2.1 Herramientas de programación
Cuando hablamos de desarrollo y manejo de hardware, hablamos de forma
implícita de la utilización de diferentes herramientas o lenguajes de programación
con los cuales es posible la comunicación humano-máquina que ordena y crea las
diferentes funcionalidades que ofrecen los diferentes dispositivos o controladores.
A continuación, se da una breve explicación de las herramientas de programación
empleadas para la realización de este trabajo.
2.1.1 Sistema Operativo ANDROID
Los teléfonos móviles, como cualquier aparato electrónico tienen dos partes:
el hardware y el software.
Hay un software especializado, el sistema operativo que controla a otras

aplicaciones, pero, sobre todo, se encarga de gestionar el hardware, los
dispositivos. En los ordenadores podemos diferenciar claramente el sistema
operativo (Windows, Linux, Mac OS) del resto de programas.
En los teléfonos móviles, al principio esto era totalmente transparente para el

usuario. El móvil podía hacer una serie de cosas muy limitadas, que ya venían
instaladas de fábrica.
Aunque las funciones eran más o menos comunes, cada móvil era distinto, ya que
se manejaba con el software propio de cada fabricante, que podía ser muy distinto
al de otro. Más tarde los móviles nos permitieron instalar pequeñas aplicaciones,
sobre todo juego en Java. Ahí se comenzaba a diferenciar entre software propio
del móvil y lo que podíamos instalar. Aunque como el sistema operativo del móvil
aún dependía del fabricante, se debería asegurar de que lo que pretendíamos
instalar iba a funcionar en nuestro terminal.
Con la evolución de los terminales móviles y tablets, se hizo necesario el poder

instalar y desinstalar aplicaciones más complejas acorde a las necesidades de los
usuarios. Y no tenía sentido tener que crear la aplicación para el sistema de cada
fabricante. Por lo que aparecieron los verdaderos sistemas operativos, que
funcionaban en móviles de distintos fabricantes.
Los primeros sistemas operativos para móviles fueron Symbian (de Panasonic,
Siemens AG, Nokia, Sony-Ericsson entre otras), Palm (sobre todo para PDAs),
BlackBerry y Windows Mobile (de Microsoft). Apple revoluciono el mundo de la
telefonía móvil con el lanzamiento de su familia iPhone, con el sistema operativo
iPhone OS, y su pantalla multitáctil. Posteriormente apareció Android. Microsoft ha
lanzado recientemente el Windows 8 que sirve tanto para PCs como para móviles
y tablets. Android nació inicialmente para teléfonos, en septiembre de 2008, luego
22
en febrero de 2011 apareció Android 3.0 para tablets, y en octubre de 2011
apareció Android 4.0 que unificó los dos sistemas (teléfonos y tablets) en uno sólo.
La versión en noviembre de 2012 es Android 4.2. La principal ventaja de utilizar
uno de estos sistemas operativos es que disponemos de una gran cantidad de
aplicaciones. Además, como pasa con los ordenadores, dos dispositivos con el
mismo sistema operativo se manejarán igual, aunque puede que tengan distinta
pantalla, cámara, que uno no integre GPS, o que sean de distinto fabricante.
Aunque puede haber pequeñas diferencias ya que cada fabricante puede
modificar algunos aspectos de Android.
La principal diferencia entre Android y el resto de sistemas operativos para

dispositivos móviles es que es software libre, basado en Linux, y la mayor parte es
de código abierto. Esto quiere decir que no deberás de pagar nada por él, y que
cualquiera puede añadirle mejoras. En los sistemas propietarios, sólo el fabricante
puede hacer modificaciones.
La principal empresa que hay detrás del desarrollo de Android es Google, quien
lidera la Open Handset Alliance, un consorcio de empresas que se comprometen a
seguir los estándares abiertos y libres.
2.1.2 Java
El lenguaje para la programación en Java, es un lenguaje orientado a objetos, de
una plataforma independiente. El lenguaje para la programación en Java, fue
desarrollado por la compañía Sun Microsystems, con la idea original de usarlo
para la creación de páginas WEB.
Con la programación en Java, se pueden realizar distintos aplicativos, como son
applets, que son aplicaciones especiales, que se ejecutan dentro de un navegador
al ser cargada una página HTML en un servidor WEB. Por lo general los applets
son programas pequeños y de propósitos específicos. Otra de las utilidades de la
programación en Java es el desarrollo de aplicaciones, que son programas que se
ejecutan en forma independiente, es decir con la programación Java, se pueden
realizar aplicaciones como un procesador de palabras, una hoja que sirva para
cálculos, una aplicación gráfica, etc. en resumen cualquier tipo de aplicación se
puede realizar con ella. Java permite la modularidad por lo que se pueden hacer
rutinas individuales que sean usadas por más de una aplicación, por ejemplo,
tenemos una rutina de impresión que puede servir para el procesador de palabras,
como para la hoja de cálculo.
La programación en Java, permite el desarrollo de aplicaciones bajo el esquema
de Cliente/Servidor, como de aplicaciones distribuidas, lo que lo hace capaz de
conectar dos o más computadoras u ordenadores, ejecutando tareas
simultáneamente, y de esta forma logra distribuir el trabajo a realizar.
23
Diferencias con C++
1. En Java no es posible crear variables globales. Solo las variables estáticas
y publicas de algunas clases pueden considerarse como tales, pero esto
generalmente, y como en el caso de las variables globales en C++son
síntoma de un mal diseño.
2. Java no dispone de sentencia goto lo cual permite crear un código más
robusto y seguro, así como más optimizado. Para cubrir esta falta Java
proporciona un tratamiento muy optimizado de excepciones, poderoso y
bien definido.
3. Los punteros son una característica poderosa y peligrosa del C + +, en si
evitan que ninguna variable sea privada de verdad, ya que es fácil acceder
a la misma a través de punteros, los cuales son fuente de problemas y mal
funcionamiento. Java no dispone de tratamiento de punteros. Los vectores
o arrays lo son de modo cierto, lo cual evita sobrepasar el mismo o salirse
de sus límites.
4. El manejo de memoria en C se realiza de forma peligrosa a través de
punteros obtenidos con la función malloc(), y que se libera explícitamente
con free(), esto puede causar errores si el programador no controla
perfectamente los pasos en que estas operaciones se realizan. Otro error
es el olvido frecuente de liberar memoria, lo cual termina consumiendo los
recursos del sistema. Java no dispone de punteros y todos los objetos se
crean con el operador new, el cual asigna espacio en el montículo de
memoria a cada objeto. Lo que se obtiene con new es un descriptor del
objeto (no una dirección) la dirección real es manejada por el sistema el
cual la puede mover o recolocar según su necesidad, pero el programador
no ha de preocuparse por ello. Lo importante es que el objeto tiene
memoria asignada mientras le interese al programa, quedando esta
memoria disponible en cuanto este interés cese. No hará falta llamar a free
o delete ya que el recolector de basura realizará esta labor. Este recolector
o reciclador de basura se ejecutará cuando el sistema esté libre o una
asignación no encuentre lugar disponible.
5. C y C + + disponen de tipos de datos frágiles cuyos límites y características
dependen de la implementación y máquina del compilador. Java
implementa límites de tamaños sensatos y válidos para todo tipo de
máquinas y entornos (independientes del Hardware) por lo que es
totalmente reproducibles en cualquier plataforma.
6. En C es posible la realización de casting o conversión de tipos en tiempo de
ejecución. En C++ esta operación es peligrosa ya que los objetos son
referencias a zonas de memoria y no es posible tener información sobre sí
la conversión en posible. En Java los descriptores de los objetos contienen
información completa acerca de la clase a la que pertenece el objeto, por lo
que pueden realizarse comprobaciones en tiempo de ejecución sobre la
compatibilidad de tipos y emitir la excepción correspondiente si no es
aplicable la conversión.
24
7. En Java no se dispone de archivos de cabecera con los prototipos delas
clases. Esto, en principio es una desventaja, hasta que se comprueba que
esta habilidad del C + + ha llevado a entornos de compilación
prácticamente inmanejables, ya que cada compilación puede tratar estos
archivos de formas un tanto complejas. Java no dispone de esta habilidad
de archivos de cabecera, el tipo y la visibilidad de la clase se compila en el
propio archivo de la clase, siendo tarea del intérprete de Java realizar el
acceso.
8. Java no tiene struct ni unión, ambos sistemas de encapsulamiento y
polimorfismo un tanto crípticos e inseguros del C ++, unificando todo en un
solo concepto de class.
9. La programación de entornos reales de C y C++ implica un buen
conocimiento del manejo del preprocesador y sus trucos, lo cual no es una
manera limpia de controlar lo que se compila. Java no dispone de este
sistema, pero tienen medios (como la declaración final para constantes) que
permiten igual potencia.
Descripción de atributos en Java
1. Applets programas elementales incluidos en páginas HTML a través de la
etiqueta app y que se despliega en el visualizador tras cargarse la página.
2. Aplicaciones programas escritos en Java y que se ejecutan de forma
independiente de los visualizadores. Esto se realiza llamando a los
interpretes Java con el programa como opción.
3. Manipuladores de protocolo programas que se cargan en el visualizador
e interpretan un protocolo (como pueda ser HTTP).
4. Manipuladores de contenido un programa cargado en el visualizador y
que interpreta el contenido de determinado tipo de ficheros.
5. Métodos nativos métodos que se declaran en una cierta clase Java pero
que se implementan en C.
2.1.3 Introducción al desarrollo de aplicaciones en Android Studio

El entorno de trabajo en Android Studio asemeja mucho al de otras plataformas de
desarrollo. La siguiente lista proporciona un vistazo general del proceso de construcción
de una aplicación de ANDROID.
1. Preparar el espacio de trabajo y crear un nuevo proyecto

Un proyecto en AndroidStudio contiene todos los elementos que definen el
espacio de trabajo para una app, el código fuente y los elementos activos para
hacer pruebas de código y construir configuraciones. Por default Android
Studio despliega los archivos del proyecto en la sección AndroidView. Esta
vista desplegada no refleja la jerarquía real de los archivos, pero está
organizada por Módulos y por tipos de archivo para simplificar la navegación
entre los principales archivos fuente del proyecto, ocultando ciertos archivos y
25
directorios que no se utilizan comúnmente. Dentro de cada Módulo de la
aplicación de ANDROID, los archivos son mostrados en los siguientes grupos.
 manifest
Contiene los archivos AndroidManifest:xml
 Java
Contiene los archivos de Código fuente de Java separados por nombres
de paquete.
 Res
Contiene todos los recursos de non-Code, tales como capas de XML,
cadenas UI, imágenes divididas dentro de los subdirectorios
correspondientes.
Figura 2.1 Sección AndroidV iew en el compilador Android Studio
2. Seleccionar Factores de Forma y nivel API

En la siguiente ventana se seleccionan los factores de forma soportados
por la aplicación, tal como teléfono, tableta, TV etc. Los factores de forma
seleccionados se convertirán en los módulos de aplicación dentro del
26
proyecto. Para cada factor de forma se puede seleccionar el nivel de API
para esa aplicación.
Figura 2.2 Gráfico que muestra la versión actual de distribuciones de ANDROID

mostrado cuando se da clic en Help me choose
La ventana de distribución de la plataforma de ANDROID muestra la

distribución de dispositivos móviles que funcionan con cada versión de
ANDROID, como se muestra en la Figura: 2.2. Al dar click en API Level se
muestra una lista de características introducidas en la versión
correspondiente de ANDROID. Esto ayudará al desarrollador a elegir el
nivel mínimo de API que posee todas las características que sus apps
necesitan, de tal forma que puede extender la aplicación para que funcione
en tantos dispositivos como sea posible.
27
Figura 2.3 Pantalla de dispositivos de destino de ANDROID.
3. Añadir una actividad

En la siguiente ventana se debe seleccionar algún tipo de actividad para
añadir a la aplicación tal como se muestra en la Figura: 2.4. La pantalla
muestra un conjunto diferente de actividades para cada uno de los factores
de forma que seleccionó anteriormente.
Figura 2.4 La pantalla Add an Activity para un factor de forma
Al elegir un tipo de actividad se da clic en Next y se procede a configurarla

introduciendo un nombre para la actividad, el nombre de la clase que
28
contiene dicha actividad y finalmente se concluye el proceso de creación
del proyecto dando click en Finish.
4. Desarrollar la Aplicación
Android Studio crea por default la estructura del proyecto y abre el entorno
de desarrollo. Si la aplicación soporta más de un factor de forma, Android
Studio crea una carpeta con archivos de código fuente para cada uno de los
factores de forma como se muestra en la Figura: 2.5.
Figura 2.5 Estructura de proyecto para una aplicación recién creada.
2.1.3.1 App Manifest

Todas las aplicaciones deben contener un archivo AndroidManifest:xml
(precisamente con ese nombre) en su directorio raíz. El archivo Manifest contiene
información contiene información esencial acerca de la aplicación para el sistema
ANDROID, información que el sistema debe tener antes de que pueda ejecutar
cualquier código. Entre otras cosas el Manifest tiene las siguientes funciones:
 Nombra los paquetes de Java para la aplicación. El nombre del paquete
sirve como un identificador único para la aplicación.
 Describe los componentes de la aplicación, las actividades, los servicios
y los proveedores de servicios que componen la aplicación. Nombra las
clases que implementan cada uno de los componentes y que publican
sus capacidades. Estas declaraciones permiten al sistema ANDROID
29
saber que componentes existen y bajo qué condiciones son
inicializados.
 Determina que procesos serán los anfitriones de los componentes de la
aplicación.
 Declara los permisos que la aplicación debe tener a n de acceder a las
partes protegidas de la API e interactuar con otras aplicaciones.
 Declara también los permisos que los elementos externos están
obligados a tener con el fin de interactuar con los componentes de la
aplicación.
 Declara el nivel API mínimo requerido por la aplicación.
2.1.3.2 Construyendo una App con Android Studio

Para ejemplificar de mejor manera los conceptos anteriores y a fin de comenzar a
familiarizarnos con el entorno de trabajo de la plataforma de Android Studio, en
esta sección se va a crear un layout en XML que contiene un campo de texto y un
botón. La interfaz gráfica de usuario está construida utilizando una jerarquía de
objetos View y ViewGroup. Los objetos View son usualmente Widgets tal como
botones o campos de texto. ANDROID proporciona un diccionario XML que
corresponde a las subclases de View y ViewGroup por lo cual podemos definir
nuestro UI usando una jerarquía de elementos UI.
Los Layouts son subclases de ViewGroup. En este ejemplo trabajaremos con
LinearLayout.
Figura 2.6 Ilustración de como un objeto ViewGroup forma ramas en el Layout y

contiene otros objetos View
30
2.1.4 Python
Python es un lenguaje de programación interpretado cuya filosofía hace hincapié
en una sintaxis que favorezca un código legible. Es un lenguaje de programación
similar a Perl, pero con una sintaxis muy limpia y que favorece un código legible.
Se trata de un lenguaje interpretado o de script, con tipado dinámico, fuertemente
tipado, multiplataforma y orientado a objetos. Significa que el intérprete de Python
está disponible en multitud de plataformas (UNIX; Solaris; Linux; DOS; Windows;
OS/2; MacOS; etc.) por lo que si no utilizamos librerías específicas de cada
plataforma nuestro programa podrá correr en todos estos sistemas sin grandes
cambios [11].
2.1.4.1 Lenguaje interpretado ó de script

Un lenguaje interpretado o de script es aquel que se ejecuta utilizando un
programa intermedio llamado intérprete, en lugar de compilar el código a lenguaje
máquina que pueda comprender y ejecutar directamente una computadora
(lenguajes compilados). La ventaja de los lenguajes compilados es que su
ejecución es más rápida. Sin embargo, los lenguajes interpretados son más
flexibles y más portables [11]. Python tiene, no obstante, muchas de las
características de los lenguajes compilados, por lo que se podría decir que es
semi-interpretado. En Python, como en Java y muchos otros lenguajes, el código
fuente se traduce a un pseudo código máquina intermedio llamado bytecode la
primera vez que se ejecuta, generando archivos “.pyc” o “.pyo” (bytecode
optimizado), que son los que se ejecutarán en sucesivas ocasiones.
2.1.4.2 Transmisión de Datos

La comunicación entre distintas entidades en una red se basa en Python en el
clásico concepto de sockets. Los sockets son un concepto abstracto con el que se
designa al punto final de una conexión. Los programas utilizan sockets para
comunicarse con otros programas, que pueden estar situados en computadoras
distintas. Un Socket queda definido por la dirección IP de la máquina, el puerto en
el que escucha, y el protocolo que utiliza.
Los sistemas de transmisión de datos constituyen el apoyo de los sistemas de
cómputo para el transporte de la información que manejan. Sin estos no hubiera
sido posible la creación de las redes avanzadas de computo de procesamiento
distribuido, en las que compartir información y transferir datos entre computadoras
con gran difusión geográfica, sumamente rápido y en grandes volúmenes.
31
2.1.5 Servicio no – IP
El servicio de DNS dinámica de No-IP permite identificar tu PC con un nombre de
dominio fácil de recordar, como TuNombre.no-ip.com en lugar de con un número
extraño del tipo 213.171.218.201 y poder montar un servidor sin complicaciones
independientemente de si tenemos ó no una IP estática. Una dirección IP es un
conjunto de 4 números de 0 a 255 separados por puntos, que identifica a una
computadora en una red (un conjunto de computadores conectados entre sí). Un
mismo computador tendrá asignada una IP por cada red a la que esté conectado.
Independientemente de su tamaño Internet no deja de ser otra red, por lo que es
evidente según la definición anterior que toda computadora, por el hecho de estar
conectada a ésta, contará con una IP por la que es conocida y referenciada por los
demás equipos de la red. Esta IP, al contrario de las
IP’s de una red local que podemos asignar nosotros mismos, viene dada por el
proveedor de acceso a internet.
Un símil útil para entender las direcciones IP sería un número de teléfono que
marcamos para hablar con otra persona. A la persona que solicita la comunicación
se le conoce con el nombre de cliente, y podría ser, por ejemplo, un navegador
web como Firefox o un cliente de FTP como SmartFTP. La persona al otro lado de
la línea, el PC al que llamamos y del cual requerimos un servicio, se conoce con el
nombre de servidor. Esta comunicación cliente-servidor se lleva a cabo, por
ejemplo, cada vez que visitamos una página web. Tomemos por ejemplo el caso
de Google. La IP del computador dónde se aloja su web es 216.239.37.99. Este
computador ejecuta de forma continuada una aplicación llamada servidor web, que
no es más que un programa que espera a que un cliente realice una petición y
contesta entonces de forma adecuada, enviando al cliente la web solicitada o un
mensaje de error si procede.
2.1.5.1 Dyn DNS
Existen servicios alternativos como No-IP ó DynDNS que nos ofrecen subdominios
(tendremos URLs de la forma miweb.dominio, como por ejemplo miweb.no-ip.com)
de forma gratuita y sin publicidad. Dyndns es una compañía en la red que ofrece
IP gratuitas, o, dicho de otra manera, nosotros lo conocemos como "dominios 2
"subdominios". De esta manera nos ofrecen la oportunidad de que cualquier
persona posea un servidor en internet por ejemplo:teamasm.dyndns.org
Normalmente gran variedad de las IP son dinámicas, estoy quiere decir que
nosotros podemos trabajar muy bien en nuestra pc siempre y que la IP no cambie,
pero en caso de que se valla la luz, o se apague el equipo, al reiniciar el servicio
se perderá nuestra IP, entonces como haremos si paso esto. Teniendo en cuenta
lo anterior y que la IP es dinámica, nosotros no podríamos saber con exactitud la
32
IP de nuestra pc estando lejos de ella, y es en este caso que nos es funcional el
Dyndns porque él nos podrá proporcionarla.
2.2 Requerimientos de Hardware
En este apartado se explicará de forma breve las características de hardware y
algunas de sus funciones que nos ayudaran en la elaboración del sistema de
control y monitoreo.
2.2.1 Raspberry Pi
Es una tarjeta de desarrollo que soporta varios componentes necesarios en un
ordenador común, un pequeño ordenador de bajo costo, tan pequeño como una
tarjeta de crédito con un mínimo de consumo de energía. Puede ser utilizado por
muchas de las cosas que su PC de escritorio hace, como hojas de cálculo,
procesadores de texto y juegos, también reproduce vídeo de alta definición.
Una de las principales ventajas del Raspberry Pi es que podemos tener acceso al
hardware de bajo nivel, lo que permite utilizarlo en proyectos de integración con
hardware como el que estamos acostumbrados a ver en proyectos con Arduino.
El diseño incluye un System-on-a-chip Broadcom BCM2835, que contiene un
procesador central (CPU) ARM1176JZF-S a 700 MHz (el firmware incluye unos
modos – Turbo - para que el usuario pueda hacerle overclock de hasta 1 GHz sin
perder la garantía), un procesador gráfico (GPU) VideoCore IV, y 512 MB de
memoria RAM (aunque originalmente al ser lanzado eran 256 MB). El diseño no
incluye un disco duro ni unidad de estado sólido, ya que usa una tarjeta SD para el
almacenamiento permanente; tampoco incluye fuente de alimentación ni carcasa.
La fundación da soporte para las descargas de las distribuciones para arquitectura
ARM, Raspbian (derivada de Debian), RISC OS 5, Arch Linux ARM (derivado de
Arch Linux) y Pidora (derivado de Fedora); y promueve principalmente el
aprendizaje del lenguaje de programación Python. Otros lenguajes también
soportados son Tiny BASIC, C, Perl y Ruby. A continuación, se muestra una
fotografía del ordenador Raspberry Pi Figura 2.7.
Figura 2.7 Placa de Ordenador RaspberryPi
33
2.2.2 Microcontrolador MSP430G2553
Los microcontroladores de la serie MSP4304 de TexasInstruments, son
procesadores de señal combinada de 16 bits, basados en la arquitectura RISC5 ó
(Computador de Conjunto de Instrucciones Reducidas), diseñados para tener un
consumo ultra bajo. Además, disponen de una cantidad de periféricos muy variado
para realizar proyectos muy diversos. Por esta razón, y por ser un componente
bastante económico, se ha decidido utilizar este microcontrolador en nuestro
proyecto.
A continuación, se muestra una fotografía de la placa de desarrollo en la que viene
conectado el MSP430G2553. Figura 2.8.
Figura 2.8 Placa de desarrollo ó LaunchPad, del microcontrolador MSP430

Características Principales del MSP430g2553
 Velocidad del reloj: configurable entre 1 y 16 MHz.
 Memoria FLASH: 16KB.
 Memoria SRAM: 512B.
 Memoria NVM: 56KB.
 Memoria SRAM: 4KB.
 Pines GPIO: 24 como máximo.
 2 Temporizadores
 Convertidor ADC de 8 canales
 UART
 I2C
 SPI
34
2.2.3 UART
UART (Recepción-Transmisión Asíncrono Universal) es uno de los protocolos
serie más utilizados. La mayoría de los controladores disponen de hardware
UART. Usa una línea de datos simple para transmitir y otra para recibir datos.
Comúnmente, 8 bits de datos son transmitidos de la siguiente forma: un bit de
inicio, a nivel bajo, 8 bits de datos y un bit de parada a nivel alto. El bit de inicio a
nivel bajo y el de parada a nivel alto indican que siempre hay una transmisión de
alto a bajo para iniciar la transmisión. Eso es lo que describe a UART.
El UART toma bytes de datos y transmite los bits individuales de una manera
secuencial. En el destino, un segundo UART re-ensambla los bits en bytes
completos. Hay que tener en cuenta, que los microcontroladores que quieren
comunicarse vía UART tienen que fijar la velocidad de transmisión, la tasa de bits,
ya que sólo disponen del bit de flanco de bajada para sincronizar.
Esto es llamado comunicación asíncrona. Transmisión de serie es de uso común
con los modems y para la comunicación sin conexión a red entre ordenadores,
terminales y otros dispositivos.
Funciones de un UART
 Convierte los datos de paralelo a serie y viceversa
 Genera y checa la paridad de los datos
 Genera bit de arranque (conexiones múltiples)
 Inserta bit de parada
 Controla el número de bits por carácter
 Almacena temporalmente el mensaje
 Controla la velocidad de transmisión
2.2.4 Modulación por ancho de pulsos (PWM)

La técnica de modulación por ancho de pulso PWM es la obtención de un
resultado analógico con medios digitales, es decir, que por medio de un control
digital se crea una señal cuadrada que al modularse ampliando o reduciendo el
ancho de dicha señal se obtendrá un valor análogo variable. Esto, para fines de
este trabajo es muy útil debido a la aplicación que se le dará en el cambio de
intensidad luminosa en luminarias. EL PWM simula tensiones entre el encendido
total (3 volts, para el MSP) y el apagado que es de 0 volts [12]. El ancho de pulso
está definido por el ciclo de trabajo, que representa la relación entre el estado
activo de la señal y su periodo. En la figura 2.9 se describe el comportamiento del
PWM y su ciclo de trabajo.
35
Figura 2.9 Ciclo de trabajo del PWM [12]
El intervalo de cada línea verde representa el periodo de la señal y la instrucción

analogWrite() (para el MSP430XX) define dentro del intervalo de 0 a 255 la
duración del ancho de la señal, es decir, el ancho de la señal es proporcional al
valor del intervalo definido por la instrucción.
36
2.2.5 Arduino UNO
La tarjeta de desarrollo Arduino UNO REV 3 utiliza el microcontrolador de alto
rendimiento ATmega328P de 8 bits de la empresa ATMEL. Es ideal para
aplicaciones tanto estudiantiles como profesionales, esto en parte gracias a la
cantidad de librerías y tutoriales que explican su funcionamiento para diversos
aplicativos.
Figura 2.10 Tarjeta de desarrollo Arduino UNO REV 3
Características principales del Arduino UNO REV 3

Arduino opera con un voltaje de 5v y contiene 14 pines digitales de entrada/salida
de los cuales 6 pueden ser utilizados como salidas de PWM (Pulse Width
Modulation), así como una conexión USB que facilita la conexión a la
computadora. Otras características son [13]:
 6 entradas analógicas
 Memoria Flash de 32 KB
 SRAM de 2KB
 EEPROM de 1 KB
 Cristal de cuarzo con velocidad de reloj de 16 MHz
 20 mA de corriente directa por cada pin de Entrada/Salida
 50 mA de corriente directa para pin de 3.3 volts
37
2.3 Dispositivos
Los dispositivos empleados en este trabajo fueron seleccionados según sus
características que dotan al proyecto de calidad y una alta fiabilidad de operación.
2.3.1 Sensor de temperatura y humedad relativa DHT22

El sensor de temperatura y humedad relativa DHT22 o también conocido como el
AM2302 es un sensor que utiliza un solo PIN de señal digital calibrada de salida,
puede ser de alto o bajo consumo dependiendo de la fuente de alimentación y las
necesidades de su aplicación si es que se requiere un bajo consumo. Su
aplicación de tecnología de módulos digitales de recolección de humedad y
temperatura lo hacen un dispositivo bastante fiable y con una gran estabilidad para
aplicaciones de larga duración, cuenta con un microcontrolador de alto
rendimiento de 8 bits y una rápida respuesta. Figura 2.11.
Figura 2.11 Sensor DHT22 o AM2302
Características del dispositivo

El dispositivo de acuerdo a las necesidades de aplicación puede trabajar con un
voltaje que va desde los 3.3 volts hasta un máximo de 5.5 volts (Típico a 5V), con
una resistencia de Pull-up de 5.1 kΩ conectada al bus de datos para aplicaciones
típicas.
38
El rango de temperatura que detecta el DHT22 va de los -40° hasta 80°C con una
precisión de +/- 0.5 y +/- 1.
El rango de % de humedad relativa (%RH) es de hasta un 99.9% con una
precisión a los 25°C de +/- 2. Anexo A
En la figura 2.12 se muestran los pines y su descripción en la tabla 2.1.
Figura 2.12 Pines del DHT22
PIN Nombre Descripción

1 VDD A la fuente (3.3v – 5.5v)
2 SDA Serial data (puerto bidireccional de datos serial)
3 NC No se utiliza
4 GND Tierra
Tabla 2.1 Configuración de los pines del DHT22
Funcionamiento
El funcionamiento del DHT22 se caracteriza por su sistema de intercambio de
datos controlado por su única línea de datos de manera que este solo enviará o
responderá cuando el host se lo solicite creando una estructura maestro-esclavo,
pero para poder llevar acabo la comunicación con el sensor, el host deberá seguir
de una manera estricta la secuencia del único bus de datos.
39
Figura 2.13 Diagrama de conexión eléctrica
El bus de datos en estado inactivo se encontrará en un estado alto, para inicializar

la señal del sensor, el host o el microprocesador deberá mandar un estado bajo de
aproximadamente 800µs para notificar al sensor que prepare los datos,
subsecuente se iniciará una señal de respuesta hacia el host con un estado bajo
de 80µs y en seguida un estado alto de 80µs como se muestra en la figura 2.14.
Figura 2.14 Señales del DHT22
El sensor enviara una cantidad de 40 datos dividido en cadenas o secuencias de

bits que envían la siguiente información.
 La humedad relativa consta de 16 bits y proporciona un dato 10 veces
mayor al valor de humedad real
 La temperatura consta de 16 bits y al igual que la humedad, el valor
proporcionado por el sensor es 10 veces mayor al del valor real, además de
que el bit más significativo en este caso el bit 15, dependiendo su estado
40
proporciona un valor negativo o positivo, si es igual a 1 quiere decir que es
negativo; si es igual a 0 será positivo
 El bit de paridad consta de 8 bits y es la suma de las cadenas de bits de
humedad y temperatura. A continuación, se explica la operación.
Ejemplo de los 40 bits de datos recibidos del DHT22 al microprocesador
Esto es:
0000 0010+1001 0010+0000 0001+0000 1101= 1010001 (Bit de Paridad)
Convirtiendo a decimal los siguientes bits:
Humedad: 0000 0010 1001 0010= 512+128+16+2= 658
Quiere decir que si es 10 veces mayor el valor
Humedad = 65.8%RH
Para la temperatura el procedimiento es similar:
Temperatura: 0000 0001 0000 1101= 256+8+4+1= 269
Por lo tanto
Temperatura = 26.9°C
En caso de que la temperatura sea menor a 0°C el bit 15 de temperatura tendrá un
estado alto 1, por ejemplo, si llegan los 16 bits de temperatura de esta forma:
Temperatura: 1000 0000 0110 0101 = (-) 64+32+4+1= 101 = -10.1°C
Otro caso durante la transmisión es él envió incorrecto de los datos y no coinciden
con el bit de paridad, por ejemplo:
0000 0010+1001 0010+0000 0001+0000 1101= 1010 0010 ≠ 1011 0010 (Error de
validación)
Si esto ocurre se reenviarán los datos.
41
2.3.2 Sensor de luminosidad BH1750
El BH1750 es un sensor de luminosidad ambiental digital que emplea la interfaz
𝐼 2 𝐶 que permite que pueda ser utilizado con casi cualquier microcontrolador y a la
vez puede ser empleado con otros sensores que miden diferentes parámetros,
todos conectados a un mismo microcontrolador, la interfaz 𝐼 2 𝐶 es un bus bastante
poderoso ya que logra la comunicación entre uno o varios dispositivos maestro a
uno o varios esclavos. En la figura 2.15 se muestra el BH1750.
Figura 2.15 Sensor de luminosidad BH1750
Características del dispositivo

Una de sus características es su responsividad espectral ya que se aproxima a la
respuesta del ojo humano, cumpliendo con un amplio rango y una alta resolución
configurable que va de 1 a 65535 lx. Otra de sus características es que contiene
una función de apagado que proporciona un bajo consumo de corriente y una baja
dependencia de las fuentes de luz.
El BH1750 tiene un regulador interno de 3.3 volts por lo que puede ser fácilmente
alimentado con una fuente de 5 volts. Las variaciones de medición son de hasta
+/-20%.
42
Figura 2.16 Diagrama de bloques del BH1750
En la figura 2.16 se muestra un diagrama de los bloques que componen al

dispositivo, comenzando por el fotodiodo (PD) que es el que se encarga de captar
la iluminancia con una responsividad aproximada al del ojo humano, la integración
de un amplificador operacional (AMP) permite la conversión de la corriente que
llega del PD a voltaje. Posteriormente esta implementado un convertidor
análogo/digital (ADC) que obtiene datos digitales de 16 bits. El dispositivo cuenta
con un oscilador interno (OSC) que trabaja a una frecuencia típica de 320 KHz y
es el que proporciona el CLK para la lógica interna en donde se realiza el cálculo
de luz ambiental y de la interface del bus 𝐼 2 𝐶 que proporciona la siguiente
información.
Registro de Datos: Es el registro de los datos de luz ambiental. Su valor inicial
será - 0000 0000 0000 0000 -.
Registro de tiempo de medición: Su valor inicial será - 0100 0101 -. Anexo B
2.3.3 MOSFET IRF540

MOSFET significa: Transistor de efecto de campo semiconductor de óxido
metálico; es útil para aplicaciones que requieren una conmutación rápida, es decir,
una rápida respuesta para cambios variables de potencia donde implícitamente
hablamos de frecuencias elevadas y de este modo es una excelente opción para
implementaciones que trabajan con PWM como es el caso de este trabajo,
además de que sus características lo vuelven un excelente candidato en términos
de potencia. Figura 2.17
43
Figura 2.17 MOSFET IRF540 (TO-220AB)
Características del MOSFET IRF540

A diferencia de los relevadores que funcionan como un switch electromecánico el
mosfet es una llave electrónica que se activa al introducir tensión sobre el pin G
(Gate), de esta manera se genera un campo eléctrico entre las terminales D
(Drain) y S (Source) que permite el libre tránsito de la corriente eléctrica. En la
figura 2.18 se muestra el esquemático del MOSFET IRF540. Anexo C
Figura 2.18 Esquema del MOSFET IRF540
Algunas de sus características principales son:
 𝑉𝐷𝑆 = 100 𝑣𝑜𝑙𝑡𝑠

 𝑅𝐷𝑆 = 0.077 𝑜ℎ𝑚𝑠 𝑐𝑜𝑛 𝑉𝐺𝑆 = 10 𝑣𝑜𝑙𝑡𝑠
 𝐼𝐷 = 28 𝐴𝑚𝑝𝑒𝑟𝑠
 𝑉𝐺𝑆 = 2 𝑎 4 𝑣𝑜𝑙𝑡𝑠 el transistor entra en conducción.
44
Capítulo 3. Arquitectura general del sistema y desarrollo
Capítulo 3: Arquitectura general del sistema y desarrollo

El fin de este trabajo como ya se mencionó en el título y el objetivo, es la
implementación de un sistema de control y monitoreo que con la ayuda de las
diferentes herramientas, aunado con los dispositivos y sus características
mencionados en el capítulo anterior, así como la aplicación de la teoría de las
comunicaciones, se busca aplicar la técnica para proporcionar una alternativa o un
apoyo a los productores.
El sistema fue creado con la capacidad de monitorear la temperatura, la humedad
relativa (HR) y la luminosidad ambiente de una pequeña granja con gallinas, esto
debido a que estos parámetros son fundamentales para la crianza de aves
(gallinas) de producción, ya que, considerando la opinión de algunos especialistas
es que dependiendo de las estaciones del año, la intensidad luminosa deberá ir
variando y mantenerse constante según le convenga al veterinario o al productor,
al igual que deberá estar informado el usuario de la temperatura así como de la
humedad relativa, para averiguar si se deberán tomar acciones en la granja para
generar un ambiente propicio que ayude a la madurez de las aves.
El esquema general del proyecto se muestra en la figura 3.1 donde se pueden
apreciar las diferentes etapas que componen al sistema.
Figura 3.1 Esquema general del sistema de control y monitoreo
45
3.1 App de Control y Monitoreo

Gracias a la aplicación desarrollada en Android el control y monitoreo será
efectuado por medio de un Smartphone, desde donde se recibirá de forma remota
el sensado de la luminosidad en luxes (lx), la temperatura en grados centígrados y
el porcentaje de humedad relativa. En el siguiente diagrama de flujo, figura 3.2, se
muestra el funcionamiento cuando el usuario ingresa a la aplicación.
Figura 3.2 Funcionamiento inicial de la aplicación
46
Después de haber ingresado a la aplicación básicamente su funcionamiento se

caracterizará por dos acciones que permitirán al usuario controlar la iluminación.
1. Encendido y apagado manual (control de luminosidad), con el que por
medio de una barra deslizable dentro de la interfaz de la aplicación se
podrá aumentar o disminuir el nivel de iluminación en luxes de una forma
directa ya que como se muestra en el diagrama, el programa monitorea si
existe una entrada de datos para posteriormente enviar el socket UDP con
los datos.
2. El programa de iluminación general se activará si, el usuario habilita la

casilla de verificación (o checkbox) en la interfaz de la aplicación que
desplegará el formato de los siguientes parámetros:
a) Hora de inicio: Donde el usuario colocará la hora en que comenzará el

programa de iluminación, en este caso una caseta con las aves (por
ejemplo, las 3 a.m.)
b) Umbral de luz: Esta característica permitirá colocar un límite inferior y un
límite superior de intensidad luminosa, esto quiere decir que, si el sensor
detecta un nivel inferior al superior impuesto por el usuario, las luces
comenzaran a iluminar la granja y mantendrá la iluminación entre el
promedio del límite superior e inferior colocados.
c) Cantidad de horas: Este determinará la cantidad de horas de iluminación
que requerirá el usuario en su granja sea de día o de noche, el sistema
tomará en cuenta la luminosidad ambiental y determinará si es
necesario encender la luces o no.
d) Tiempo de encendido: El tiempo de encendido es un factor fundamental
debido a que las luces no pueden encenderse rápidamente debido al
estrés que esto provoca en las aves, según lo requiera el usuario
colocará el tiempo en que la intensidad de las luces ira aumentando
gradualmente hasta cumplir con el promedio del umbral de luz. Esto es
posible gracias a la función de PWM que contiene el microcontrolador
MSP430G2553 del sistema.
e) Tiempo de apagado: Al igual que el tiempo de encendido ocurrirá lo
mismo con el apagado de las lámparas que harán un cambio gradual
según el tiempo que solicite el usuario
Después de una confirmación de los datos ingresados, estos son enviados por
medio del socket TCP hacia el servidor, que desarrollará el proceso del siguiente
diagrama. Figura 3.3
47
Figura 3.3 Establecimiento de conexión entre cliente-servidor
La aplicación intentará realizar la conexión con el servidor, si no es así regresará

notificación de la “No” conexión, ya sea por no contar con conexión a internet en el
momento o porque no existe una respuesta de parte del servidor. En cuanto se
entable una conexión, los datos serán procesados y el servidor obtendrá los datos
del programa de iluminación que el usuario introdujo sobre la aplicación.
El primer hilo de procesamiento que realiza el teléfono celular, tiene como fin leer
los parámetros luminosidad, temperatura y humedad relativa que el servidor
obtiene a través de los sensores, la aplicación espera estos datos a través de un
socket UDP. En este caso se utiliza el puerto 7001, y acomoda los datos en la
48
pantalla del teléfono para ser leídos correctamente por el usuario, si se excede el
tiempo de espera en la recepción o el paquete se pierde, el teléfono desplegará en
pantalla el valor de “-1” para indicar que el dato no llegó o no se recibió
correctamente, y pasará directamente a leer el siguiente dato que corresponde a
la temperatura y humedad relativa, con los cuales repite el proceso anterior. Toda
vez que la función de Recepción de datos sea completada el programa regresará
a comprobar el estado de la conexión para mantener una comunicación
permanente con el servidor, al ser tramas de datos bastante pequeñas apenas del
orden de los kilobits, el intercambio de información entre cliente y servidor no
requiere de un ancho de banda demasiado grande, lo cual agiliza el proceso de
intercambio de datos y permite al usuario economizar en gastos de datos de
internet móvil con la compañía de telefonía celular o internet de su preferencia.
Figura 3.4 Lectura y envió de parámetros lx, C° y HR

49
El siguiente hilo de procesamiento que el teléfono inteligente lleva a cabo a la par

de la lectura de datos, es el monitoreo de la pantalla que está en espera constante
de la interacción por parte del usuario.
Figura 3.5 Proceso de monitoreo de pantalla por parte de App

Una vez que el usuario se ha decidido por introducir datos en la aplicación, podrá
hacerlo de dos maneras, si el checkbox del programa de iluminación se encuentra
desactivado, el usuario tiene la libertad de ajustar la intensidad de los reflectores
mediante una barra deslizable, estos datos se enviarán en tiempo real al servidor
utilizando Sockets que viajan por UDP, al estar la casilla de programa de
iluminación inactiva la aplicación se dedicará a monitorear únicamente entradas
manuales de datos. Cuando el usuario activa el checbox para implementar un
programa de iluminación, la aplicación desplegará un formato con los parámetros
que el usuario deberá indicar al sistema y una vez que el formulario se ha
50
completado, la app enviará al servidor los datos con un socket TCP para asegurar
su correcta emisión y recepción, la barra deslizable que controla la intensidad
luminosa quedará entonces inhabilitada impidiendo que cualquier persona pueda
alterar el programa de iluminación que se encuentra en ejecución. A partir de ese
momento la app ignorará cualquier tipo de intento de entrada manual y se
dedicará enteramente a recibir los datos de Temperatura, Humedad y luminosidad
para mostrarlas al usuario, pero estará siempre monitoreando la suspensión del
programa en cualquier momento para volver a obedecer las entradas manuales de
luminosidad.
3.2 Configuración DNS
Es importante explicar cómo es que se da el establecimiento de la conexión de
internet hacia nuestro servidor, y esto es posible con la obtención de una licencia
de nombre de dominio. Hecho que se realizó por medio de un proveedor NO-IP
para que a través de él se lleve a cabo la conectividad entre nuestros dispositivos
cliente/servidor de manera simple y remota, dicha licencia se compró por un
periodo de 5 años.
La licencia cuenta con un software que se instaló en nuestra Raspberry, cuya
función principal es la de recalcular la dirección IP pública de nuestro servidor
cada 5 minutos y que de esta manera los datos lleguen al servidor, aunque cambie
la IP. La función del DNS es traducir un conjunto de palabras o un nombre de
dominio en una dirección IP para que de esta manera pueda ser localizado
nuestro servidor desde internet.
En la siguiente imagen, figura 3.5, se puede ilustrar como se está ejecutando la
aplicación del DNS en la raspberry, además de indicar que existe un proceso de
No-IP ejecutándose, también se puede visualizar la cuenta de correo que se está
utilizando, que para este caso utilizamos armandohdzbal@hotmail.com. En el
quinto renglón se tiene la dirección IP que se está utilizando y en la parte inferior
aparece el tiempo que tarda en recalcular la dirección IP que es justamente de 5
minutos.
Figura 3.6 Software del DNS ejecutándose

51
En la siguiente imagen, figura 3.6 se muestra la interfaz de No-IP donde se dio de

alta el nombre de dominio
Figura 3.7 No-IP
3.3 Configuración de la DMZ

La DMZ como se muestra en la figura 3.1 está conformada por la Raspberry, el
módulo Arduino y la tarjeta MSP; el switch representa la manera en que estos
están dentro de una misma red de área local (LAN) y la manera en que se
comunican es por medio de los puertos USB de tal forma que toda la actividad de
las tarjetas desarrolladoras llega a la Raspberry que es nuestro servidor de donde
se recibe y se envía la información.
La DMZ tiene una función muy importante dentro de nuestro sistema ya que
permite el acceso desde el exterior de otros dispositivos que llamaremos clientes
(como es el caso del smarthphone con la app que se desarrolló), pero al mismo
tiempo quedara expuesto el servidor a internet, sin embargo, al generarse la zona
desmilitarizada desde nuestro router se protege a los otros dispositivos que se
encuentran dentro de la misma red local - así como se mencionó en el apartado
teórico - si alguien adquiere control de la DMZ no podrá acceder a los demás
dispositivos, además de que es necesaria esta configuración debido a que debe
registrarse una IP fija para el servidor y que de esta forma sea posible localizarlo.
Como sabemos el proveedor de internet es quien proporciona una IP a todos los
dispositivos que se conectan, lamentablemente esta no es fija y en cuanto se
pierde la conexión o se reinicia el router a la primera o en repetidas ocasiones,
este podría perder la IP original asignándola a otro equipo, la cual tiene el acceso
inmediato a nuestra DMZ, algo que es sumamente arriesgado. Justamente para
evitar este problema fue que se consiguió la licencia de nombre de dominio para
52
nuestro servidor Raspberry que funciona sin una IP fija, ya que por medio del
software se calcula cada 5 minutos que IP tiene asignado nuestro dominio y de
esta manera es posible dar de alta nuestro nombre de dominio sin ningún
inconveniente.
Para realizar la configuración de la DMZ solo se requiere entrar a la interfaz del
modem en el explorador y encontrar la opción que diga DMZ, al ingresar a esta
opción mostrara las opciones para añadir un dispositivo como se muestra en la
figura 3.7. Posteriormente se tendrá que abrir un puerto para que por medio de
este nuestro dispositivo tenga salida hacia el exterior. Finalmente seleccionaremos
el checkbox que habilitara la DMZ.
Figura 3.8 Configuración de la DMZ
3.4 Integración de Arduino y el sensor de BH1750

El proceso de monitoreo se lleva a cabo por medio de dos diferentes sensores que
están acoplados a cada uno de los módulos que son Arduino y el MSP430G2553.
Comenzando con el sensor de luminosidad BH1750 que se encuentra en el
Arduino UNO, proporciona la información de la luminosidad ambiente dentro de la
caseta con aves. La configuración para este dispositivo no es muy compleja
debido a que existe una librería de Arduino justo para este sensor de luminosidad
con la cual es posible traducir los datos que llegan del sensor en luxes hacia la
Raspberry.
53
En el siguiente diagrama de flujo, figura 3.8, se muestra cómo es que Arduino

hace la lectura de luminosidad, inicializando el puerto serial y la interfaz I2C,
preguntando si la interfaz serial está disponible - de estarlo - el siguiente paso a
seguir es comprobar si hay presencia de luz - de ocurrir lo contrario - dará por
finalizada la ejecución notificando al servidor.
Posteriormente se va a verificar que este el sensor disponible para proceder a la
lectura de la luminosidad y con ello realizar la lectura correspondiente para
almacenarla y enviarla al servidor, generando un ciclo que enviara la información
de forma constante.
Figura 3.9 Diagrama de flujo del funcionamiento de Arduino con el sensor BH1750
54
3.5 Integración del MSP430G2553

El microcontrolador MSP430g2553 se encarga junto con el sensor DHT22 del
monitoreo de la temperatura y de la humedad relativa, pero al mismo tiempo el
MSP430 es el encargado de encender o apagar las luces con los parámetros que
el usuario solicita por medio de un amplio proceso que se muestra en la figura 3.9.
Para empezar el microcontrolador inicializa el puerto serial de comunicación
verificando su estado, si está disponible comprobara la bandera del programa de
iluminación, es decir, comprobara si el usuario ya mando los parámetros desde la
app acerca del programa, si no es así la siguiente opción del microcontrolador es,
verificar si el usuario a introducido algún valor de luminosidad del control de
encendido y apagado manual, si no es así este enviara la lectura del sensor de
Temperatura y HR, pero si el usuario ha deslizado desde la app el control manual
de iluminación, al micro le corresponde enviar la señal para encender las lámparas
con el convertidor Analógico Digital.
Ahora bien, volviendo a la bandera del programa de iluminación, si el usuario
introdujo los parámetros para iniciar dicho programa, el microcontrolador leerá el
dato de tiempo de encendido/apagado. Donde el dato solicitado debe ser mayor a
1 minuto y menor a 60 minutos, sea tanto para el encendido como el apagado de
luces. Si es correcto el dato, este dividirá el número 255, sobrescribiendo el
resultado en la misma variable del dato original, el numero 255 es el intervalo
máximo que ocupa el PWM para llegar al 100 % de su ciclo de trabajo como se
explicó en el capítulo 2, por medio de una rutina de tiempo podemos hacer que
este aumente de 0 a 255 y de esta forma las luces se encenderán o se apagarán
de forma gradual pero antes de eso se debe generar un retardo que vaya acorde
al tiempo en minutos solicitado en el dato original. El comando delay() del MSP de
acuerdo a sus especificaciones técnicas cada unidad equivale a 1 milisegundo
esto quiere decir que si queremos generar un retardo de 1 segundo colocaremos
delay(1000), sin embargo como se explica en la figura 3.4 el número que
requerimos es 60000, ya que equivale a 1 minuto. De esta manera se genera la
variable retardo que le indicara al PWM en que momento aumentar una unidad.
Por ejemplo. Si se desea generar un retardo de 30 minutos:
255
𝐷𝑎𝑡𝑜 = = 8.5
30 𝑚𝑖𝑛𝑢𝑡𝑜𝑠
60000
𝑅𝑒𝑡𝑎𝑟𝑑𝑜 = ≈ 7059 ≈ 7.059 𝑠𝑒𝑔𝑢𝑛𝑑𝑜𝑠
8.5
Esto quiere decir que cada 7.059 segundos aproximadamente, aumentara una
unidad el PWM hasta llegar a 255 donde las luces encenderán gradualmente
hasta llegar a su máximo ciclo de trabajo.
55
Figura 3.10 Diagrama de funcionamiento del MSP con el sensor DHT22
56
Si después de tener un programa de iluminación activo ejecutándose en el

sistema, el usuario decidiera de pronto finalizarlo, el microcontrolador suspenderá
el ajuste automático en la iluminación mediante una interrupción provocada por un
pulso de 3.3 Volts proveniente de la Raspberry. El programa pasa directamente a
esperar un valor en la intensidad de iluminación introducido manualmente por el
usuario hasta que se le indique el inicio de un nuevo programa de iluminación y
deba calcular un nuevo retardo. La aplicación de la interrupción es de suma
importancia debido a que los tiempos en que permanece dormido con el comando
delay(X) pueden llegar a ser muy prolongados y durante ese tiempo no
responderá a ninguna acción con excepción de las interrupciones. La frecuencia
con la cual se actualiza el dato de temperatura y humedad relativa hacía el
servidor se verá afectado directamente por la implementación de un programa de
iluminación, ya que durante la ejecución de los programas el microcontrolador solo
consultará el dato al sensor cada vez que finalice su tiempo de retardo, sin
embargo al ser una variable que no se controla es un dato meramente informativo
por lo cual la velocidad de actualización no es un parámetro crítico para el
funcionamiento del sistema, no así el dato de iluminación el cual es esencial y se
ejecuta en otro dispositivo (el Arduino) ante la incapacidad del microcontrolador de
realizar procesamiento paralelo.
3.6 Etapa de Potencia

La etapa de potencia dentro de la arquitectura del sistema como se mostró en la
figura 3.1 corresponde al control de iluminación que es posible con el
MSP430G2553.
Es importante el PWM dentro de la etapa de potencia ya que es por esta función
que se decidió ocupar el MOSFET IRF540 que con sus características de
conmutación rápida y su aguante de potencia permite el encendido o apagado
gradual de las luminarias que se ocuparon.
Los reflectores o luminarias que se emplearon manejan un voltaje de 12 volts y
una potencia de 20 watts. En la figura 3.5 se muestra el esquemático de conexión.
57
Figura 3.11 Esquema de conexiones de luminarias

Tomando en cuenta que la corriente de drenaje 𝐼𝐷 viene dada por la fuente de
voltaje de la lámpara y de la potencia de la misma podemos destacar con un breve
calculo que:
𝑃𝑟𝑒𝑓𝑙𝑒𝑐𝑡𝑜𝑟 = 𝐼𝐷 𝑉𝐶𝐷
𝑃𝑟𝑒𝑓𝑙𝑒𝑐𝑡𝑜𝑟 20 𝑤𝑎𝑡𝑡𝑠
𝐼𝐷 = = = 1.66 𝐴𝑚𝑝.
𝑉𝐶𝐷 12 𝑣𝑜𝑙𝑡𝑠
Considerando que el MOSFET IRF540 soporta una 𝐼𝐷 máxima de hasta 28

ampers y entra en conducción aplicándole una tensión a la compuerta G de 2 a 4
volts, el MOSFET es más que suficiente para los requerimientos de la etapa de
potencia, ya que el microcontrolador trabaja con una tensión de 3 volts.
3.7 Integración Del Servidor Raspberry Pi

La Raspberry Pi es el corazón y el cerebro que coordina todas las acciones en
este sistema, como mencionamos previamente, es una microcomputadora de
arquitectura ARM que tiene muchas ventajas sobre los servidores convencionales
en aplicaciones que requieren bajo poder de procesamiento como es el caso de
este sistema. Posee muchas ventajas sobre las Workstation convencionales
comenzando por el tamaño, sus dimensiones son similares a la palma de la mano
por lo cual puede adaptarse a cualquier espacio, el consumo de energía es muy
bajo en comparación con un CPU convencional, no libera calor de forma
considerable ni requiere elementos mecánicos como ventiladores o dispositivos de
58
almacenamiento magnético lo cual resulta sumamente ventajoso para los

propósitos de este proyecto.
Los procesos que realiza el servidor son variados y son los más complejos de todo
el sistema, pues mantiene una compleja relación con todos los dispositivos que
integran este sistema. Al inicio el programa en el servidor estará en espera
permanente por la recepción del Socket de conexión que emite el cliente, una vez
que la conexión se ha establecido el programa abre 2 hilos de procesamiento
paralelo, en el primero estará leyendo continuamente los datos de temperatura,
luminosidad y humedad relativa que obtiene de los microcontroladores y los envía
a través de Sockets UDP al dispositivo móvil, si la conexión Serial entre el servidor
y los microcontroladores llegase a fallar, esto requeriría de un reinicio manual por
parte del soporte técnico encargado del sistema.
Figura 3.12 Proceso inicial en Servidor
59
Una de las partes más complejas de y desafiantes de este proyecto es el hilo que
se encarga de monitorear los datos enviados por el usuario. En principio se asume
que el programa de iluminación estará inactivo y en espera de que el usuario
introduzca los parámetros deseados para personalizar su propio programa de
iluminación, mientras tanto en usuario tiene la posibilidad de controlar la intensidad
de luz a su voluntad desde un punto remoto, con una barra deslizable en la
aplicación es la persona encargada del uso del sistema quien fija un valor a la
intensidad de los reflectores y en el modo manual este valor permanecerá hasta
que sea alterado nuevamente por el usuario.
El programa de iluminación sin embargo al ser un sistema autónomo considera
varias variables para su correcto funcionamiento, es la herramienta más práctica
de este proyecto y lo cual facilita al usuario algunos factores importantes en la
crianza de las gallinas productoras. Toda vez que un nuevo programa de
iluminación sea activado el usuario debe ingresar los parámetros iniciales por
medio de la App, estos datos una vez que sean completados serán enviados al
servidor mediante un Socket TCP para asegurar el correcto envío y recepción.
Figura 3.13 Monitoreo de datos de usuario desde el servidor
60
A partir de este momento la barra de control manual será inhabilitada de la

aplicación y bajo ninguna circunstancia podrá alterarse la iluminación de forma
manual hasta que el programa sea desactivado.
Figura 3.14 Implementación del programa de iluminación en el servidor
61
Cuando el servidor ha recibido los parámetros mediante el Socket TCP, el servidor

debe hacer uso de ciertos recursos externos como son el servidor NTP instalado
por default y las librerías time con las cuales puede consultar la hora desde la red
de internet, utiliza los parámetros introducidos por el usuario y los valores de
luminosidad que recibe desde el sensor por parte del Arduino. El primer paso será
entonces enviar el dato con el tiempo de encendido al microcontrolador MSP430
para que este realice su parte de procesamiento y calcule los pasos por minuto
que tendrá que avanzar en el valor de luminosidad de las lámparas para llegar a
encenderlas en el tiempo deseado por el usuario, la razón de esto es que no se
pueden encender las lámparas a toda su luminosidad en un instante, esto podría
provocar estrés en las gallinas productoras lo que repercutiría negativamente en la
producción, hacerlo de manera lenta simulará los efectos del amanecer y permitirá
al sistema regular la intensidad de luz al valor deseado. Mientras el
microcontrolador ha calculado los pasos por minuto y se encuentra a la espera de
las órdenes del servidor para incrementar o decrementar la intensidad de luz en el
reflector, el servidor obtiene muestras de la intensidad de luz medida por el sensor
y obtiene el promedio de los valores leídos durante un minuto, en base a ello
comparará ese valor y se encuentra entre el rango inferior y el rango superior
elegidos por el usuario, no llevará a cabo ninguna acción, de manera contraría si
esta condición no se cumple el programa pasará a comprobar si la intensidad leída
a través del sensor es menor al límite inferior, de cumplirse está condición el
servidor ordenará al micro incrementar la intensidad de luz, si no se cumple
entonces pasará a comprobar si la intensidad es mayor al límite superior, si está
última condición se cumple el servidor ordenará al MSP430 decrementar la
intensidad de luz, el primer caso puede darse al anochecer cuando hay poca luz
en el ambiente y el caso último sucederá en cada amanecer con lo cual el sistema
reducirá la luz en los reflectores hasta dejarlos totalmente apagados y dar paso a
la iluminación natural para con esto ahorrar energía. Al finalizar este proceso de
comprobación el sistema comprobará siempre la conexión con el cliente para
verificar que el programa no haya sido suspendido.
3.8 Instalación del sistema
Para la implementación de nuestro sistema de control y monitoreo fue necesario
realizar la instalación eléctrica que abastecería de energía a nuestros dispositivos,
esto fue realizado por electricistas que colocaron tanto la alimentación a 127 volts
que llega a la caseta, como la pastilla termo magnética de protección.
Posteriormente se ubicó una zona adecuada dentro de la caseta para fijar nuestro
gabinete IP65 donde colocaríamos las tres tarjetas que son: el servidor (Rapberry
Pi), la tarjeta entrenadora Arduino y el microcontrolador MSP430g2553 – todos
ellos con una fuente de alimentación de 5 v a 3 A -. También se incorporó una
fuente de alimentación de 12V a 6A para alimentar los reflectores de iluminación.
62
Para evitar que el agua se meta dentro del gabinete se emplearon conectores tipo
glándula que sirven como sello del interior al exterior al igual que también sujetan
a los cables evitando que se desconecten por movimientos bruscos. Figura 3.11
Figura 3.15 Conectores Glandula.

El gabinete ya montado en un muro quedo como se muestra en la figura 3.12.
Figura 3.16 Gabinete IP65

Se puede apreciar de un lado del gabinete como entran los cables de corriente
(blanco y negro) mientras que del otro extremo entra el cable de red (Azul) que
está conectado directamente de la Raspberry al modem de la casa,
aproximadamente se utilizaron 12 metros de cable de red.
Otra de las aberturas del gabinete dirige los cables dentro de una manguera
corrugada flex que van conectados a los sensores. Para fijar estos solo se
atornillaron a un palo de madera que sostiene la malla de gallinero. Figura 3.13
63
Figura 3.17 Sensores de monitoreo sujetos a la madera
Se instalaron los reflectores dentro de la caseta fijándolos en la parte superior de

una de las paredes donde pudieran iluminar bien la zona con las gallinas. Figura
3.18
Figura 3.18 Caseta con las gallinas
64
Capítulo 4. Pruebas realizadas, resultados y costos
Capítulo 4: Pruebas realizadas, resultados y costos

En este capítulo se describen las pruebas y resultados arrojados por el sistema
que pueden ser fácilmente visualizados por el usuario.
4.1 Interfaz de la App finalizada
Como se explicó en el capítulo 3 (subtema 3.1) el funcionamiento y las
características de la aplicación que se desarrolló para el smarthphone, la interfaz
final para el usuario quedo de la siguiente forma. Figura 4.1.
Figura 4.1 Interfaz final del usuario
De esta forma el usuario es capaz de controlar la luminosidad de forma manual o

con el programa de iluminación habilitando solamente el botón desplegable,
introduciendo los parámetros según le convengan al productor.
Como parte de las pruebas que se realizaron, la aplicación fue inicializada en el
momento en que el WiFi no estaba disponible arrojando el mensaje “No hay
conexión a casa” en naranja. Figura 4.2.
65
Figura 4.2 Sin conexión Wi-Fi
En el caso de no contar con señal de datos móviles la aplicación mostrará el

siguiente mensaje “No hay conexión” en color rojo.
Figura 4.3 Sin conexión de datos móviles
66
En el momento de restablecerse la conexión a internet la aplicación le avisa al

usuario “Conexión Restablecida” en azul como se muestra en la Figura 4.4
Figura 4.4 Conexión restablecida
Como se explicó en el diagrama de flujo (Figura 3.4) de la App, los datos al no ser
recibidos de forma correcta por una desconexión, el menú en el apartado de
luminosidad desplegara un “-1” indicando que no han llegado los datos de
monitoreo de luminosidad desde el servidor
Para comprobar la conectividad que existe de internet hacia nuestro servidor solo
se requiere ingresar al símbolo de sistema y mandar un ping al nombre de dominio
de nuestro servidor de la siguiente manera. Figura 4.5.
67
Figura 4.5 Ping a servidor-pi.ddns.net
Se muestra la dirección IP actual del servidor, su tiempo de respuesta, la cantidad

de paquetes enviados y perdidos.
4.2 Etapa de Potencia
Se probaron primero los circuitos con el reflector primero de forma experimental en

una tableta protoboard, las pruebas realizadas con el microcontrolador fueron
exitosas.
Figura 4.6 Etapa de potencia experimental
68
Se midió la modulación a la salida de la etapa de potencia para descartar que el

transistor Mosfet distorsionara la forma de la onda o introdujera picos de voltaje al
sistema, las pruebas resultaron exitosas y el control de luminosidad se pudo
realizar a la perfección.
Figura 4.7 Señal de salida de la etapa de potencia
En la figura 4.8 se puede observar el control de intensidad de luz sobre el reflector

cuando este se encuentra a la mitad de la luminosidad máxima.
Figura 4.8 Control de intensidad sobre el reflector
69
4.3 Tabla de Costos

Un proyecto de esta naturaleza que considera tantos dispositivos de Hardware
tiene costos normalmente elevados, en el caso de este proyecto hicimos el
esfuerzo por adecuar nuestro proyecto con costos reducidos, buscando materiales
y dispositivos de calidad óptima de acuerdo a las necesidades de este proyecto, lo
más costoso sin embargo fue la licencia del servidor DNS la cual desde nuestro
punto de vista ha sido una buena inversión para proyectos futuros. A continuación,
se enlista los elementos que representaron costos en este proyecto y su valor en
moneda nacional.
Tabla de costos
Tabla 4.1 Tabla de costos
70
CONCLUSIONES
Se requirió una gran labor para llevar a cabo este proyecto haciendo uso de
diferentes áreas de la ingeniería, tal es el caso de la electrónica, la programación y
las comunicaciones que al final fueron aplicadas más allá de lo que compete a
nuestra carrera dando lugar a un tema interdisciplinario, brindando esta tecnología
a la industria avícola. Gracias a la jugosa variedad de herramientas
proporcionadas por estas disciplinas se logró aplicar las técnicas pertinentes que
nos permitieron dar un mejor manejo y una mejor respuesta a los detalles que se
iban presentando.
Bajo la implementación de este sistema hemos comprobado que tanto los
sensores que se utilizaron han sido de las mejores opciones ya que brindan la
información necesaria para este proyecto, en conjunto con todos los dispositivos
que han potencializado este sistema, además es importante resaltar el buen
funcionamiento que está brindando la aplicación ya que se puede comprobar que
el control de la intensidad de luminosidad está siendo muy efectiva para nuestros
fines.
71
Bibliografía
[1] Black, U. Tecnologías Emergentes Para Redes de Computadoras, páginas419-
432. Prentice Hall Hispanoamericana, USA, segunda edición, 1999.
[2] Merilee Ford, S. S., H. Kim Lew y Stevenson, T. Tecnologías de
interconectividad de redes, páginas 37-50, 87-106, Prentice Hall, México, primera
edición, 1998.
[3] Raya, J. L. y Rodrígo, V. Domine TCP/IP, página 495. Universidad de
Cantabria, Espana, primera edición, 1998.
[4] Tanenbaum, A. S. Redes de Computadoras, páginas 521_543. PrenticeHall
Hispanoamericana, USA, tercera edición, 1996.
[5] Comer, D. E. Redes de Computadoras, Internet e Interredes, páginas 340_387.
Prentice Hall Hispanoamericana, USA, primera edición, 1997.
[6] Comer, D. E. Redes Globales de información con Internet y TCP/IP, páginas
337_361. Prentice Hall Hispanoamericana, USA, tercera edición,1996.
[7] Lee, T. y Davies, J. Microsoft Windows 2000 TCP/IP Protocolos y Servicios.
Referencia Técnica, páginas 89, 341-356, McGraw Hill, USA, primera edición,
2000.
[8] Internet Engineering Task Force, 2018, https://tools.ietf.org/html/rfc791
[9] Stallings William Comunicaciones y redes de computadores, 6ta edicion
[10] Institute of Electrical and Electronics Engineers, 2018,
https://ieeexplore.ieee.org/document/6012487/
[11] Duque, R. G. Python para todos, páginas 92_96. Creative Commons
Reconocimiento 2.5e, España, versión 1 edición, 2008.
[12] Hirzel, Timothy. 2018, PWM, http://energia.nu/guide/tutorial_pwm/
[13] 2018, ARDUINO UNO REV3, https://store.arduino.cc/usa/arduino-uno-rev3
[14] Into the world, 2018, http://inworldconnect.blogspot.com/2011/06/el-
encabezado-en-el-modelo-osi.html
72
Glosario
1. OSI (Interconexión de Sistemas Abiertos)
2. IEEE (Instituto de Ingenieros en Electrónica y Electricidad)
3. LLC (Control de Enlace Logico)
4. MAC (Control de Acceso al Medio)
5. IEEE 802.2 (Define el control de enlace logico LLC)
6. IEEE MAC (Estandar que define direcciones mac)
7. PDU (Unidad de Datos de Protocolo)
8. Firewalls (Es una parte de un sistema o una red que está diseñada para
bloquear el acceso no autorizado)
9. TCP (Protocolo de Control de Transmision)
10. UDP (Protocolo de Datagramas de Usuario)
11. EBCDIC (Código de Intercambio Decimal de Código Binario Extendido)
12. ASCII (Código Estándar Estadounidense para el Intercambio de
Información)
13. Software (Equipamiento lógico e intangible de un ordenador)
14. SMTP (Protocolo Simple de Transferencia de Correo)
15. HTTP (Protocolo de Transferencia de Hiper Texto)
16. FTP (Protocolo de Transferencia de Archivos)
17. FTAM (Gestión y Acceso de Transferencia de Ficheros)
18. POP (Protocolo de Oficina Postal)
19. IMAP (Protocolo de Acceso a Mensajes de Internet)
20. SSH (Secure SHell)
21. Telnet (Red de Telecomunicacion)
22. UNIX (Sistema operativo portable, multitarea y multiusuario)
23. TCP/IP (Protocolo de Control de Transmision/Protocolo de Internet)
24. DARPA (Agencia de Proyectos de Investigación Avanzados de Defensa)
25. PC (Computadora Personal)
26. ARPANET (Red de la Agencia de Proyectos de Investigación
Avanzados)
27. CSMA/CD (Acceso Múltiple con Escucha de Portadora y Detección de
Colisiones)
28. MTU (Unidades de transmisión máxima)
29. TFTP (Protocolo de Transferencia de Archivos Trivial)
30. IETF (Grupo de Trabajo de Ingeniería de Internet)
31. DNS (Sistema de Nombres de Dominio)
32. BIND (Dominio de nombre de Internet de Berkeley)
33. Hardware (Es la parte física de un ordenador o sistema informático)
34. DMZ (Zona Desmilitarizada)
73
Anexo A
74
Anexo B
75
76
Anexo C
77
78

Tesis Final

Cargado por

Copyright:

Formatos disponibles

Tesis Final

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Final

Cargado por

Copyright:

Formatos disponibles

INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA

UNIDAD PROFESIONAL “ADOLFO LÓPEZ MATEOS” ZACATENCO

SISTEMA DE CONTROL Y MONITOREO REMOTO PARA UNA GRANJA DE

INGENIERO EN COMUNICACIONES Y ELECTRÓNICA

ARMANDO HERNÁNDEZ BALDERAS

M. EN C. JOSÉ ERNESTO ROJAS LIMA

México, CDMX Agosto, 2018

1.1 Protocolos, topologías y servicios………………………………………………………………………...........1

1.1.1 Protocolo de comunicación……………………………………………………………………........1

1.1.2 Topología y medios compartidos.............................................................................................1

1.1.3 Relación entre Servicios y Protocolos.....................................................................................1

1.1.4 Modelos de Referencia............................................................................................................2

1.2 El Modelo OSI...........................................................................................................................................2

1.2.1 Capas Física y Enlace.............................................................................................................4

1.2.2 Capas de Red y Transporte.....................................................................................................6

1.2.3 Capas de Sesión, Presentación y Aplicación...........................................................................6

1.3 El modelo TCP/IP......................................................................................................................................9

1.3.1 Capas Física y Red................................................................................................................10

1.3.2 Capas de Internet y Transporte..............................................................................................10

1.3.3 Capa de Aplicación.................................................................................................................10

1.4 Familia de protocolos TCP/IP..................................................................................................................11

1.4.1 Protocolo de Control de Transmisión.....................................................................................11

1.4.2 Protocolo IP............................................................................................................................12

1.4.2.1 Funciones de IP.....................................................................................................15

1.4.3 Suma de verificación (Checksum)..........................................................................................15

1.4.4 Protocolo UDP........................................................................................................................15

1.4.5 Direccionamiento IP................................................................................................................16

1.5 Protocolo DNS.........................................................................................................................................16

1.5.1 Espacio de Nombres de Dominio...........................................................................................17

1.6 Arquitectura DMZ.....................................................................................................................................18

1.7.1 Definición de un Socket..........................................................................................................20

CAPITULO II Requerimientos de Hardware, dispositivos de estado sólido y herramientas de programación...22

2.1 Herramientas de programación...............................................................................................................22

2.1.1 Sistema Operativo ANDROID................................................................................................22

2.1.3 Introducción al desarrollo de aplicaciones en Android Studio................................................25

2.1.3.1 App Manifest.........................................................................................................29

2.1.3.2 Construyendo una App con Android Studio..........................................................30

2.1.4.1 Lenguaje interpretado ó de script.........................................................................31

2.1.4.2 Transmisión de Datos...........................................................................................31

2.1.5 Servicio no – IP......................................................................................................................32

2.1.5.1 Dyn DNS...............................................................................................................32

2.2 Requerimientos de Hardware..................................................................................................................33

2.2.1 Raspberry Pi...........................................................................................................................33

2.2.2 Microcontrolador MSP430G2553...........................................................................................34

2.2.4 Modulación por ancho de pulsos (PWM)................................................................................35

2.2.5 Arduino UNO..........................................................................................................................37

2.3.1 Sensor de temperatura y humedad relativa DHT22...............................................................38

2.3.2 Sensor de luminosidad BH1750.............................................................................................42

2.3.3 MOSFET IRF540....................................................................................................................43

CAPITULO III Arquitectura general del sistema y desarrollo…………………………………………………....45

3.1 App de Control y Monitoreo……………………………………………………………………………….46

3.2 Configuración DNS…………………………………………………………………………………………51

3.3 Configuración de la DMZ…………………………………………………………………………………..52

3.4 Integración de Arduino y el sensor de BH1750………………………………………………………....53

3.5 Integración del MSP430G2553…………………………………………………………………………...55

3.6 Etapa de Potencia……………………………………………………………………………………….....57

3.7 Integración Del Servidor Raspberry Pi…………………………………………………………………...58

3.8 Instalación del sistema………………………………………………………………………………….....62