Sistema de monitoreo para colmenas simapmx-2020 basado en IoT-FIWARE

Vista previa del material en texto

INFOTEC CENTRO DE INVESTIGACIÓN E
INNOVACIÓN EN TECNOLOGÍAS DE LA
INFORMACIÓN Y COMUNICACIÓN
DIRECCIÓN ADJUNTA DE INNOVACIÓN Y
CONOCIMIENTO
GERENCIA DE CAPITAL HUMANO
POSGRADOS
"SISTEMA DE
MONITOREO PARA
COLMENAS
SIMAP-MX2020
BASADO EN
IoT-FIWARE"
IMPLEMENTACIÓN DE UN PROYECTO LABORAL
para obtener el grado de MAESTRO EN SISTEMAS
EMBEBIDOS
Presenta:
Isidro Zavaleta Ochoa
Asesores:
Dr. Daniel Villanueva Vásquez
Dr. José Sebastián Gutiérrez Calderón
Ciudad de México, Junio, 2020
incoTEC 
AD 
AUTORIZACIÓN DE IMPRESIÓN Y NO ADEUDO EN BIBLIOTECA
MAESTRÍA EN SISTEMAS EMBEBIDOS
Ciudad de México, 16 de junio de 2021 
INFOTEC-DAIC-GCH-SE-194/2021. 
La Gerencia de Capital Humano / Gerencia de Investigación hacen constar que 
el trabajo de titulación intitulado 
SISTEMAs DE MONITOREO PARA COLMENAS SIMAP-Mx2020 BASADO 
EN IOT-FIREWARE 
Desarrollado por el alumno Isidro Zavaleta Ochoa y bajo la asesoría del Dr. 
Daniel Villanueva Vásquez y el Dr. José Sebastián Gutiérrez Calderón; 
cumple con el formato de biblioteca. Por lo cual, se expide la presente 
autorización para impresión del proyecto terminal al que se ha hecho mención. 
Asimismo se hace constar que no debe material de la biblioteca de INFOTEC. 
Vo. Bo. 
Lic. Juan Ramón Abarca Damián 
Coordinador de Biblioteca
Anexar a la presente autorización al inicio de la versión impresa del trabajo referido
que ampara la misma. 
C.p.p Servicios Escolares
Agradecimientos
Quisiera agradecer a todas aquellas personas que han estado participado en el desa-
rrollo del presente proyecto compañeros y compañeras les agradezco, ha sido un largo
recorrido el poder concebir esta propuesta que poco a poco se fue materializando y
gracias a la voluntad y el esfuerzo inquebrantable me ha sido posible llegar a este pun-
to de termino,creo firmemente en que el conocimiento se genera en comunidad y que
todos aprendemos en los hombros de los grandes, gracias a mi familia, mama y papa
que con su consejo y apoyo durante la adversidad me dieron fuerza y aliento, a mis
colegas y colaboradores de INFOTEC por su invaluable apoyo y participación, espero
que el presente trabajo gire se comparta y promueva fundamentalmente la base de fu-
turos desarrollos que tengan como finalidad el promover la apicultura de precisión y la
preservación de la abeja, a todos los apicultores que me brindaron la oportunidad de
aprender, colaborar y ser parte por un momento de su vida y motivarme a continuar
por este maravilloso camino les agradezco.
Tabla de contenido
Introducción 1
Capítulo 1: Contexto 3
1.1 Breve descripción del problema . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Capítulo 2: Marco teórico 8
2.1 Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Manejo de Información de contexto en fiware . . . . . . . . . . . . . . 11
2.1.2 Elementos de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 Actores Involucrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.4 Arquitectura general del Publish/Subscribe Contex Broker . . . . . . 14
2.1.5 Cloudino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.6 Wifi Cloud Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.7 Apicultura de Precisión . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.8 Áreas de oportunidad y objetos de estudio empleando la apicultura
de precisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.9 Ecosistema FIWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.10 Análisis de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.11 Perspectiva del producto . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.12 Funcionalidad del producto . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.13 Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.14 Suposiciones y dependencias . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.15 Requerimientos Funcionales . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.16 Requerimientos No Funcionales . . . . . . . . . . . . . . . . . . . . . 30
2.1.17 Descripción de la solución tecnológica . . . . . . . . . . . . . . . . . 33
2.1.18 Modelos Matemáticos Predictivos . . . . . . . . . . . . . . . . . . . . 34
Capítulo 3: Metodología y Desarrollo 36
3.1 Metodología para el diseño y construcción de sistemas IoT . . . . . . . . . . 36
3.2 Diseño de la Solución Tecnológica Propuesta . . . . . . . . . . . . . . . . . . 38
3.2.1 Arquitectura para el diseño del SIMAP-MX2020 . . . . . . . . . . . . . 38
3.3 Diagrama a bloques del Hardware Embebido . . . . . . . . . . . . . . . . . . 39
3.3.1 Diseño del Circuito Electrónico . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Desarrollo de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Capítulo 4: Implementación y Resultados 50
4.1 Implementación de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.1 Diseño de la solución tecnológica . . . . . . . . . . . . . . . . . . . . . 50
4.2 Implementación de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3 Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Conclusiones 70
Bibliografía 72
Anexo I 77
Anexo I : Transductores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Anexo II 80
Anexo II : Articulo Internet of Things: Low Cost Monitoring BeeHive System
using Wireless Sensor Network . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Anexo III 88
Anexo III: Esquema Eléctrico SIMAP-MX2020 . . . . . . . . . . . . . . . . . . . . 88
Índice de figuras
1. Figura 1.Arquitectura de FIWARE . . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Figura 2.Arquitectura general del Publish/Subscribe Contex Broker . . . . 15
3. Figura 3.Arquitectura Cloudino. . . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Figura 4.Pinout WCC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Figura 5.Arquitectura de la Aplicación . . . . . . . . . . . . . . . . . . . . . . 23
6. Figura 6.Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Figura 7.Porta núcleo langstroth. . . . . . . . . . . . . . . . . . . . . . . . . . 33
8. Figura 8.Metodología de desarrollo. . . . . . . . . . . . . . . . . . . . . . . . 36
9. Figura 9. Arquitectura del sistema. . . . . . . . . . . . . . . . . . . . . . . . . 38
10. Figura 10.Diagrama a bloques de la arquitectura de hardware. . . . . . . . 40
11. Figura 11.Configuración Maestro Esclavo. . . . . . . . . . . . . . . . . . . . 41
12. Figura 12.Fotorresistencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
13. Figura 13.Divisor de Tensión. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
14. Figura 14.Modulo de Desarrollo GY-21P . . . . . . . . . . . . . . . . . . . . . 44
15. Figura 15.Conexiòn modulo GY-21P y ATMEGA328. . . . . . . . . . . . . . . 44
16. Figura 16.Calibración in situ. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
17. Figura 17.Arreglo de modulo Hx711 y celdas de carga. . . . . . . . . . . . . 46
18. Figura 18.Celdas de carga instrumentadas. . . . . . . . . . . . . . . . . . . . 47
19. Figura 19.Base con transductores de peso. . . . . . . . . . . . . . . . . . . . 47
20. Figura 20.Diagrama de flujo software. . . . . . . . . . . . . . . . . . . . .. . 48
21. Figura 21.SIMAP-MX2020 v1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
22. Figura 22.Implementación SIMAP-MX2020 V1 . . . . . . . . . . . . . . . . . 51
23. Figura 23.Prueba SIMAP-MX2020 V1 . . . . . . . . . . . . . . . . . . . . . . . 51
24. Figura 24. Falso Panal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
25. Figura 25.Implementación SIMAP-MX2020 V2. . . . . . . . . . . . . . . . . 53
26. Figura 26.Transductores al interior del núcleo. . . . . . . . . . . . . . . . . . 54
27. Figura 27.Implementación final SIMAP-MX2020 V2. . . . . . . . . . . . . . 54
28. Figura 28.Entidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Sebastian
Rectangle
29. Figura 29.Incrementar la memoria. . . . . . . . . . . . . . . . . . . . . . . . 56
30. Figura 30.Configuración de la entidad. . . . . . . . . . . . . . . . . . . . . . 56
31. Figura 31.Kitematic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
32. Figura 32.Servidor orion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
33. Figura 33.Entidad publicada. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
34. Figura 34.Registros en CrateDB. . . . . . . . . . . . . . . . . . . . . . . . . . 59
35. Figura 35.Consulta CrateDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
36. Figura 36.Grafana. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
37. Figura 37.Grafana. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
38. Figura 38.Datos del sistema de monitoreo. . . . . . . . . . . . . . . . . . . . 62
39. Figura 39.Prueba de Normalidad Temperatura. . . . . . . . . . . . . . . . . 63
40. Figura 40.Prueba de Normalidad Humedad. . . . . . . . . . . . . . . . . . . 63
41. Figura 41.Prueba de Normalidad Punto de Rocio. . . . . . . . . . . . . . . . 64
42. Figura 42.Registros de Datos de la Colmena. . . . . . . . . . . . . . . . . . . 65
43. Figura 43.Registros de Datos de Temperatura. . . . . . . . . . . . . . . . . . 66
44. Figura 44.Registros de Datos Humedad Relativa. . . . . . . . . . . . . . . . . 67
45. Figura 45.Registros punto de rocío . . . . . . . . . . . . . . . . . . . . . . . . 68
46. Figura 46.TransductorSHT21 . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
47. Figura 47.Condiciones de trabajo SHT2x. . . . . . . . . . . . . . . . . . . . . 78
48. Figura 48.Condiciones de trabajo SHT2x. . . . . . . . . . . . . . . . . . . . . 78
49. Figura 49.Transductor Hx711 . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
50. Figura 50.Esquema Eléctrico SIMAP-MX2020. . . . . . . . . . . . . . . . . . 88
Sebastian
Rectangle
Índice de cuadros
1. Cuadro 1.Asesor externo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2. Cuadro 2.Asesores Internos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3. Cuadro 3.Responsable del Proyecto. . . . . . . . . . . . . . . . . . . . . . . . 25
4. Cuadro 4.Requerimientos Funcionales . . . . . . . . . . . . . . . . . . . . . 28
5. Cuadro 5.Requerimientos Funcionales . . . . . . . . . . . . . . . . . . . . . 29
6. Cuadro 6.Requerimientos Funcionales . . . . . . . . . . . . . . . . . . . . . 30
7. Cuadro 7.Requerimientos No Funcionales . . . . . . . . . . . . . . . . . . . 31
8. Cuadro 8.Requerimientos No Funcionales . . . . . . . . . . . . . . . . . . . 32
Sebastian
Rectangle
Siglas y abreviaturas
(IoT): Internet of Things
(FIPPPFI-PPP): Future Internet Public-Private Partnership
(IDAS): Integrated Data Acquisition System
(CEP): Complex Event Processing
(PDP): Nombre completo
(GE): Programmed Data Processor
(CB): Contex Broker
(OCB): Orion Contex Broker
(CP): Context Productor
(CC): Context Consumers
(DB): Data Base
(NGSI): Next Generation Safeguards Initiative
(MOOC): Massive open online courses
(WCC): WiFi Cloudino Connector
(SIMAP-MX2020): Sistema de Monitoreo de Colmenas México 2020
(ERS): Especificación de Requerimientos de Software
(ERH): Especificación de Requerimientos de Hardware
(RF): Requerimiento Funcional
(RNF): Requerimiento No Funcional
(FTP): Protocolo de Trnasferencia de archivos
(PIOT): Plataforma de internet de las cosas
Introducción
Este documento tiene como principal propósito explicar en detalle el proceso de desa-
rrollo del dispositivo ”SIMAP-MX2020” propuesto como proyecto de titulación. El cual
fundamenta y propone la pertinencia, sobre el diseño e implementación de un sistema
de monitoreo IoT para la abeja de la especie Apis mellífera.
Por un lado, se expone la necesidad e importancia de como este tipo de siste-
mas pueden coadyuvar al estudio y compresión de la relación especie-territorio. Por
otro lado, se presentaran los beneficios clave que una arquitectura de fuentes abiertas
hardware y software nos pueden brindar para el desarrollo de sistemas enfocados en
áreas de investigación emergentes, como lo es la apicultura de precisión. Así mismo, se
resalta la posibilidad de desarrollar sistemas de bajo costo y alta capacidad de desem-
peño analítico, los cuales brindan soluciones de seguridad y prevención del abigeato.
Estos sistemas no deben ser pensados en términos de automatización o de la
sustitución de la labor de un apicultor, es una herramienta que ayuda a la colección de
datos de las diferentes variables medioambientales en la colmena durante los periodos
de cosecha. Los datos de precisión pueden contribuir a generar registros semanales,
mensuales y anuales, los cuales podrán ser comparados con el conocimiento empírico
y los años de experiencia de los apicultores, obteniendo como resultado, la observa-
ción y el análisis para ayudar a comprender, formular y explicar varios fenómenos de
comportamientos asociados a la preservación de la abeja de la especie Apis mellífera.
Para el desarrollo del sistema embebido se utilizan diferentes componentes elec-
trónicos, los cuales, permiten recolectar datos y mediante una aplicación web, a través
del internet de las cosas es posible desplegar los datos en tiempo real . Finalmente, los
resultados del monitoreo se publican en FIWARE una plataforma de Internet del Futu-
ro abierta con el objetivo de realizar el monitoreo del sistema en tiempo real sin coste
alguno.
1
Capítulo 1
Contexto
Capítulo 1. Contexto.
A lo largo del tiempo hemos estudiado y aprendido sobre la correlación de las especies
en el ecosistema natural donde las especies dependen unas de otras, en estos tiempos
los humanos hemos olvidado este principio de correlación natural, muestra de ello es
la alarmante situación que se vive a nivel mundial con el estado de salud de los insec-
tos polinizadores como lo son las abejas, las cuales han resultado afectadas debido a
los cambios del entorno donde viven. Durante muchos años la evolución de las espe-
cies, el territorio y la flora se desarrollaron proporcionalmente, sin embargo, hoy día la
intervención del humano ha generado dificultades de adaptación y resistencia [1].
La urbanización ha dado pauta a una creciente contaminación del aire, el agua
y los territorios naturales donde se desenvuelven la mayor parte de los insectos polini-
zadores, esto ha creado que se afecte el tiempo de floración de las plantas, generando
variaciones en las temporadas de lluvia, repercutiendo en la genética de las flores, don-
de los mensajes químicos que emitían para poder ser localizadas por las abejas han
cambiado [1].
La gran parte de los estudios sobre la abeja de la especie Apis Mellifera, son
llevados a cabo in situ, donde los climas y entornos naturales son específicos, únicos y
propios de cada región o territorio donde son desarrollados [1].
En el caso del territorio mexicano, es necesario desarrollar investigaciones que
apoyen a comprender a profundidad la correlación entre la especie Apis Mellifera la
flora, fruto y fauna mexicana. Hoy en día, la situación alarmante que sufren la apicul-
tura y las abejas en todo el mundo se debe al hechode que durante largos períodos
de tiempo, la evolución de las plantas y las flores siempre estuvo condicionada a la
resistencia y la adaptación [1] .
El ser humano en unos años ha modificado drásticamente los ciclos de vida,
así como los entornos de los que dependen, por factores como estos, las abejas no
pueden adaptarse a este ritmo acelerado que se les ha impuesto y en consecuencia,
están colapsando en todo el mundo [1].
3
Factores como la transformación y la alteración radical de los paisajes forestales
y agrarios, la deforestación y la agricultura intensiva presentes en la actualidad en casi
todos los entornos naturales, la fuerte tendencia al monocultivo y el uso de semillas
transgénicas en los campos, además de la generalización y el uso de pesticidas, insec-
ticidas y todo tipo de agroquímicos para controlar las plagas o acelerar el crecimiento
de los cultivos, han afectado el sentido de orientación, memoria y metabolismo de las
abejas y otros insectos [2].
Así mismo, la creciente contaminación del aire y el cambio climático gradual
están afectando el tiempo de floración del las plantas y la temporada de lluvias, lo que
perjudica los mensajes químicos que emiten las flores y como resultado, las abejas
pierden orientación y enfrentan problemas para localizarlas y polinizarlas, disminu-
yendo la cantidad y calidad del néctar, alimentándose mal [2].
Todos estos antecedentes crean un panorama desalentador que deja indefensos
a la mayoría de los insectos polinizadores, con un sistema inmune débil y un metabo-
lismo muy sensible que no les permite hacer frente a las plagas o invasores que los
atacan y los afectan directamente y de manera específica [3].
Actualmente nos encontramos dentro de un círculo vicioso, donde las abejas
no pueden encontrar flores y por ese motivo, no pueden alimentarse, mientras tanto
las flores no pueden reproducirse al no ser polinizadas [3].
La familia de las abejas de la especie Apis Mellifera es una de las principales
especies que recolectan néctar para convertirla en miel y una de las más utilizadas por
los apicultores de todo el mundo para extraer productos derivados de la colmena, una
especie en constante decline [3].
El proyecto de investigación presentado en este documento se centra en la re-
copilación, el almacenamiento y la visualización de datos en tiempo real de variables
ambientales como la temperatura, humedad, la cantidad luminosa y el peso, paráme-
tros que pueden utilizarse para inferir acerca de los estados de comportamiento de la
colmena, además de prevenir el abigeato en México, es decir, el hurto de colmenas, un
problema y necesidad latente expresada por los apicultores durante esta investigación.
4
1.1 Breve descripción del problema.
Durante largos periodos de tiempo, la evolución de las plantas y flores siempre estu-
vieron bajo la resistencia y adaptación de la especie, el ser humano en unos cuantos
años ha modificado sus ciclos de vida, como los entornos de los que dependen [4]. Los
insectos polinizadores son incapaces de adaptarse a este ritmo acelerado que se les ha
impuesto y en consecuencia están colapsando en todo el mundo [4].
Todos estos antecedentes crean un panorama desalentador, dejando a las las
abejas muy indefensas, con un sistema inmune y un metabolismo muy sensible, con
el que no pueden hacer frente a las plagas o invasores que las atacan y afectan directa-
mente [4].
Además de todos estos problemas en México se presentan una problemática
social muy concurrente, el abigeato, el cual, además del hurto de la colmena, también
viene acompañada de la extracción de bastidores de miel, la destrucción y quema de
las mismas. De esta forma, la falta de interés por las autoridades mexicanas ante estos
problemas, deriva en una desatención total sin acciones contundentes al respecto.
1.2 Motivación.
La necesidad de ofrecer aplicaciones que sirvan socialmente y que provean una solu-
ción mediante desarrollo tecnológico, resultan de motivación en áreas como lo es la
apicultura de precisión. El tema de las abejas especie “Apis Mellifera”, un insecto poli-
nizador declarado en el 2018 como la especie más importante del planeta tierra, resulta
en peligro de extinción y con un daño irreversible. Por lo tanto, desarrollar herramien-
tas en este campo de aplicación que pueden servir como una ayuda a la comprensión
del territorio con la especie, contribuye así a la preservación de la especie y al desarro-
llo tecnológico.
5
1.3 Objetivos.
1.3.1 Objetivo General
Desarrollar un sistema embebido de monitoreo remoto de variables ambientales en la
colmena utilizando tecnología IoT con la finalidad de registrar y desplegar datos preci-
sos en tiempo real.
1.3.2 Objetivos específicos
1 Diseñar una arquitectura que integre el Software y Hardware para el sistema
de monitoreo.
2) Gestionar los datos obtenidos por el sistema mediante herramientas de IoT.
3) Implementar el sistema a través de FIWARE una plataforma de Internet del
futuro que despliegue los datos en tiempo real.
1.4 Estructura del documento
El presente trabajo se estructura de la siguiente manera de forma resumida: En el ca-
pítulo 2, se presenta el Marco teórico y el estado del arte que permiten ubicar las tec-
nologías y técnicas utilizadas en el proyecto. En el capítulo 3 se presenta el desarrollo
del proyecto. En el capítulo 4 la implementación del sistema y los resultados obtenidos.
Finalmente, se presentan las conclusiones, bibliografía, y anexos del presente proyecto
de titulación.
6
Capítulo 2
Marco Teórico
Capítulo 2. Marco teórico.
FIWARE hace referencia a una plataforma del Internet del Futuro, su tecnológica pú-
blica y abierta permite el desarrollo de diversas aplicaciones y servicios en las Smart
Cities, Internet de las Cosas y computo en la nube [5].
2.1 Estado del arte
La propuesta de desarrollo consiste en un sistema embebido, un controlador de ener-
gía y transductores de variables atmosféricas. Para la propuesta de diseño referente a la
arquitectura de hardware, se optó por que el diseño final fuera de bajo costo y de código
abierto. El hardware principal utilizado fue Cloudino, una iniciativa open hardware-
software mantenida por INFOTEC, a la par se eligió una arquitectura de software abier-
ta que permitiera utilizar los servicios de cómputo en la nube libre de costos, así se
decidió trabajar el desarrollo con la plataforma del internet del futuro FIWARE [5].
Cloudino envía la información de cada transductor, la cual es recibida por un
Gateway el cual se enlaza a un servidor de la red central, donde se comunica a la plata-
forma de internet de las cosas FIWARE, la cual es una plataforma tecnológica pública
y abierta para el desarrollo de aplicaciones [6].
FIWARE hace referencia a una plataforma tecnológica y pública la cual ofrece
un ecosistema de innovación mediante modelos de datos establecidos para diferentes
aplicaciones [6]. Los “Generic-enablers”, son modelos de datos diseñados para ser lo
más genéricos posibles y se clasifican en cinco grupos, los cuales, se enlistan a conti-
nuación:
1) Alojamiento en la nube para recursos de cómputo, almacenamiento y red.
2) Habilitación de servicios de Internet de las Cosas brindando las interfaces
entre servicios y dispositivos del Internet de las Cosas.
8
3) Gestión de datos y contextos facilitando el acceso, almacenamiento, proce-
samiento, publicación y análisis de datos a gran escala.
4) Interfaces de redes y dispositivos, facilitando el mayor aprovechamiento de
las capacidades de la infraestructura disponible.
5) Arquitectura de ecosistemas y entrega de aplicaciones y servicios, brindando
un marco para la co-creación, publicación, venta cruzada y consumo de aplicaciones
y servicios con un enfoque de negocios [7].
La nube de FIWARE llamada FIWARE-Lab es un ambiente sandbox (entorno de
pruebas separado del entorno de producción) no comercial para experimentar e inno-
var con las tecnologías de FIWARE,está conformado por nodos federados desplegados
sobre una red distribuida alrededor del mundo, con la finalidad de exportar sus datos
los usuarios interesados pueden explotar estos datos abiertos publicados por las ciu-
dades y otras organizaciones, así como realizar pruebas y mostrar sus aplicaciones en
FIWARE Lab [7]. La conectividad de dispositivos físicos requiere implementar y cono-
cer a profundidad protocolos de comunicación inalámbrica y estándares como el IEEE
802.11, poseer solidos fundamentos de redes de computadoras y direccionamientos
ip, para poder desarrollar en un principio de manera local la aplicación, es decir en
un entorno o servidor de pruebas y posteriormente migrarla hacia un entorno de pro-
ducción, donde finalmente se ejecuta y despliega la aplicación, para que los usuarios
finales puedan acceder y trabajar con los datos mismos [7].
Debido a que cada dispositivo cuenta con una variedad de particularidades,
no es factible proporcionar una solución funcional general, por esta razón se requiere
contar con una arquitectura IoT que habilite funciones de intermediación y de reco-
pilación de datos desde dispositivos heterogéneos y que además sean configurables y
adaptables a las necesidades del mercado [8]. La arquitectura básica para el desarrollo
de aplicaciones de IoT con FIWARE se muestra en la Figura 1, donde se puede observar
los componentes de la arquitectura, la adquisición de datos y la ejecución de coman-
dos a nivel de los dispositivos físicos y finalmente el uso de los datos hacia aplicaciones
externas [8].
9
Figura 1. Arquitectura de FIWARE
Fuente: Reproducción íntegramente de [9]
La arquitectura comprende los siguientes componentes de FIWARE: IDAS (Bac-
kend Device Management), Orion Context Broker, CEP (Complex Event Processing),
Short Term Historic y componentes de seguridad como el Identity Management y el
Authorization PDP (Policy Decision Point) [8].El IDAS con sus IoT Agents resuelve los
problemas de entornos heterogéneos donde los dispositivos con diferentes protocolos
se gestionan y modelan en un formato de datos común (el modelo I), proporcionado
por el Context Broker [8]. Además, se incluyen otros componentes que permiten me-
jorar las capacidades de la información almacenada: modelos de almacenamiento de
datos avanzados, recuperación histórica de la información, vinculación con aplicacio-
nes de terceros.
El context broker es el corazón de la arquitectura, permite recopilar y publicar
información de contexto a gran escala [10]. Así mismo se podrían englobar las funcio-
nalidades de los componentes para lo siguiente, Orion e IDAS pueden usarse para la
lectura y obtención de información proveniente de sensores fijos, sensores móviles y
sensores de monitoreo personal. CEP procesador de eventos complejos puede usarse
en condiciones donde se requiere la detección y análisis de patrones, como las condi-
ciones atmosféricas de tráfico y contaminación [10]. El short term historic es utilizado
10
para la recuperación histórica de la información generada por los sensores y el iden-
tity managment junto con el Authorization PDP nos sirve para controlar los permisos
y acceso de usuarios.
2.1.1 Manejo de Información de contexto en FIWARE.
El Publish/Subscribe Context Broker GE a través de su implementación Orion Con-
text Broker conocido como Orion CB, permite la publicación de información a través
de los productores de contexto, por ejemplo, los sensores, de manera que la informa-
ción de contexto publicada, se encuentre disponible para otras entidades los cuales
están interesados en procesar la información [10]. Podemos utilizar el Orion CB como
un canal para que las aplicaciones administren los datos manejados provenientes del
IoT, los proveedores de contexto y los consumidores de contexto pueden ser cualquier
aplicación o incluso otros Ges dentro de la plataforma FIWARE [10].
Así mismo, el Orion CB proporciona las interfaces NGSI9 y la NGSI10 [10]. Uti-
lizando estas interfaces se pueden realizar varias operaciones, tales como:
Registrar aplicaciones de proveedores de contexto, por ejemplo: un sensor de
temperatura dentro de una habitación [10].
Actualizar información de contexto, por ejemplo: enviar actualizaciones de la
temperatura [10].
Ser notificado cuando surjan los cambios en la información de contexto (por
ejemplo, cuando la temperatura ha cambiado), o con una frecuencia determinada (por
ejemplo, obtener la temperatura cada minuto) [10].
Consultar información de contexto. Orion almacena la información de contexto
actualizada desde las aplicaciones [11].
El Orion CB GE soporta dos vías de comunicación: “push” y “pull”, tanto en los
productores como en los consumidores de contexto.
11
Lo que significa que un productor de contexto con una lógica mínima o muy
simple puede enviar continuamente la información de contexto en el Publish/Subscribe
Context Broker [11]. A su vez, un consumidor de contexto puede solicitar información
de contexto de productores de contexto (si estos proporcionan la capacidad de ser con-
sultada).
Los productores de contexto capaces de actuar como servidores también se les
conocen como proveedores de contexto. De manera similar, los consumidores de con-
texto pueden obtener información de contexto del Broker (mediante una petición),
mientras que el Orion CB puede enviar a la información de contexto al consumidor
interesado mediante una suscripción [11].
2.1.2 Elementos de Contexto.
La comunicación entre los distintos componentes de la arquitectura de alto nivel del
Publish/Subscribe Context Broker se realiza a través de la interfaz RESTful NGSI, la
cual es inspirada y basada en la especificación OMA NGSI. [12] Un elemento de con-
texto se refiere a la información que es producida, recopilada u observada y que puede
ser relevante para su procesamiento, análisis y extracción de nuevo conocimiento [12].
Tiene asociado un valor definido, que consiste en una secuencia de uno o más triplas
que se refieren a atributos de un elemento de contexto. FIWARE soporta un conjunto
de tipos de datos básicos, así como la posibilidad de definir tipos de datos estructura-
dos; vectores y mapas clave (cuyos elementos pueden ser otros vectores, mapas clave
o tipos de datos simples) [12].
Los elementos de contexto proporcionan información relevante a una entidad
en particular, este puede ser un componente físico o parte de una aplicación, por ejem-
plo, un elemento de contexto puede contener valores de atributos asociados a una
habitación como la última temperatura medida, los metros cuadrados que mide y el
color de la pared. Por lo general, elemento de contexto contiene un id (EntityId) y un
tipo (EntityType) que identifica exclusivamente a una entidad. Además, pueden existir
metadatos, vinculados a los atributos a un elemento de contexto [13]. La información
12
de contexto en OMA NGSI se representa a través de estructuras de datos llamadas ele-
mentos de contexto, los cuales tienen asociado. Un EntityId y un EntityType, único que
identifica la entidad a la cual los datos de contexto hacen referencia. Una secuencia de
uno o más atributos de elementos de datos (tripletas) así mismo metadatos opcionales
vinculados a atributos [13].
2.1.3 Actores Involucrados
El Publish/Subscribe Context Broker (CB) funciona como un controlador y agregador
de datos de contexto y como una interfaz entre los demás actores de la arquitectura.
Controla principalmente el flujo de contexto entre todos los actores por lo que el CB
debe conocer a todos los proveedores de contexto (PC) disponibles. El CB ofrece un
servicio de búsqueda de proveedores de contexto y un servicio de persistencia de con-
texto. Productor de contexto (CP) El productor de contexto (CP) es un actor capaz de
generar contexto [16].
El CP es quien actualiza de forma espontánea la información de contexto re-
lacionada a uno o más atributos de contexto de acuerdo a su lógica interna definida.
ElCP puede también actuar como proveedor de contexto. Un proveedor de contexto
(CPr) es un tipo especializado de productor de contexto, que proporciona información
de contexto bajo demanda de manera síncrona [16]. Esto significa que el CB o incluso
el CC pueden invocar al CPr para adquirir información. Un CPr puede producir nueva
información de contexto inferida a partir del procesamiento de parámetros de entrada,
por lo que con frecuencia es responsable del razonamiento de alto nivel de la informa-
ción de contexto [16].
Cada CPr registra su disponibilidad y sus capacidades mediante el envío de
anuncios al CB y expone interfaces para proporcionar la información de contexto al CB
y a CC. Consumidor de contexto (CC) El consumidor de contexto (CC) es una entidad
(por ejemplo, una aplicación) que explota la información de contexto [14]. Un CC pue-
de recuperar información de contexto mediante una solicitud al CB o mediante una
invocación directa a un CPr a través de una interfaz específica. Otra forma de obtener
13
información es mediante la suscripción a actualizaciones, las cuales serán recibidas al
cumplirse determinadas condiciones (relacionadas a un conjunto de entidades) [14].
El CC registra una operación de devolución de llamada con la suscripción, por
lo que el CB notifica al CC cuando existan notificaciones relevantes en el contexto. Al-
gunos CC pueden exponer las operaciones de actualización de contexto, por ejemplo,
produciendo una acción determinada, como encender o apagar una lámpara [14]. Ca-
da intercambio de datos de contexto se relaciona a una entidad específica. Una entidad
es el objeto, por ejemplo, un usuario o grupo de usuarios, cosas o grupos de cosas, que
hacen referencia a datos de contexto. Se compone de dos partes, un tipo y un identifi-
cador [14].
Un tipo es un objeto que categoriza un conjunto de entidades, por ejemplo,
usuarios humanos identificados por un nombre de usuario, dispositivos móviles iden-
tificados por su imei, usuarios móviles identificados por un número telefónico y grupos
de otras entidades identificados con un identificador de grupo [14].
2.1.4 Arquitectura general del Publish/Subscribe Contex Broker
El Publish/Subscribe Context Broker es un servidor que implementa una API que se
basa en el modelo de información NGSI. Esta API se llama API FIWARE NGSI 10. El
servidor siempre está escuchando en un puerto que generalmente es el 1026 aunque
es posible cambiarlo. [15].
Por medio de este puerto los CP pueden actualizar los datos de las entidades
y sus atributos, y los CC pueden consultar esa información. El CB también soporta
un modelo basado en notificaciones, de manera que un CC pueda suscribirse a una
entidad o a una combinación de ellas y recibirá una notificación cuando “algo” suceda
(transcurra un periodo determinado de tiempo o algún cambio en sus atributos, por
ejemplo). CB utiliza la base de datos mongoDB para almacenar el estatus actual de las
entidades, no se almacena información histórica de sus cambios. Para este propósito
se puede utilizar CrateDB [15].En la Figura 2 se muestra la arquitectura general del
Publish/Subscribe Contex Broker.
14
Figura 2. Arquitectura general del Publish/Subscribe Contex Broker.
Fuente: Reproducción íntegramente de [16].
2.1.5 Cloudino
Cloudino es un sistema abierto de hardware y software mas una plataforma online,la
cual permite el desarrollo e instrumentación de sistemas embebidos para multiples
aplicaciones IoT [17].
La plataforma de Cloudino fue diseñada pensando en cuatro características
principales, tamaño reducido, fácil de usar, de bajo costo y modularidad. Con estas
características Cloudino, permite a cualquiera la posibilidad de incorporar las tecno-
lógicas del IoT sin limitaciones económicas [17].
La plataforma Cloudino propone agregar un chip IoT (Cloud Wifi Connector)
el cual trabaja como una capa red configurable entre transductores, actuadores y los
servicios en la nube.
El primer componente es la API Cloudino la cual tiene una implementación
específica para diferentes soluciones de microcontroladores.
La función de la API es importante porque con ella se puede enviar datos me-
diante MQTT hacia Orión Contex Broker desde el servidor de Cloudino sin tener que
15
realizar algún cambio en el código fuente y solamente es necesario configurar el pro-
tocolo específico a utilizar en la capa de red [17]. La API Genérica es independiente
del protocolo IoT que utilizamos en la capa de red. En la Figura 3 se puede observar la
Arquitectura general de trabajo con Cloudino.
Figura 3. Arquitectura Cloudino.
Fuente: Elaboración Propia.
2.1.6 Wifi Cloud Connector
El conector WiFi Cloudino (WCC), es un chip IoT, que ha sido pre-programado con los
protocolos MQTT y NGSI [18]. MQTT es un protocolo abierto de comunicación opera
mediante mensajes en un arreglo de tipo cliente y servidor, es decir se ejecuta mediante
publicaciones y subscripciones a tópicos, protocolo idóneo para aplicaciones de IoT
donde se requiera mandar cantidades minimas de información. [18].
Podemos considerar al conector WiFi Cloudino como un router IoT, el cual in-
corpora un servidor web para realizar las configuraciónes como seleccionar el provee-
dor de servicio de internet y la selección del protocolo IoT que el chip utilizará.
16
Otra característica importante del conector Cloudino es que puede ser utiliza-
do como maestro-esclavo, trabaja como un procesador en paralelo dedicado exclusi-
vamente a la capa de red, dejando al microcontrolador esclavo dedicado a la conec-
tividad de los transductores y actuadores.Sin embargo, puede ser utilizado como un
dispositivo individual para directamente comunicar los objetos en tiempo real a inter-
net [18].
Así mismo una característica primordial o mas sobresaliente es que es posible
re programar el dispositivo vía Wifi o desde la nube. En la Figura 4 se puede apreciar
el WCC el cual tiene 11 GPIOs y solamente posee un pin analógico, los cuales pueden
ser usados para conectar sensores y actuadores directamente al chip, sin la necesidad
de agregar un microcontrolador extra, así mismo puede ser programado utilizando Ja-
vaScript embebido [18].
Figura 4. Pinout WCC.
Fuente: Reproducción íntegramente de [19]
2.1.7 Apicultura de Precisión
La Apicultura de Precisión es una dirección de investigación emergente del Internet de
las cosas, consiste en una estrategia de gestión basada en el monitoreo individual de
las colonias para minimizar los recursos consumidos y maximizar la productividad de
las abejas [20].
17
La apicultura de precisión es un tema desafiante y en condiciones de ayudar a
agregar valor a la cadena apícola, preservar la especie, cuidar el ambiente y contribuir
al desarrollo económico y social del territorio [20].
Los sistemas empleados en la apicultura de precisión en la actualidad presen-
tan una combinación de retos que intervienen en su utilización, adquisición y total
integración en actividades productivas como lo es la apicultura. Factores reales como
la inversión requerida para el desarrollo, diseño e integración del sistema rebasa las
capacidades de adquisición de los apicultores principiantes.Debido en parte a que la
producción de miel es un producto resultado de un proceso de cultivo que requiere de
al menos 2 años previos de trabajo antes de cosechar ganancias economicas significa-
tivas [21].
La apicultura debe desarrollarse colectivamente o en conjunto con otros api-
cultores para minimizar gastos donde adicionalmente se deben generar productos de
valor agregado (medicamentos, productos alimenticios, productos de limpieza), que
ayuden a hacerlo rentable económicamente hablando.
Es sumamente importante distinguir los aportes que los sistemas para apicul-
tura de precisión realmente pueden ofrecer.
Estos sistemas no deben pensarse en términos de automatización o sustitución
de las labores de un apicultor, actividades como la revisión de la colmena para com-
probarsi existe reina, la cantidad de provisiones, la sanidad de la colmena, la falta o
sobra de espacio en la cámara de cría y alzas entre otros, siguen siendo actividades que
ningún apicultor debería de dejar de hacer ya que estos implicarían diversos riesgos
asociados.
Siendo que su verdadera importancia radica en términos de investigación es
decir una herramienta de colección de datos sobre las distintas variables ambientales
de la colmena durante toda la temporada de cultivo, cuya precisión ayude a generar ex-
pedientes y registros anuales de precisión [22]. Además estos sistemas pueden ayudar
a contrarrestar el abigeato mediante el enfoque de sistemas de seguridad IoT.
18
Los datos de precisión obtenidos deberán ser comparados con el conocimiento
empírico proveniente de los años de experiencia de los apicultores que posteriormente
a través de la observación y análisis ayuden a formular, explicar y comprobar diversos
fenómenos y comportamientos asociados a las abejas. El objetivo final de toda aplica-
ción IoT es el de alcanzar el nivel de “servicios ubicuos” esto es proporcionar servicios
de colaboración consciente en cualquier momento en que sean requeridos por cual-
quier usuario en cualquier lugar [22].
La disponibilidad de la información recolectada es de especial interés a apicul-
tores, biólogos, etólogos y profesionales que de alguna forma realicen o lleven a cabo
trabajos e investigaciones profundas en el área de apicultura, por lo cual se considera
un factor crítico el disponer de estos datos en cualquier instante y en lugares adecua-
dos.
Con la posibilidad de aplicar “Semántica” haciendo referencia a la capacidad de
extraer conocimiento de los datos de manera inteligente que incluye el uso de recursos
y modelado de información involucrando procesos como reconocimiento y análisis de
datos [23].
El poder contar con herramientas como la presente propuesta podrían ayudar-
nos a sustentar el desarrollo de apicultura, comprender la relación especie-territorio
mexicano y preservar la especia mediante el desarrollo de alertas o sistemas de seguri-
dad.
2.1.8 Áreas de oportunidad y objetos de estudio empleando la apicul-
tura de precisión
Los métodos para monitorizar mas empleados actualmente se centran en la medición
de variables como el peso, la temperatura, humedad relativa en el aire, la concentra-
ción de gases en la colmena, vibración y sonido, parámetros los cuales pueden ser me-
didos constantemente y de un forma cada vez más accesible para los investigadores
ya que el costo y tamaño de los sensores electrónicos decrementan mientras que la
precisión y capacidad de los mismos aumenta [24].
19
El colectar datos continuos sobre las variaciones de peso en la colmena nos
pueden ayudar a determinar o inferir sobre:
1) El crecimiento y consumo de alimentos de la colonia.
2) Si existe estrés alimenticio debido a una decremento de peso en la colonia.
3) La masa de néctar y polen recolectado durante el día y su relación con la
evaporación de agua por la noche.
4) El rango de recolección de néctar diario una vez iniciada la época de flujo de
néctar.
5) La enjambrazón es decir la manera natural por la cual las abejas se reprodu-
cen y una parte de la colonia se separa de la colmena variando su peso.
6) El inicio de la temporada de hibernación
7) Se puede estimar el número de abejas pecorea-doras monitorizando la pér-
dida de peso por las mañanas cuando salen a recolectar.
8) Conocer el inicio y fin de la temporada de flujo de néctar, puede contribuir a
explicar cómo los cambios climáticos afectan a las abejas [25].
Existen investigaciones en EU por parte del centro espacial Goddard de la NASA
un proyecto que sirve de observatorio nacional, donde apicultores voluntarios de la re-
gión media atlántica pesan a diario sus colonias y retro alimentan de forma manual con
estos datos el sistema, con la finalidad de comprender la relación planta-polinizador.
Como resultado obtuvieron que la temporada de flujo de néctar actualmente
ocurre 4 semanas antes que en el año 1970 para la zona de Maryland. Variaciones que
probablemente guardan relación con el cambio climático y calentamiento global, y
que no pudieron ser capturadas satelitalmente ya que los satélites proporcionan una
buena cobertura a gran escala del cambio de vegetación con respecto al clima, pero no
pueden observar la polinización directamente [26].
20
Basados en la información de la temperatura los apicultores e investigadores
han tratado de detectar estados en la colonia como:
1) El incremento de consumo de comida.
2) El inicio del estado de crianza.
3) El volumen de crías en la colmena.
4) Detección de estados de pre enjambrazón.
5) Muerte en la colonia de abejas.
6) Diversos comportamientos asociados durante la etapa de pupa [27].
La exposición a bajas temperaturas durante los estados de cría operculada in-
duce una alta mortalidad y a un acortamiento en la longevidad de las obreras, la expo-
sición (20ºC) durante los estados de cría operculada inducen la venación anormal de
las alas en la abeja melífera [27].
Las abejas obreras mantienen el nido de cría de la colonia dentro de un estre-
cho rango de temperatura 34±1.5ºC sin embargo estudios realizados han demostrado
que las abejas obreras que son criadas durante el estado de pupa a 36ºC desarrollan
mejores capacidades de aprendizaje y memoria a corto plazo [28].
Así mismo desarrollan mejores capacidades para realizar las danzas de comuni-
cación, movimientos del abdomen que realizan las abejas pecoreadoras que informan
al resto de la colmena dónde se encuentra la fuente de alimento señalando la dirección
y la distancia [28].
¿Por qué las obreras mantienen la temperatura de crianza a 34±1.5ºC en lugar
de 36ºC si las temperaturas ligeramente por arriba de lo normal mejoran los compor-
tamientos asociados a la colección de néctar y polen en las abejas?
Una posibilidad es que la incubación a una temperatura más elevada de lo nor-
mal demanda excesiva energía a la colonia perjudicando otros factores fisiológicos o
neuronales importantes aun no comprobados o que temperaturas mayores a 34±1.5ºC
implican la generación de patógenos [29].
21
De igual manera mediciones de temperatura sobre la parte superior de la col-
mena han sido propuestas para la determinación automática de cinco periodos de
desarrollo del ciclo anual en la colonia de abejas [30].
1) Inicio de la crianza en invierno.
2) Inicio de la crianza en primavera.
3) Inicio de la crianza en verano.
4) Inicio de la crianza en otoño Periodos sin crías.
Este conocimiento puede ayudar a mejorar la sincronización anticipada de las
actividades de los apicultores con el desarrollo de cada etapa individual en la colonia
[31].
2.1.9 Ecosistema FIWARE
El ecosistema FIWARE hace referencia al conjunto de aplicaciones y servicios emplea-
dos en el sistema de SIMAP-MX2020, una guía visual bastante útil puede observarse en
la Figura 2.5.
El agente IoT empleado es cloudino, el cual mediante su plataforma IoT llamada
cloudino.io, pública la información de los sensores hacia el OrionCB, el cual escucha
mediante el puerto 1024:1024, este broker actualiza los valores de los transductores en
tiempo real, utilizando como memoria temporal a MongoDB, a este se le asignó como
puerto de servicio 27017:27017.
MongoDB no guarda registros históricos en función del tiempo, por lo que se
empleó el servicio CrateDB como gestor de la base de datos, con la capacidad de al-
macenar registros históricos apuntando a su puerto de servicio 4200:4200, datos que
pueden ser consultados empleando lenguaje de consulta estructurado.
22
Sin embargo para que puedan guardarse los registros publicados en el OrionCB
provenientes del agente IoT es necesario hacer uso del servicio QuantumLeap, este
servicio de enlace cuántico sera el responsable de vigilar las actualizaciones de las va-
riables o tópicos y replicara su información desde OrionCB hacia CrateDB.
Porúltimo para la visualización de la información en tiempo real se configuró
Grafana con puerto de servicio 3000:3000, visualizador gráfico que realiza consultas
SQL y las representa de diversas formas en una interfaz configurada previamente. La
figura 5. muestra el ecosistema de FIWARE descrito.
Figura 5. Arquitectura de la Aplicación
Fuente: Elaboración propia.
2.1.10 Análisis de requerimientos
Para la colaboración y desarrollo de la presente investigación se contó con la partici-
pación de asesores internos y externos.
El Cuadro 1, muestra los datos del asesor apicultor externo invitado.
23
Nombre Evelin Loyo Vargas
Rol Apicultor/Técnico/Fundador en rescates de abejas Mera-
ki Querétaro.
Profesión Apicultor miembro de la asociación local ganadera de
apicultores del estado de Querétaro.
Responsabilidad Miembro de la Asociación Ganadera Local de Apicultores
del estado de Querétaro contacto directo.
Información de contacto https://www.facebook.com/contactoMeraki
Cuadro 1. Asesor externo.
Fuente: Elaboración propia.
Nombre Dr. Daniel Villanueva Velázquez
Rol Catedrático de Conacyt e investigador de tiempo comple-
to en INFOTEC.
Profesión Doctor en Ciencia y Tecnología Informática.
Responsabilidad Asesor Interno INFOTEC.
Información de contacto Correo: daniel.villanueva@infotec.mx
Teléfono: (55) 5624 2800 ext. 6324
Nombre Dr. José Sebastián Gutierrez Calderón
Rol Catedrático Conacyt miembro del Sistema Nacional de
Investigadores SNI
Profesión Doctorado en Ingeniería en Automática y Electrónica In-
dustrial
Responsabilidad Asesor Interno INFOTEC
Información de Contacto Correo: jsgutierrez@up.edu.mx
Cuadro 2. Asesores Internos.
Fuente: Elaboración propia.
Así mismo el Cuadro 2, muestra la información de los asesores internos involu-
crados en la presente propuesta de desarrollo.
Expertos investigadores los cuales han brindado asesoría académica y profesio-
nal, durante el desarrollo del proyecto.
De la misma manera la información del responsable del desarrollo técnico del
presente proyecto se presenta a continuación en el Cuadro 3.
24
Nombre Isidro Zavaleta Ochoa
Rol Analista, desarrollador de hardware y software.
Profesión Candidato a MSE INFOTEC.
Responsabilidad Desarrollador del SIMAPM-MX2020.
Información de contacto Correo: ingzavaleta0@gmail.com
Teléfono: 4411207327
Cuadro 3. Responsable del Proyecto.
Fuente: Elaboración propia.
2.1.11 Perspectiva del producto
El sistema SIMAP-MX2020 será un producto diseñado para trabajar en entornos WEB,
además se integrará conjuntamente con una plataforma del internet de las cosas, Clo-
duino y Fiware son elegidas debido a que son libres costo.
2.1.12 Funcionalidad del producto
El SIMAP-MX2020 es el resultado de la integración de un arquitectura de hardware y
una arquitectura software utilizando FIWARE como plataforma IoT.
La Figura 6, muestra la arquitectura general del sistema. La plataforma electró-
nica integra un transductor SHT21 para medir la temperatura, humedad y punto de
rocío, para monitorizar inicialmente la presencia,ausencia y muerte de la colonia de
abejas entre otras posibilidades, así mismo integra un transductor LDR para detectar
las variaciones de luz al interior de la colmena, con la finalidad de detectar la apertura
o retiro de la tapa de la colmena. Finalmente integra un Hx711 amplificador y conver-
sor de señales ADC para la lectura de cuatro galgas extensiometricas que permitirán
medir la variación de peso en la colmena.
2.1.13 Restricciones
1) La Interfaz Web operara a través de internet.
2) Lenguajes y tecnologías en uso: C++, JSON, JAVA, HTML,SQL.
25
Figura 6. Arquitectura del sistema.
Fuente: Elaboración propia.
3) Los servidores atenderán consultas mediante SQL y una aplicación gráfica.
4)El diseño del sistema se basara en la metodología para desarrollo y construc-
ción de sistemas inteligentes IoT.
5) El sistema deberá tener un diseño de interfaz simplificada la cual difiere del
lenguaje empleado para su desarrollo.
2.1.14 Suposiciones y dependencias
1) Se asume que los requisitos aquí descritos son estables.
2) Se asume que los equipos empleados garantizaran una ejecución correcta.
3) Se asume que se utilizan fuentes abiertas de hardware y software.
4) Se supone que el sistema trabajará 24/7 horas los 365 días del año.
5) Se supone que el sistema detectara la apertura de la colmena.
26
6) Se supone que el sistema medirá las variaciones de peso.
7) Se supone que el sistema medirá la temperatura y humedad al interior de la
colmena.
2.1.15 Requerimientos Funcionales
Para la etapa del levantamiento de requerimientos se consideraron como asesores ex-
ternos la participación de apicultores miembros de la asociación ganadera local del
estado de Querétaro. A los cuales se preguntó sobre las problemáticas que enfrentan
en sus labores.
Comentaron que actualmente las colonias de abejas enfrentan problemas, co-
mo muerte y disminución de la colonia, ocasionado principalmente por el uso excesivo
de pesticidas y plaguicidas.
Además de enfrentar plagas de ácaros como lo es la varroa, mejor conocido co-
mo el pequeño escarabajo de la colmena.
Por otra parte una problemática social altamente recurrente que mas esta afec-
tando a los apicultores es el abigeato. Lo que genera la necesidad de incorporar sis-
temas de seguridad que puedan detectar perturbaciones o saqueos a la colmena de
abejas.
Se requiere que la electrónica propuesta para dar solución sea de alto rendi-
miento y precisión, así mismo sera deseable la generación de alertas de seguridad vía
email. Considerando lo anterior los Cuadros 4 a 6, documentan los requerimientos
funcionales que deberá cubrir el sistema, los cuales han surgido a través del análisis
de los requerimientos.
27
Identificación del
requerimiento:
RF01
Nombre del requerimiento: Autenticación de Usuario.
Características: Los usuarios deberán identificarse para acceder a la plataforma.
Descripción del
requerimiento:
El sistema podrá ser consultado por cualquier usuario dependiendo
del módulo en el cual se encuentre y su nivel de accesibilidad.
Prioridad del
requerimiento:
Alta.
Identificación del
requerimiento:
RF02
Nombre del requerimiento: Registro de Usuarios.
Características: Los usuarios deberán registrarse en el sistema para acceder y poder
recibir alertas, reportes o mensajes del sistema de monitoreo.
Descripción del
requerimiento:
El sistema permitirá al usuario (Apicultor o Investigador) registrar-
se. El usuario debe suministrar datos como: CI, Nombre, Apellido, E-
mail, Número telefónico, Usuario y Password.
Prioridad del
requerimiento:
Alta.
Requerimiento
no funcional relacionado:
RNF01, RNF02,RNF05,RNF08.
Identificación del
requerimiento:
RF03
Nombre del requerimiento: Consultas e información del sistema.
Características: El sistema ofrecerá al usuario información general sobre el estado en
tiempo real de las variables medidas en la colmena mediante la gene-
ración de gráficas además de una interfaz de usuario disponible en la
plataforma IoT.
Descripción del
requerimiento:
La interfaz de usuario podrá ser consultada por el usuario las 24 ho-
ras al día, así mismo se generará un registro en la base de datos que
servirá para emitir reportes diarios sobre los estados en la colmena
Requerimiento
no funcional relacionado:
RNF01, RNF02.
Prioridad del
requerimiento:
Alta.
Identificación del
requerimiento:
RF04
Nombre del requerimiento: Interfaz de Usuario.
Características: El sistema actualizará los datos provenientes del sistema embebido
en tiempo real.
Descripción del
requerimiento:
Desplegar gráficamente las variables utilizando gadgets disponibles
los cuales deberán ser actualizados en tiempo real con la menor la-
tencia posible.
Requerimiento
no funcional relacionado:
RNF01, RNF02.
Prioridad del
requerimiento:
Alta.
Cuadro 4. Requerimientos Funcionales
Fuente: Elaboración propia.
28
Identificación del
requerimiento:
RF05
Nombre del requerimiento: Actualización de Datos.Características: El sistema permitirá al administrador, apicultores e investigadores
modificar los datos personales.
Descripción del
requerimiento:
Permite al administrador modificar datos de los usuarios, y cuentas
creadas.
Requerimiento
no funcional relacionado:
RNF01, RNF02,RNF05.
Prioridad del
requerimiento:
Alta.
Identificación del
requerimiento:
RF06
Nombre del requerimiento: Fuentes Abiertas.
Características: El sistema deberá integrar para su desarrollo software y hardware pre-
feriblemente libre de licenciamientos .
Descripción del
requerimiento:
Tanto el hardware como software deberá ser desarrollado teniendo
en cuenta la necesidad de no generar costos adicionales ni infringir
en derechos de licenciamientos de terceros
Requerimiento
no funcional relacionado:
RNF01, RNF02,RNF05.
Prioridad del
requerimiento:
Alta.
Identificación del
requerimiento:
RF08
Nombre del requerimiento: Variables atmosféricas.
Características: El sistema deberá integrar un transductor de precisión que permita
monitorizar la temperatura, humedad al interior de la colmena .
Descripción del
requerimiento:
Medir la temperatura y la humedad relativa en el aire al interior de la
colmena.
Requerimiento
no funcional relacionado:
RNF01, RNF02,RNF05,RNF04.
Prioridad del
requerimiento:
Muy Alta.
Identificación del
requerimiento:
RF09
Nombre del requerimiento: Peso.
Características: El sistema deberá integrar un arreglo de transductores que permita
monitorizar las variaciones de peso en la colmena.
Descripción del
requerimiento:
Utilizar un arreglo de galgas extensiometricas que permitan realizar
lecturas sobre las variaciones del peso en la colmena .
Requerimiento
no funcional relacionado:
RNF01, RNF02,RNF05,RNF04.
Prioridad del
requerimiento:
Muy Alta.
Cuadro 5. Requerimientos Funcionales
Fuente: Elaboración propia.
29
Identificación del
requerimiento:
RF10
Nombre del requerimiento: Apertura de la Colmena.
Características: El sistema incorporara un sistema de seguridad contra el abigeato.
Descripción del
requerimiento:
Detectar perturbaciones,movimiento o apertura de la tapa en la col-
mena.
Requerimiento
no funcional relacionado:
RNF01, RNF02,RNF04,RNF05,
Prioridad del
requerimiento:
Alta.
Identificación del
requerimiento:
RF11
Nombre del requerimiento: Alertas.
Características: El sistema deberá generar algún tipo de alerta al apicultor .
Descripción del
requerimiento:
El sistema deberá integrar alertas que sean disparadas al ser alcanza-
dos los umbrales previamente calibrados.
Requerimiento
no funcional relacionado:
RNF01, RNF02,RNF04RNF05.
Prioridad del
requerimiento:
Alta.
Cuadro 6. Requerimientos Funcionales
Fuente: Elaboración propia.
2.1.16 Requerimientos No Funcionales
A continuación los Cuadros 7 a 8, documentan los requerimientos no funcionales, es
decir las consideraciones que deberá cubrir el sistema que pueden servir de ayuda en
la operatividad del SIMAP-MX2020 como ayuda de usuario, manuales o facilidades, los
cuales han surgido a través del levantamiento de requerimientos y análisis del proyecto
30
Identificación del
requerimiento:
RNF01
Nombre del requerimiento: Interfaz de usuario.
Características: El sistema presentara una interfaz de usuario sencilla para que sea de
fácil manejo a los usuarios del sistema.
Descripción del
requerimiento:
El sistema debe tener una interfaz de uso intuitiva y sencilla.
Prioridad del
requerimiento:
Alta.
Identificación del
requerimiento:
RNF02
Nombre del requerimiento: Ayuda en el uso del sistema.
Características: La interfaz del usuario deberá de presentar un sistema de ayuda para
que a los usuarios del sistema se les facilite el manejo del sistema.
Descripción del
requerimiento:
La interfaz debe estar complementada con un buen sistema de ayuda
(la administración puede recaer en personal con poca experiencia en
el uso de aplicaciones informáticas).
Prioridad del
requerimiento:
Alta.
Identificación del
requerimiento:
RNF03
Nombre del requerimiento: Mantenimiento.
Características: El sistema deberá de tener un manual de instalación y manual de
usuario para facilitar los mantenimientos que serán realizados por
el administrador y garantizar la operatividad.
Descripción del
requerimiento:
El sistema debe disponer de una documentación fácil de actualizar
que permita realizar operaciones de mantenimiento con el menor es-
fuerzo posible.
Prioridad del
requerimiento:
Muy Alta.
Identificación del
requerimiento:
RNF04
Nombre del requerimiento: Interfaz web.
Características: El sistema deberá de tener una interfaz de usuario amigable fácil de
operar y que visualice las variables en función del tiempo de manera
gráfica.
Descripción del
requerimiento:
La interfaz deberá representar de manera visual las gráficas en tiem-
po real, proveniente de los transductores y podrán ser configurables
Prioridad del
requerimiento:
Muy Alta.
Cuadro 7. Requerimientos No Funcionales
Fuente: Elaboración propia.
31
Identificación del
requerimiento:
RNF05
Nombre del requerimiento: Desempeño.
Características: El sistema garantizará a los usuarios un desempeño en cuanto a los
datos almacenados en el sistema ofreciéndole una confiabilidad a es-
ta misma..
Descripción del
requerimiento:
Garantizar el desempeño del sistema informático a los diferentes
usuarios. En este sentido la información almacenada o registros rea-
lizados podrán ser consultados y actualizados permanente y simul-
táneamente, sin que se afecte el tiempo de respuesta. .
Prioridad del
requerimiento:
Alta.
Identificación del
requerimiento:
RNF06
Nombre del requerimiento: Nivel de Usuario.
Características: Garantizara al usuario el acceso de información de acuerdo al nivel
que posee.
Descripción del
requerimiento:
Facilidades y controles para permitir el acceso a la información al
personal autorizado a través de Internet, con la intención de consul-
tar y subir información pertinente para cada una de ellas.
Prioridad del
requerimiento:
Alta.
Identificación del
requerimiento:
RNF07
Nombre del requerimiento: Confiabilidad continúa del sistema.
Características: El sistema tendrá que estar en funcionamiento las 24 horas los 7 días
de la semana. Ya que es una página web diseñada para la carga de
datos y comunicación entre usuarios.
Descripción del
requerimiento:
La disponibilidad del sistema debe ser continua con un nivel de ser-
vicio para los usuarios de 7 días por 24 horas, garantizando un es-
quema adecuado que permita la posible falla en cualquiera de sus
componentes, contar con una contingencia, generación de alertas.
Prioridad del
requerimiento:
Alta.
Identificación del
requerimiento:
RNF08
Nombre del requerimiento: Seguridad en información.
Características: El sistema garantizará a los usuarios una seguridad en cuanto a la
información que se procede en el sistema..
Descripción del
requerimiento:
Garantizar la seguridad del sistema con respecto a la información y
datos que se manejan tales sean documentos, archivos y contraseñas.
Prioridad del
requerimiento:
Alta.
Cuadro 8. Requerimientos No Funcionales
Fuente: Elaboración propia.
32
2.1.17 Descripción de la solución tecnológica
La propuesta consiste en desarrollar un sistema embebido electrónico de bajo con-
sumo, el cual integrará transductores de variables como temperatura ambiente, hu-
medad relativa, foto resistencia, giroscopio y acelerómetro. Utilizando para ello co-
mo procesador núcleo un ATMEGA28 y para la etapa de red la plataforma electrónica
cloudino, el cual implementa el protocolo de comunicación IEEE 802.11 a través de
su microcontrolador núcleo ESP8266 de Espressif systems, diseñado para conexiones
bidireccionales seguras de bajo consumo de energía, largo alcance de comunicación y
movilidad. Cloudino utiliza como procesador núcleo para la etapa de red un ESP8266.
Para la etapa de experimentación se utilizará un núcleo portable de abejas, una pe-
queña colonia de abejas alrededor de 15000 a 20000 abejas criadas previamente por
un apicultor.La Figura 7 muestra la arquitectura interna del núcleo portable del tipo
langstroth.
Figura 7. Porta núcleo langstroth.
Fuente: Reproducción integra de
https://ieeexplore.ieee.org/document/8920622/figures.
33
2.1.18 Modelos Matemáticos Predictivos
Es posible determinar la variación del peso de la colmena acorde a la ecuación mate-
mática (1).
∆PC = GP +PP = 0 (1)
Donde ∆PC representa la variación de peso en la colmena, GP es la ganancia
de peso en la colmena y PP refiere a la perdida de peso en la misma. Así mismo para
calcular la ganancia de peso en la colmena podemos utilizar la ecuación (2).
GP = N +Pl +H2O + IC +C A + A A +FOD (2)
Donde N es el néctar, Pl es el polen recolectado, H es la humedad , IC es el
incremento de crías, C A el crecimiento de las abejas,A A es el aterrizaje de las abejas,
de igual manera es posible determinar la perdida de peso en la colmena mediante la
ecuación (3).
PP = E +R +MA +ER +D (3)
Donde E es la evaporación , R es la actividad metabólica de respiración, MA es
la muerte de las abejas, ER refiere a la eliminación de residuos y D son los despegues.
34
Capítulo 3
Metodologìa y Desarrollo
Capítulo 3. Metodología y Desarrollo.
3.1 Metodología para el diseño y construcción de sistemas
IoT
Para el diseño del prototipo se partió de una metodología general que permite el diseño
y construcción de sistemas para el internet de las cosas. La metodología se compone
de 8 etapas, las cuales, contemplan desde la concepción de diseño, el ciclo de vida y
hasta la comercialización de un producto en el mercado.
Por lo tanto, se presenta una serie de pasos a seguir los cuales son cíclicos, es
decir, está en constante actualización y siempre existe oportunidad para realizar mejo-
ras considerables derivadas de procesos como la seguridad en pruebas y la validación
de los mismos. La Figura 8 muestra la metodología propuesta, cabe señalar que en este
proyecto se alcanzaron cubrir todas las etapas propuestas en la metodología para el
diseño y construcción de sistemas IoT en plataformas de Internet del futuro.
Figura 8. Metodología de desarrollo.
Fuente: Metodología Daniel Villanueva derechos de autor.
36
Cada una de las etapas de la metodolgoía son descritas a continuación:
1) Etapa 1: en esta etapa, se lleva a cabo el diseño de los componentes elec-
trónicos (sensores y actuadores), que se integrarán en el sistema de monitoreo para
colmenas, además de considerar los tipos y tecnologías del momento.
2)Etapa 2: la etapa permite para construir un prototipo funcional a partir del
Software y Hardware seleccionado, además de obtener un primer análisis para su fina-
lización.
3) Etapa 3: en esta etapa, se revisan los posibles servicios necesarios para el sis-
tema. En este caso, el sistema utiliza el almacenamiento de datos forzados de la plata-
forma FIWARE Cloud.
4) Etapa 4: en esta etapa, se definen los protocolos necesarios para la comu-
nicación. En este caso, el sistema usa un protocolo de comunicación WiFi usando
Cloudino-IoT.
5) Etapa 5: la etapa permite generar, diseñar y construir un modelo para la ges-
tión de los datos obtenidos por el sistema de monitoreo de colmenas. En este caso, el
sistema utiliza el modelo de datos Orion Context Broker (OCB).
6) Etapa 6: en esta etapa, se lleva a cabo una validación del sistema, es decir, su
funcionamiento de manera integral.
7) Etapa 7: en esta etapa, la operación se lleva a cabo en un entorno real, en este
caso, en el dominio de la apicultura de precisión utilizando la colmena.
8) Etapa 8: Finalmente, la última etapa permite una evaluación final del desem-
peño del sistema de monitoreo. Por lo tanto, se discuten y concluyen los resultados del
sistema de propuesto.
En este sentido, todas las etapas de la metodología se basan en una capa de
seguridad. Por lo tanto, desde la etapa inicial hasta la etapa final, la seguridad debe
considerarse de acuerdo con su contexto. Así mismo, la metodología integra una capa
superior que define el dominio de aplicación del sistema, en este caso, la aplicación en
el dominio de la apicultura.
37
3.2 Diseño de la Solución Tecnológica Propuesta
En esta etapa de diseño del proyecto se presenta la arquitectura del sistema, es decir
los elementos en los cuales se divide el sistema, se presenta el diagrama a bloques del
hardware del dispositivo y se detalla cada uno de sus elementos, se realizan los cálculos
y se diseña el sistema de conexionado eléctrico posteriormente se desarrolla el softwa-
re y se presenta el prototipo funcional desarrollado.
3.2.1 Arquitectura para el diseño del SIMAP-MX2020
La figura 9 muestra la arquitectura del sistema, es del tipo cliente servidor común de
los sistemas distribuidos que ofrecen servicios ubicuos, durante el desarrollo los servi-
cios se trabajaron de manera local y posteriormente se desplegaron en FIWARE nodo
México alternando con el servidor o nodo FIWARE de España.
Figura 9. Arquitectura del sistema.
Fuente: Elaboración Propia .
38
Los apicultores o investigadores con acceso permitido pueden ingresar a la pla-
taforma de cloudino.io para seleccionar el transductor o sensor preferido y subir el
código de programación para realizar las calibraciones y obtener lecturas de los mis-
mos. Finalmente pueden acceder a la aplicación de grafana desde el navegador, para
visualizar y monitorizar de manera gráfica las lecturas y los datos obtenidos en tiempo
real, adicionalmente es posible extraer los datos en formato CSV para posteriormente
realizar una exploración y análisis inicial de la información y almacenar un registro de
los mismos.
3.3 Diagrama a bloques del Hardware Embebido
Para el desarrollo del hardware se propone el siguiente diagrama, el cual tiene una eta-
pa de transductores análogos y digitales. En cuanto a los transductores análogos se uti-
liza el convertidor ADC integrado en el ATMEGA328, así mismo para los transductores
digitales se emplea el protocolo I2C de comunicación serial, el I2C envía información
a través de una sola vía de comunicación.
La información es enviada bit por bit de forma coordinada, la lectura de cada
transductor es realizada cada 5s y enviada hacia la plataforma cloudino.io mediante el
protocolo WiFi 802.11.
Lo anterior es procesado mediante el conector de wifi cloudino, el cual tiene
preprogramado los protocolos más comunes como MQTT o el NGSI para el Orion
Context Broker, lo cual permite enviar datos e información. Podríamos ver al conector
Cloudino como un router IoT el cual nos permite configurar el sistema utilizando un
simple navegador web, la arquitectura de hardware a bloques para el SIMAP-MX2020
se presenta en la Figura 10.
39
Figura 10. Diagrama a bloques de la arquitectura de hardware.
Fuente: Elaboración Propia.
Al lado izquierdo se pueden observar la etapa de transductores así como su pro-
tocolo de comunicación empleado, en la parte inferior se puede observar que se utiliza
un regulador de voltaje mas una fuente de alimentación AC/DC para energizar el dis-
positivo.El microcontrolador ATMEGA328P es el responsable de la gestión de los datos
recibidos por cualquier transductor y mediante el ESP8622-12F con antena wifi los da-
tos son enviados hacia el gateway receptor.
3.3.1 Diseño del Circuito Electrónico
Para la selección de los componentes se opto por elegir transductores los cuales fueron
comunicados mediante protocolo I2C esto con la finalidad de minimizar la cantidad de
buses para la transmisión de los datos. Así mismo para el transductor análogo se utiliza
un GPIO con convertidor ADC.
El ATMEGA328P trabaja a una frecuencia de 16MHZ, el mismo se enlaza hacia
el dispositivo cloudino mediante los GPIOS PD0 Y PD1 los cuales hacen referencia a
40
TXD y RXD es decir el puerto serie. la Figura 11 muestra el diagrama eléctrico en la
configuración maestro esclavo .
Figura 11. Configuración Maestro Esclavo.
Fuente: Elaboración propia.
El integrado AMS117 es el responsable de alimentar medianteun circuito acon-
dicionador de corriente el ESP8266-12F, el AMS117 es un regulador de voltaje de 5V con
una corriente de salida de 800mA.
Una solución propuesta para detectar la apertura de la colmena es medir la can-
tidad de luz al interior de la misma, cuando la tapa esta puesta mientras se encuentra
cerrada la colmena. Esta condición de poca luminosidad se mantiene hasta que el téc-
nico apicultor levanta la tapa para realizar su revisión periódica, y se repite en prome-
dio cada 15 días acorde a su calendarizaciòn y tipo de manejo apícola . Por lo que una
apertura de la colmena ajena a su programación seria un indicador para disparar una
alerta. Esta variación de luz es monitorizada mediante la integración de una fotorre-
sistencia al interior de la colmena, para esto se utilizo una LDR de 100K a través de un
circuito divisor de tensión conectado a una resistencia de igual valor como se muestra
en la Figura 12.
41
Figura 12. Fotorresistencia.
Fuente: Elaboración propia.
Para determinar el voltaje de salida Vo variable que la LDR entregara en función
de la cantidad de luz recibida, podemos realizar un circuito analógico como el que se
muestra en el Figura 13.
Figura 13. Divisor de Tensión.
Fuente: Elaboración propia.
42
Analizando el circuito de la Figura 13 es posible determinar la corriente total
acorde a la ecuación matemática (4).
IT =V /R1 +R2 (4)
Donde R1 representa a la LDR con valor a 100k y R2 representa a la resisten-
cia pull down con el mismo valor. Así mismo para determinar el voltaje de salida V0
podemos utilizar la ecuación (5).
V0 = IT ∗R2 (5)
Finalmente sustituyendo la ecuación matemática 4 en 5 obtenemos.
V0 = (V /R1 +R2)∗R2 (6)
Donde V0 representa la variación del voltaje en función de la cantidad de luz
sensada a travès del divisor de voltaje. Asignamos dos valores uno máximo con R1 =
100k a plena carga para obtener un V0 = max, y uno mínimo con R1 = 0K para obtener
un V0 = mi n, el resultado se muestra en la ecuaciòn 7 y 8.
Con R1 = 100k
V0 = (5V /100k +100k)∗100k =V0 = 2.5v (7)
Con R1 = 0
V0 = (5V /0k +100k)∗100k =V0 = 5v (8)
Así se pudo determinar que a medida que se incrementa el valor de la fotorre-
sistecia el voltaje de salida disminuye a la mitad, de la misma manera que si el valor de
la fotorresistencia disminuye el voltaje de salida aumenta a su máximo valor 5v.
43
Así pues el experimento realizado para demostrar la detección de umbral ha-
ciendo referencia a la apertura de la tapa, consistió en abrir la tapa de la colmena du-
rante el día, la tarde y la noche mientras se registraban las lecturas del transductor,
los resultados y la implementación se muestran en el capitulo 4. Para realizar las me-
diciones de humedad relativa y temperatura se utilizaron los transductores SHT21 Y
HTU-21 mediante el modulo GY-21P. La figura 14 muestra el modulo GY-21P utilizado
para el desarrollo.
Figura 14. Modulo de Desarrollo GY-21P.
Fuente: Reproducción integra de[]
El modulo GYP-21P se comunica mediante el protocolo I2C o bus de una sola
linea su diagrama de conexión eléctrico se muestra en la Figura 15.
Figura 15. Conexiòn modulo GY-21P y ATMEGA328.
Fuente: Elaboración propia.
44
Para la conexión del modulo GY-21P se utilizaron los GPIOS PC5 y PC4 DEL
ATMEGA328P correspondientes a SCL Y SDA, así mismo la alimentación del modulo
se conecta a 3.3v y GND.
Para calibrar el SHT21 transductor de temperatura se utilizo in situ la compa-
ración con una termopar mediante un multimetro klein tools, el primer experimento
consistió en tomar lecturas de ambos transductores de manera independiente transcu-
rrido un tiempo de 10 minutos antes de registrar manualmente las lecturas, se tomaron
la misma cantidad de muestras para posteriormente ser analizadas.
Una análisis nos ayudo para determinar si existía una diferencia estadística sig-
nificativa entre las lecturas de ambos.
Figura 16. Calibración in situ.
Fuente: Elaboración propia.
En la Figura 16 se puede observar que la termopar fue introducía a través de la
piquera, después se registraron manualmente 100 registros mismos que fueron com-
parados con los registros de temperatura obtenidos mediante cloudino provenientes
del modulo GY-P21.
Para comprobar que la distribución de las lecturas de temperatura son norma-
les se aplico a las 100 muestras registradas el test de normalidad shapiro-wilk y kolmo-
gorov, los resultados son presentado en el capitulo 4 implementación y resultados.
45
Para determinar el peso de la colmena se utilizo un modulo Hx711 con un arre-
glo en puente de whetstone para cuatro celdas de carga con capacidad de carga de
hasta 50 kg cada una, la conexión de las celdas con el modulo Hx711 se muestra en la
Figura 17.
Figura 17. Arreglo de modulo Hx711 y celdas de carga.
Fuente: Elaboración propia.
Una caja para colmena del tipo langstroth puede llegar a pesar aproximada-
mente 200 kg, esto se debe a que el diseño de este tipo de colmena permite añadir
hasta cuatro alzas a medida que la población de abejas se incrementa.
Por lo que se emplearon un arreglo de cuatro celdas con capacidad de carga de
hasta 50 kg cada una, con lo cual fue posible monitorizar la variación de peso a plena
carga del porta núcleo.
Como parte de la instrumentación se diseño una base de madera para ser colo-
cada en el piso a la cual se realizaron cuatro desbastes en cada esquina al tamaño de
las celdas, la base con los transductores se muestra en la Figura 18.
46
Figura 18. Celdas de carga instrumentadas.
Fuente: Elaboración propia.
Así mismo una vez que termino de ser instrumentada la base,la misma fue co-
locada y ajustada de bajo del porta núcleo como se muestra en la Figura 19.
Figura 19. Base con transductores de peso.
Fuente: Elaboración propia.
La calibración de los transductores de peso se realizo mediante software embe-
bido in situ inicialmente se coloco un peso conocido medido con una balanza de alta
precisión para laboratorio, pesando un objeto de 300g, posteriormente se realizo me-
47
diante software la calibración. Calculando las compensaciones iniciales del sistema y
posteriormente se realizo las lecturas y registros.
3.4 Desarrollo de Software
A continuación la Figura 20, presenta un diagrama general sobre el flujo de los datos
que representa los procesos de software.
Figura 20. Diagrama de flujo software.
Fuente: Elaboración propia.
La lectura de los transductores de peso, temperatura, humedad relativa y pun-
to de rocío fue enviada mediante protocolo I2C hacia la plataforma cloudino.io, ahí
una entidad desarrollada en JSON nos permite conectar los tópicos que identifican o
hacen referencia al nombre de las variables que contienen los datos, una vez enlaza-
da la plataforma cloudino mediante la entidad, los valores son recibidos por orionCB
y replicados mediante quantumleaps hacia crateDB para finalmente ser gráficados, la
implementación y resultados se enuncian en el capitulo cuatro.
48
Capítulo 4
Implementación y Resultados
Capítulo 4. Implementación y Resultados.
4.1 Implementación de Hardware
4.1.1 Diseño de la solución tecnológica
Para la implementación del sistema se parte de un diseño tecnológico. Este primer di-
seño incorporaba un transductor de temperatura y humedad DHT11 un MP5060 ace-
lerómetro y giroscopio de 3 ejes alimentados mediante una pila 9v. El primer prototipo
desarrollado puede observarse en la Figura 21.
Figura 21. SIMAP-MX2020 v1.
Fuente: Elaboración propia.
Para instrumentar este primer prototipo funcional, fue necesario retirar un bas-
tidor del porta núcleo, un núcleo portable como el utilizado contiene hasta cinco, los
cuales cumplen diversas funciones, como lo es la reserva de miel o la cámara de la cría
que comúnmente se localiza en el centro, por lo que se opto por retirar un bastidor de
un extremo donde no se afectase a la cría, generando un espacio donde fue introduci-
do el dispositivo mediante dos cintas con velcro adhesivo, la implementación de este