Un middleware para la gestión labores agrícolas en un ...

Un middleware para la gestión labores agrícolas en un ambiente de internet

de las cosas.

Jose Luis Rivas Viedman [email protected]

Tesis de Maestría presentada para optar al título de Magíster en Ingeniería de Software

Asesor: Hugo Armando Ordoñez Erazo, Doctor (PhD) en Ingeniería Telemática.

Universidad de San Buenaventura Colombia

Facultad de Ingenierías

Maestría en Ingeniería de Software

Santiago de Cali, Colombia

2018

Referencia/Reference

Estilo/Style: IEEE (2014)

J.L. Rivas Viedman, “Un middleware para la gestión labores agrícolas en

un ambiente de internet de las cosas.”, Tesis Maestría en Ingeniería de

Software, Universidad de San Buenaventura Cali, Facultad de Ingenierías,

2018.

Maestría en Ingeniería de Software, Cohorte IV.

Bibliotecas Universidad de San Buenaventura

• Biblioteca Fray Alberto Montealegre OFM - Bogotá.

• Biblioteca Fray Arturo Calle Restrepo OFM - Medellín, Bello, Armenia, Ibagué.

• Departamento de Biblioteca - Cali.

• Biblioteca Central Fray Antonio de Marchena – Cartagena.

Universidad de San Buenaventura Colombia

Universidad de San Buenaventura Colombia - http://www.usb.edu.co/

Bogotá - http://www.usbbog.edu.co

Medellín - http://www.usbmed.edu.co

Cali - http://www.usbcali.edu.co

Cartagena - http://www.usbctg.edu.co

Editorial Bonaventuriana - http://www.editorialbonaventuriana.usb.edu.co/

Revistas - http://revistas.usb.edu.co/

Biblioteca Digital (Repositorio)

http://bibliotecadigital.usb.edu.co

AGRADECIMIENTOS

A mi familia por su infinito apoyo aún en mis momentos más difíciles, a mi

esposa por su paciencia y comprensión, a mis hijos por ser mi mayor

motivación, a la ingeniera Beatriz Grass por su comprensión y ayuda cuando

quise claudicar, al doctor Hugo Ordoñez por su apoyo, por trasmitirme la

tranquilidad necesaria para no apresúrame y culminar satisfactoriamente este

proyecto.

A la Universidad de San Buenaventura seccional Cali por poner a mi disposición

los medios materiales y recurso humano necesarios para culminar esta tesis.

A Cenicaña por darme el tiempo, el apoyo y los recursos que me facilitaron

alcanzar los objetivos propuestos.

Y en especial a Dios por permitirme llegar a este momento tan especial de mi

vida, por darme la fortaleza para superar las dificultades y la tranquilidad para

asumir con humildad los objetivos alcanzados.

Contenido

CAPÍTULO I – INTRODUCCIÓN ................................................................................................... 1

1.1. JUSTIFICACIÓN .............................................................................................................. 3

1.2. OBJETIVOS .................................................................................................................... 4

1.2.1. OBJETIVO GENERAL .................................................................................................................. 4

1.2.2. OBJETIVOS ESPECÍFICOS. ........................................................................................................... 5

1.3. RESULTADOS OBTENIDOS .............................................................................................. 5

1.4. ORGANIZACIÓN DEL DOCUMENTO ................................................................................. 6

CAPÍTULO II – MARCO TEÓRICO ................................................................................................ 7

2.1. CONCEPTOS ESTUDIADOS ..................................................................................................... 7

2.1.1. MIDDLEWARE ......................................................................................................................... 7

2.1.2. INTERNET DE LAS COSAS - IOT .................................................................................................... 8

2.1.3. SENSORES Y ACTUADORES ......................................................................................................... 9

2.1.4. SENSORES DE MATRIZ GRANULAR .............................................................................................. 10

2.1.5. SISTEMAS BASADOS EN REGLAS ................................................................................................ 11

2.1.6. MQTT Y MQTT-SN, PROTOCOLOS PARA LA IOT ........................................................................ 12

2.1.7. 3. 1.6. SISTEMAS BASADOS EN REGLAS ECA ............................................................................... 13

2.1.8. NODE.JS ............................................................................................................................... 13

2.1.9. MÓDULO XBEE ..................................................................................................................... 14

2.1.10. MODEM ............................................................................................................................... 14

CAPÍTULO III – ESTRATEGIA PROPUESTA .................................................................................. 16

3.1. SAMIOT - MIDDLEWARE TO SUPPORT SMART AGRICULTURE IN AN ECOSYSTEM IOT ......................... 16

3.2. ARQUITECTURA ......................................................................................................................... 16

3.2.1. MIDDLEWARES ORIENTADO A MENSAJES (MOM) ...................................................................... 16

3.2.2. MIDDLEWARE BASADOS EN AGENTES ........................................................................................ 17

3.3. DISEÑO ......................................................................................................................... 17

3.3.1. CAPA DE COMUNICACIONES. .................................................................................................... 18

3.3.2. CAPA DEL SISTEMA. ................................................................................................................ 18

3.3.3. CAPA MANEJADORA DE TRAMAS. .............................................................................................. 19

3.3.4. CAPA DE SERVICIOS ................................................................................................................ 20

3.3.5. INTÉRPRETES ......................................................................................................................... 21

3.4. FLUJO DE COMUNICACIÓN ENTRE LOS COMPONENTES ............................................................... 21

3.5. MODELO DE DATOS .......................................................................................................... 23

CAPÍTULO IV. MÉTODO DE INVESTIGACIÓN ............................................................................. 25

4.1. PREGUNTA DE INVESTIGACIÓN ............................................................................................ 25

4.2. DISEÑO DE LA INVESTIGACIÓN ..................................................................................... 25

4.2.1. EL MODELO DE INVESTIGACIÓN DOCUMENTAL ........................................................................... 25

4.2.1.1. FASE PREPARATORIA .......................................................................................................... 25

4.2.1.2. FASE DESCRIPTIVA.............................................................................................................. 26

4.2.1.3. FASE DE CONSTRUCCIÓN TEÓRICA GLOBAL .............................................................................. 27

4.2.1.4. FASE DE EXTENSIÓN Y PUBLICACIÓN ...................................................................................... 27

4.2.2. MODELO PARA CONSTRUCCIÓN DE SOLUCIONES. ........................................................................ 27

4.2.2.1. ESTUDIO DE PRE-FACTIBILIDAD ............................................................................................. 27

4.2.2.2. FORMULACIÓN DEL PROYECTO ............................................................................................. 27

4.2.2.3. EJECUCIÓN DEL PROYECTO .................................................................................................. 28

4.2.2.4. VALIDACIÓN DE LA SOLUCIÓN ............................................................................................... 28

4.3. PROYECTOS ANALIZADOS ............................................................................................ 34

CAPÍTULO V – RESULTADOS Y ANÁLISIS ................................................................................... 37

CAPITULO VI – CONCLUSIONES Y TRABAJOS FUTUROS ............................................................. 42

CAPÍTULO VII – BIBLIOGRAFÍA ................................................................................................. 44

ÍNDICE DE FIGURAS

Figura 1. Internet de las cosas IoT. Fuente: postscapes. .................................................................................... 9

Figura 2. Sensor de matriz granular. ................................................................................................................ 10

Figura 3. Principio de funcionamiento bucle de eventos node,js [39] .............................................................. 14

Figura 4. Middleware architecture. .................................................................................................................. 16

Figura 5. Abstracción de componentes de middleware .................................................................................... 18

Figura 6. Flujo de operaciones del middleware. ............................................................................................... 21

Figura 7. Modelo de datos común. ................................................................................................................... 24

Figura 8. Sistema de Comunicación para una Red de Monitoreo de pluviómetros en el Valle del Cauca. ....... 29

Figura 9. Código java script que simula múltiples conexiones concurrentes. ................................................... 30

Figura 10. Comportamiento de la CPU vs la memoria RAM, según el número de conexiones simultaneas en el

middleware. ...................................................................................................................................................... 30

Figura 11. Mapa del campo del viento. Fuente Cenicaña, software SINPAVESA. ............................................ 32

Figura 12. Diferencia de velocidad/dirección del viento un punto de interés y cuatro puntos de medición. ... 32

Figura 13. Flujo de información para generar mapa campo del viento. .......................................................... 33

Figura 14. Captura de pantalla SINPAVESA. Fuente CENICAÑA ....................................................................... 34

Figura 15. Red híbrida implementada en el sitio de monitoreo. Fuente [43] ................................................... 38

Figura 16. Curvas de potencial mátrico para cada sensor de matriz granular. ................................................ 40

Figura 17. Curvas de potencial matricial un período de tiempo ....................................................................... 40

ÍNDICE DE TABLAS

Tabla 1. Especificaciones del módulo xbee pro 900 hp 200kb [43] .................................................................. 14

Tabla 2. Frame formats supported by the middleware. ................................................................................... 22

Tabla 3. Formato de trama red Xbee. ............................................................................................................... 23

Tabla 4. Características en las cinco herramientas más relevantes ................................................................. 26

Tabla 5. Tabla porcentaje de consumo de CPU y memoria por número de conexiones ................................... 31

Tabla 6. Profundidad y agrupación de sensores de matriz granular. ............................................................... 39

RESUMEN

A medida que se suple la necesidad de monitorear las variables de nuestro entorno,

aumenta el número de sensores, estándares, formatos de datos y heterogeneidad de la

información disponible para analizar; haciendo que estos sistemas se hagan más complejo

y, como consecuencia las soluciones genéricas para gestionarlos y controlarlos alcanzan sus

límites. En cualquier campo y específicamente en agricultura, los middlewares pueden

facilitar proceso de integrando dispositivos a través de nodos agrícolas inteligentes,

apoyando la interoperabilidad entre las diversas aplicaciones y servicios desarrollados o

existentes. Recientemente, ha habido una serie de propuestas de middlewares para IoT;

todos aportan beneficios, pero se limitan en el número de variables o tramas capaces de

procesar.

Debido a esta limitante y con la necesidad mejorar la producción de caña de azúcar a través

del uso eficiente del agua requerida, el sector azucarero en el valle del río Cauca, Colombia,

ha decidido realizar el monitoreo del potencial mátrico del suelo, permitiéndoles

determinar el momento justo para realizar el riego, impactando de manera positiva en la

conservación del medio ambiente y mejorando la rentabilidad.

Este documento describe nuestro middleware, el cual permitirá la creación de sistemas

complejos, capaz de procesar cualquier tipo de trama con una intervención básica del

usuario, que sirvió para ayudar a Cenicaña a resolver su necesidad de definir cuándo y

cuánto regar.

Palabras clave: Middleware, Internet de las cosas, Red inalámbrica de sensores (WSN).

Potencial mátrico, Eficiencia en el riego.

ABSTRACT

The monitoring of large-scale crops may require wireless sensor networks to collect

information in real time. These networks require the integration of diverse devices and

sensors. Middlewares have been used to facilitate the integration of heterogeneous

applications and services. This article presents SAMIoT, a middleware aimed at improving

the production of sugarcane through the optimization of water use. The middleware

monitors the matric potential of the soil to determine the right moment to irrigate. And

solution based on the proposed middleware was developed in the sugarcane crops in the

Cauca River Valley in Colombia.

Keywords: Middleware, Internet of Things (IoT), Wireless Sensor Networks (WSNs), Matric potential, Efficient irrigation.

CAPÍTULO I – INTRODUCCIÓN

La explotación agrícola a gran escala puede alcanzar grandes áreas de terreno, en este

sentido el monitoreo de estas áreas hace necesario desplegar redes de sensores

inalámbricos (WSN) basadas en Intenet of Things (IoT) que permitan interconectar gran

número de sensores u objetos, con el propósito de recopilar información de distintas

variables en tiempo real, en el área del cultivo y en donde se distribuye la red de sensores

[1]. De esta forma, el conocer la mayor cantidad de información del entorno monitoreado,

permite tomar decisiones rápidas y precisas con respecto a las labores agrícolas a realizar,

como por ejemplo en el cultivo de la caña de azúcar.

El sector azucarero en el valle del río Cauca, Colombia, ha decidido realizar un monitoreo

de las variables precipitación y potencial mátrico que permita determinar el momento

justo para realizar el riego, basado en la recolección de información de estas variables;

permitiendo mejorar la producción de caña de azúcar y hacer más eficiente el uso del agua

requerida, impactando de manera positiva en la conservación del medio ambiente y

mejorar la rentabilidad de toda la cadena de suministro [2]. En este sentido, el monitoreo

permite tomar decisiones de manejo oportunas que permitan el suministro de agua en las

explotaciones agrícolas. Por otro lado, es necesario determinar el momento oportuno para

realizar de manera eficiente la labor de riego, es decir cuando, cuanto y como regar los

cultivos.

Existen diversos métodos para la programación de los riegos, unos basados en la

cuantificación de los diferentes componentes del balance hídrico para estimar un nivel de

agotamiento permisible del agua en el suelo y otros basados en el monitoreo del estado

hídrico del suelo o la planta [3]. Cenicaña (Entidad dedicada a la investigación de la caña de

azúcar) ha probado y recomendado otros métodos para la programación de los riegos como

el uso del tanque Cenirrómetro [4], la instalación de pozos de observación del nivel freático,

la verificación de la humedad del suelo [5] y, si bien el balance hídrico es el método más

2 Un middleware para la gestión labores agrícolas en un ambiente de internet de las cosas. Jose Luis Rivas Viedman, Jose

Hugo Armando Ordoñez Erazo (Director), José Armando Ordóñez Córdoba (Co-Director)

usado entre los cultivadores de caña en el valle del río Cauca para programar la ejecución

del riego [6], se requiere incorporar aspectos relacionados con las propiedades hidrofísicas

de los suelos, pero en este valle del río Cauca existe una alta heterogeneidad de suelos

(alrededor de 238), alta variabilidad de las precipitación entre otras. Esta variabilidad e

incertidumbre ha determinado el disponer de un área piloto con sensores de humedad y

de potencial mátrico, para monitorear continuamente el estado energético del agua en el

suelo y por lo tanto, mejorar la precisión en la programación de los riegos, permitiendo

lanzar alarmas o abrir compuertas o válvulas cuando la cantidad de agua disponible para la

planta se encuentre en su capacidad de campo [7] o contenido de humedad de un suelo

bien drenado, es decir entre ± -20 y por encima de ± -80 kPa [8][9][10] apoyando al modelo

de balance hídrico.

Para minimizar los impactos que conlleva el uso no eficiente del agua en la agricultura, es

necesario realizar investigaciones que conlleven a determinar tanto el consumo y la

disponibilidad de agua para la planta.

Una alternativa para el monitoreo del uso del agua en la agricultura es la incorporación de

las tecnologías de información basada en la IoT, las cuales aporta ventajas y oportunidades

de automatización y optimización en la captura de información integrando redes de

sensores los cuales permiten identificar, detectar, procesar y entregar datos e información

de las variables a monitorear en los cultivos y/o el suelo donde estos se encuentran

sembrados.

La IoT permite el despliegue de sensores y redes WNS que en la agricultura se utilizan para

monitorear diferentes variables tales como la temperatura, precipitación, radiación entre

otras. Si bien existen soluciones que pueden servir para incorporarse dentro de un

ecosistema IoT y que estudiaremos más adelante, la mayoría están dirigidas principalmente

a una única aplicación, para lo cual, son desplegadas sólo en su área de interés específica

[11]; por ejemplo, para aplicaciones de teledetección de variables en viticultura [12], para

el seguimiento de cultivos hortícolas [13] y para la gestión eficiente del agua de riego [14].

Entre tanto [15] estudia el grado de salinidad en una plantación de caña de azúcar.



Debido a que los sensores usados en la agricultura no están dotados de inteligencia, en este

documento se presenta SAMIoT un middleware que permite la comunicación de los

sensores pertenecientes a una WSN con Nodos Agrícolas Inteligentes en un ambiente IoT,

capaz de manejar eventos en tiempos cercanos al real, mediante conexiones TCP a través

de sockets proporcionados por el mecanismo de extensión modular de Node.js [16]. El

middleware permite la integración de una serie de elementos para facilitar la configuración

de un dispositivo en el ecosistema IoT, gestionar y configurar nuevas condiciones, enviar

comandos hacia los “Nodo Agrícola Inteligente” o dispositivo de hardware autónomos o

leer la información de los sensores agrícolas conectados a él y enviar la información a un

servidor [17]. En esencia, el middleware permite monitorear variables que contribuyan a

disminuir la incertidumbre que existe con respecto a la alta variabilidad de la precipitación,

contenido volumétrico de agua del suelo y los periodos de recarga y drenaje del agua en el

suelo.

1.1. JUSTIFICACIÓN

El consumo de agua en la agricultura y principalmente el riego, constituye una de las labores

de campo más costosas y esto, sin tener en cuenta que los precios del agua comúnmente

reflejan sólo el costo del suministro de agua en el cultivo y generalmente no transmiten

señales económicas a los mercados [1], ocultando de cierta manera el impacto ambiental

que esta actividad pueda causar.

El balance hídrico nace como una alternativa para satisfacer la necesidad de optimizar el

uso del agua, reducir costos, reducir el riesgo de lavado de nutrimentos y lo más importante

disminuir el riesgo del impacto ambiental sobre los caudales de agua y sobre las aguas

subterráneas. Sin embargo, el uso del balance hídrico no siempre aporta resultados

satisfactorios debido a diferentes factores tales como: la incertidumbre en la distribución

de agua en el suelo, la alta variabilidad de las precipitaciones y las propiedades físicas y

químicas del mismo [6].



Para minimizar los impactos que conlleva este uso inadecuado de agua en la agricultura, es

necesario realizar investigaciones que faciliten conocer las condiciones físicas y químicas de

los cultivos casi en tiempo real, así como de las condiciones y propiedades del suelo del cual

se nutren las plantas y el desarrollo de herramientas que permitan su captura y transporte.

Si bien, en el mercado se encuentran herramientas como las propuestas en [3][4][5] que

podrían contribuir al desarrollo de soluciones IoT, se evidencia que en su desarrollo no se

han tenido en cuenta las restricciones o limitaciones del entorno agrícola. Debido a lo

anterior y a que los sensores usados en la agricultura no están dotados de inteligencia, y

con la necesidad de medir variables que permitan determinar tanto el consumo y la

disponibilidad de agua para la planta, se hace necesario realizar investigaciones que

permitan incorporación de las tecnologías de información basada en la IoT, sensores

conectados a Nodos Agrícolas Inteligentes y pertenecientes a una WSN [18][19] con centros

de almacenamiento y análisis de datos; que permitan ventajas y oportunidades de

automatización y optimización en la captura de información con el fin de identificar,

detectar, procesar y entregar datos e información de las variables a monitorear en los

cultivos y/o el suelo donde estos se encuentran sembrados. En esencia, el middleware

permite monitorear variables que contribuyan a disminuir la incertidumbre que existe con

respecto a la alta variabilidad de la precipitación, contenido volumétrico de agua del suelo

y los periodos de recarga y drenaje del agua en el suelo.

1.2. OBJETIVOS

1.2.1. Objetivo general

Construir un middleware de soporte a labores agrícolas, que permite gestionar la

información de sensores en un ambiente de internet de las cosas, utilizando un motor de

reglas basado en lenguaje natural independizando la heterogeneidad de las tramas en

intérpretes, modelando la captura y heterogeneidad de las tramas como un sistema de

reglas basado en intérpretes.



1.2.2. Objetivos específicos.

• Diseñar un middleware que permita realizar la gestión de sensores en un ambiente

de la IoT, aplicado a la agricultura.

• Modelar el proceso de captura como un sistema de reglas. Definir el motor de reglas

basado en lenguaje natural, que permitan realizar acciones en el middleware.

• Desarrollar un prototipo del middleware que permite la interacción con sensores y

actuadores.

• Evaluar experimentalmente el comportamiento de las variables gestionadas por el

middleware.

1.3. RESULTADOS OBTENIDOS

A continuación, se listan los resultados/productos obtenidos con el desarrollo de la

presente investigación:

• Monografía del trabajo de grado. Corresponde al presente documento, donde se

describe el proceso seguido en el desarrollo del proyecto, la soluciones alcanzada,

los aportes más sobresalientes, las conclusiones y recomendaciones para el

desarrollo de futuras investigaciones.

• Presentación a revisión artículo científico al “The Third International Conference on

Universal Accessibility in the Internet of Things and Smart Environments - SMART

ACCESSIBILITY 2018 - March 25, 2018 to March 29, 2018 - Rome, Italy”.

• Arquitectura del middleware donde se mezcla la abstracción de dos enfoques de

arquitecturas de middlewares – Los Middlewares Orientado a Mensajes (MOM) y

los Middleware Basados en Agentes.

• Un prototipo de middleware funcional y probado en un entorno real y productivo.

El middleware está actualmente operativo en el Centro de Investigación de la Caña

de Azúcar de Colombia. Hasta la creación de este documento captura 36 variables

de condiciones climáticas en cada una de 12 estaciones meteorológicas, 2 variables



de precipitación de cada uno de 9 pluviómetros y 7 variables de matriz granujal de

cada una de 5 estaciones de potencial mátrico.

1.4. ORGANIZACIÓN DEL DOCUMENTO

En el Capítulo II del presente documento se describe todo el marco teórico que soporta la

investigación realizada. Se detallan los temas de Middleware, Internet de las Cosas - IoT,

Sensores y actuadores, Gestión de eventos (Eventing), Sistemas ECA, MQTT y MQTT-SN y

protocolos para la IOT. En la Capítulo III se presenta la se presenta la arquitectura que

soporta el middleware y se describe cada uno de sus componentes. En el Capítulo IV se

detalla el planteamiento de la hipótesis del trabajo investigativo, cómo se evalúa dicha

hipótesis, cómo se realiza la investigación y cómo se evalúan sus resultados. En el Capítulo

V se presentan los resultados obtenidos. En el Capítulo VI se presentan las conclusiones a

las que se llega después de la investigación realizada, además de posibles trabajos futuros.

En el Capítulo VII se presenta la bibliografía.

CAPÍTULO II – MARCO TEÓRICO

Una implementación de la IoT en cualquier tópico involucra muchos procesos y tecnologías

tales como: sensores y actuadores, sistemas basados en reglas, programación orientada a

eventos, entre otros. Lo que hace necesario realizar un breve estudio de estos conceptos,

de manera que permita un mayor entendimiento de los requisitos que se deben tener en

cuenta, a la hora de desarrollar o implementar un middleware para dar soporte a cualquier

dominio el desarrollo de la IoT.

2.1. CONCEPTOS ESTUDIADOS

2.1.1. Middleware

Existen muchas definiciones para middleware en la industria de TI. Sin embargo en

generalmente encontramos que el término middleware se relaciona con cualquier

programa o trozo de programación que sirve para "pegar entre sí" o mediar entre dos

programas separados, a menudo ya existentes [20].

Estudios realizados en [20][21][24], presentan un definición que describe la mayoría de los

productos de middleware disponibles en la actualidad. Definiéndolo como un software que

ayuda a una aplicación a interactuar o comunicarse con otras aplicaciones, redes, hardware

y / o sistemas operativos. Este software ayuda a los programadores, alivianándoles la

compleja tarea de generar las conexiones que son necesarias en los sistemas distribuidos.

Proporcionan herramientas para mejorar la calidad de servicio (QoS) , la seguridad , el paso

de mensajes , servicios de directorio, servicios de archivos , etc., que pueden ser invisibles

para el usuario.



Mientras tanto en Middleware Resource Center definen un middleware, como cualquier

software que permite que otros softwares puedan a interactuar, aunque también precisan

que existen varios tipos [22] de ellos.

Middleware Orientados a Mensaje (MOM): Esta categoría permite almacenamiento

asíncrono y capacidades de aplicar mensajería a plazo, así como los corredores de

integración que realizan la transformación y enrutamiento de mensajes o incluso la

coordinación de procesos de negocio.

Objeto Middleware: Esta categoría consiste en gran parte de orquestadores de petición de

objetos.

RPC Middleware: Este tipo de middleware proporciona para llamar a procedimientos en

sistemas remotos y representa interacciones sincrónicas entre los sistemas y se utiliza

comúnmente dentro de una aplicación.

Middleware de base de datos: Middleware de base de datos permite el acceso directo a las

estructuras de datos y proporciona una interacción directa con las bases de datos. Hay

puertas de enlace de base de datos y una variedad de opciones de conectividad. Extract,

Transform, Load y paquetes (ETL) están incluidos en esta categoría.

Transacción Middleware: Esta categoría incluye monitores tradicionales de procesamiento

de transacciones (TPM) y servidores de aplicaciones web.

2.1.2. Internet de las Cosas - IoT

El término internet de las cosas fue acuñado en 1999 por Kevin Ashton, según él, fue la

forma de llamar la atención de los ejecutivos [23], en la vinculación de la nueva idea de la

RFID en la cadena de suministro de P & G, pero el término tomó fuerza en el año 2004,

luego de la publicación de un artículo en la revista Scientific American en una conferencia

de la Unión Europea[23][24].

Sin embargo, en la actualidad la IoT, es un concepto que en general emerge como una de

las principales tendencias que dan forma al desarrollo de tecnologías en el sector de las TIC

[25].



Esta usa la Internet para interconectar dispositivos de usuario o dispositivos físicos con

otros objetos figura 1; obligando de alguna manera a repensar de nuevo algunos de los

enfoques convencionales utilizados habitualmente en la creación de redes, computación y

servicio de aprovisionamiento / gestión de dispositivos e información[25].

Otros estudios [26] aseguran que las capacidades que ofrece la IoT pueden salvar vidas y

ayudar a las organizaciones a ahorrar tiempo y dinero, así como ayudar a mejorar la toma

de decisiones y los resultados en una amplia gama de áreas de aplicación.

Figura 1. Internet de las cosas IoT. Fuente: postscapes.

2.1.3. Sensores y actuadores

Lo sensores son dispositivos, que permiten detectar magnitudes físicas o químicas y

transformarlas en variables eléctricas. En un ecosistema, estos dispositivos hacen parte del

nivel de captura y permiten medir y obtener datos de un entorno físico; en este grupo se

pueden encontrar sensores de temperatura, de presión, o una smart label entre otros[27].

Los actuadores son dispositivos que permiten realizar acciones específicas sobre el entorno

físico.

Los actuadores más comunes se dividen en dos grupos, los accionadores, que se encargan

de aportar energía para modificar los valores de magnitud física como la luz, el calor y la



potencia entre otros. Y los acondicionadores de señal que intermedian en la amplificación

o conversión de una señal y para producir movimiento que permita modificar o maniobrar

un relé, contactor o electroválvula [27].

2.1.4. Sensores de matriz granular

Los sensores de matriz granular son extremadamente convenientes para mediciones de

potencial hídrico [28], porque no requieren de flujo de aire o exposición a periodos de

secado, los sensores registran los datos con la llegada del nuevo evento de mojado. Además,

estos sensores tienen un costo bajo y, utilizando cables eléctricos largos, se pueden

minimizar el impacto de estrés que se pueda causar a las plantas y los suelos que se

pudieran ocasionar por el proceso de monitoreo [29].

Descripción: El sensor se compone de electrodos incrustados en un material de cuarzo

granular, con el fin de minimizar los efectos de salinidad. Los poros de la lámina en el sensor,

permite mediciones en suelos más húmedos y a su vez los hace más duraderos que otros

sensores como los bloques de yeso. La mezcla de todos sus materiales permite mediciones

de humedad del suelo cercanas a la saturación con un rango de medición entre 10 y 200

kilo pascales (kPa) figura2.

Figura 2. Sensor de matriz granular.



2.1.5. Sistemas basados en reglas

Los sistemas basados en reglas es una metodología que evalúan información de varios

dispositivos y servicios en conjunto o con información del contexto, con la cual

comprueban si las condiciones de las reglas se satisfacen de manera adecuada [30]. En su

mayoría estas reglas están asociadas al juicio de un experto o a la experiencia de un

operador. La evaluación de la información se realiza por medio de un motor de reglas, el

cual se encargará de lanzar la ejecución de las acciones correspondientes de acuerdo a la

condición.

La programación orientada a eventos y la gestión de eventos son los puntos más relevantes

en los sistemas basados en reglas, estos se describen a continuación:

• Gestión de eventos (Eventing):

La IoT, es un soporte para la automatización de algunos procesos dentro de cualquier

entorno, de manera que la gestión de eventos desempeña un rol muy importante en el

desarrollo de cualquier solución que busque facilitar la interconexión de dispositivos.

En su estudio [31], propone un marco general para la detección de eventos compuestos

que trabajan en la parte superior de una serie de sistemas publicador/subscriptor. Este

marco incluye un lenguaje genérico para especificar y detectar eventos compuestos de

una manera distribuida.

Entre tanto [30], presenta un entorno de computación ubicua que se compone de

dispositivos activos y autónomos que interactúan entre sí a través de servicios web, y

presenta un marco basado ECA (Evento-Condición-Acción) para la coordinación efectiva

de dichos dispositivos.

Por otra parte [32], discute cómo construir una infraestructura SOA basada en eventos,

donde se pueda utilizar información de recursos para crear servicios de IoT, utilizando

eventos independientes y compartidos para ejecutar los servicios , así como disponer de

la sesión del evento para coordinar estos servicios.

• Programación orientada a eventos:



La programación orientada a eventos, es uno de los paradigmas de programación que se

adapta muy bien al IoT, en el marco de una coordinación eficaz de los dispositivos [30].

Este tipo de programación se basa en un modelo de comunicación en el que interactúan

dos o más elementos, ocupándose básicamente de dos roles; unos que actúan como

productores de eventos y otros como consumidores de los mismos, donde la iteración

continúa entre ellos está enmarcada por dos funciones, la selección de eventos y la

gestión de eventos [33]. Los productores generan información (con un formato

preestablecido) y la distribuyen a través de un intermediario que se encarga de orquestar

actividades como gestionar la información y distribuir los eventos.

2.1.6. MQTT y MQTT-SN, protocolos para la IOT

Estos paradigmas de programación son comúnmente soportado por un protocolo MQTT,

definida por IBM [34].

Este protocolo ha sido seleccionado recientemente por OASIS4, como uno de los protocolos

destinados a soportar el paradigma de la IoT. Además de esto, desde que IBM liberara la

especificación de este protocolo, su uso ha crecido paulatinamente, llegando a estar en

auge en la actualidad. En este aspecto cabe destacar la contribución del Eclipse Paho

Project, un proyecto que está en continuo desarrollo por la fundación Eclipse, cuyo objetivo

es implementar clientes MQTT en varios lenguajes de programación, como Java, C o

JavaScript, y que publicó su primera versión de las librerías MQTT en junio de 2014.

En esencia, MQTT es un protocolo muy ligero, asíncrono y basado en la

publicación/suscripción de mensajes. Sus principios de diseño lo hacen ideal para

paradigmas emergentes como M2M, la IOT, las aplicaciones móviles y las redes de sensores.

MQTT opera sobre redes TCP/IP. Consecuentemente, este protocolo no puede ser

ejecutado directamente sobre una red de sensores ya que estas no tienen por qué estar

adaptadas a las redes TCP/IP y generalmente tienen su propia pila de protocolos. Para

solventar este problema, IBM desarrolló MQTT-SN [35] como una extensión de MQTT

adaptada a las peculiaridades de una red de sensores.



2.1.7. 3. 1.6. Sistemas basados en reglas ECA

El concepto Evento-Condición-Acción (ECA) es un paradigma intuitivo y potente para

programación de sistemas reactivos. El uso principal de ECA es la construcción de reglas

reactivas de la forma si un evento cumple la condición, entonces haga una acción [36]. El

sistema ECA, recibe como insumos eventos del ambiente externo y reaccionan mediante la

realización de acciones internas, que cambian la información almacenada o dispara

acciones que influyen en el medio ambiente. Hay muchas áreas potenciales y existen

aplicaciones que hacen uso de este paradigma para brindar soluciones como es el caso de

[37] donde incluyen lenguajes para componer eventos, condiciones a través de querys y

acciones que definen normas de alto nivel para la descripción de la conducta en la Web

Semántica. O para gestión en tiempo real y actividades empresariales [38].

2.1.8. Node.js

Node.js es un entorno de desarrollo que permite ejecutar eventos JavaScript del lado del

servidor. Node.js ejecuta javascript utilizando el motor V8, desarrollado por Google para

uso de su navegador Chrome[39]. Si bien node.js es capaz de soportar múltiples hilos, no

depende de estos, para soportar la ejecución concurrente de la lógica de negocio sino que

se basa en un modelo asincrónico de entrada/salida de eventos [40].

Node.js es ligero y eficiente, ideal para aplicaciones en tiempo real de datos intensivos que

se ejecutan a través de dispositivos distribuidos [41], requerimiento necesario para

satisfacer los desafíos que supone la IoT.

La funcionalidad asincrónica de Node.js hace que no sea necesario dominar el problema de

la gestión de hilos; ya que en este modelo de programación, las peticiones se gestionan

internamente, de manera que la operación solicitada por el cliente es recibida a través de

bucle de hilo único para cada evento [42].

Gracias al bucle de eventos, el procesamiento de otras operaciones no es obstruido. El

principio de funcionamiento bucle de eventos se muestra en la figura 3.



Figura 3. Principio de funcionamiento bucle de eventos node,js [39]

2.1.9. Módulo XBee

Son un conjunto de circuitos integrados de tecnología inalámbrica por radio frecuencia de

un bajo costo y de bajo consumo de energía[43].

Existen diversas clases de XBee que se adecuan a una gran variedad de necesidades; para

este caso se escogió el modelo XBee PRO 900HP 200Kb. En la tabla 1 se especifican las

características de este módulo.

Tabla 1. Especificaciones del módulo xbee pro 900 hp 200kb [43]

XBee PRO 900 HP Referencia: XBP9B-DMST-002 Característica Valor

Banda de Frecuencia 902 a 928 MHz

Conector Antena RPSMA Tasa de Transferencia de Datos 200 Kb Topología de Red DigiMesh Rango de Alcance

Indoor 305 m

Outdoor 6.5 Km Consumo de Corriente

En Transmisión 215 mA En Recepción 29 mA Sleep 2.5 µA

La capacidad que tienen estos módulos de conectarse a un número de dispositivos en una

red, hace que sean una muy buena opción para redes sensoriales más grandes, con un

máximo de 65000 posibles nodos alcanzables [44][45].

2.1.10. Modem

El modem SA-G+ de Novatel Wireless Inc. fue seleccionado para la implementación de la

red, ya que soporta el estándar 3G para la transferencia de datos. Facilitando la traducción



los mensajes digitales para que estos puedan ser transmitidos y recuperados por la red

analógica, logrando una interfaz entre el mundo digital y el analógico.

CAPÍTULO III – ESTRATEGIA PROPUESTA

3.1. SAMIOT - MIDDLEWARE TO SUPPORT SMART AGRICULTURE IN AN ECOSYSTEM

IOT

En esta sección, se presenta la arquitectura que soporta el middleware, su diseño y el flujo

de comunicación entre los componentes.

La figura 4, muestra arquitectura de capas y componentes implementados para dotar al

middleware de la funcionalidad deseada.

.

Figura 4. Middleware architecture.

3.2. Arquitectura

El middleware propuesto se fundamenta en los principios de dos enfoques de arquitecturas

para el diseño de middlewares descritos en [46]; los cuales se describen a continuación:

3.2.1. Middlewares Orientado a Mensajes (MOM)



En el modelo MOM, la comunicación se basa en mensajes que incluyen extrametadata, en

comparación con los middlewares orientados a eventos, los mensajes son portadores de

direcciones de remitente y receptor; en concordancia con ello, el motor de escucha del

middleware propuesto recibe y procesa paquetes cuya estructura de trama e información

de remitente ha sido previamente definida a nivel de base de datos.

3.2.2. Middleware Basados en Agentes

Dado que Internet no tiene una solución única para todos los dominios [47]; este enfoque

facilita la gestión de recursos, reducción de la carga de la red, gestión de código; proveyendo

ejecución asincrónica y autónoma, disponibilidad, robustez, tolerancia a fallos,

adaptabilidad y heterogeneidad [46]. En este enfoque, las aplicaciones se dividen en

programas modulares llamados agentes, para facilitar la inyección de los eventos y su

distribución a través de la red, facilitando el diseño de sistemas descentralizados capaces

de tolerar fallas parciales [48]. En el middleware propuesto, este modelo está representado

por agentes sobre una capa lógica basada en intérpretes. Esto permite ofrecer una solución

middleware para la IoT completamente configurable y extensible, adaptable a diferentes

entornos operativos [49] garantizando procesar tramas muy heterogéneas

3.3. DISEÑO

La figura 5 muestra una abstracción general de la arquitectura en la que se representa las

dependencias de comunicación entre componentes del middleware, las cuatro capas de la

arquitectura se describen a continuación:



Figura 5. Abstracción de componentes de middleware

3.3.1. Capa de comunicaciones.

Es la encargada de establecer, controlar, mantener comunicación desde y hacia los

dispositivos. El proceso Listener dispone un puerto de escucha permanente, mientras que

el Dispatcher, se encarga de enviar los comandos definidos por los usuarios o aplicaciones

hacia los Nodos Agrícolas Inteligentes, estos comandos pueden ser a través de una consola

o definidos en la tabla comandos de la base de datos.

3.3.2. Capa del sistema.

Esta se encarga de proporcionar interoperabilidad técnica y lógica entre el nodo agrícola

inteligente y el middleware. Según ETSI (European Telecommunications Standards

Institute), la interoperabilidad técnica permite asociar componentes de hardware,

software, sistemas y plataformas para establecer una comunicación de máquina a máquina;

por lo general se centra en la comunicación de los protocolos y la infraestructura necesaria

para que estos puedan operar [50]. En esta capa, además se proveen los objetos que serán

instanciados en cada intérprete, también realiza tareas de validación de trama, validación

de checksum, gestiona a los objetos de acceso (DAO) y los diferentes intérpretes, entre

otras funciones.



A nivel de seguridad, se cuenta con dos procesos; en primer lugar, se aprovecha el enfoque

MOM para enviar en su extradata la dirección ip del remitente así como número de serie o

identificación registrada en la base de datos y solo así permitir la conexión entre el nodo y

el middleware, en segundo lugar; una vez establecida la conexión y recibida la trama; esta,

es enviada a un procesos de validación donde se verifica si el tipo de trama entrante ha sido

previamente registrados en la base de datos, al obtener una respuesta satisfactoria se valida

la calidad de los datos contra el valor del checksum propio de la trama. Por otro lado, la

seguridad de la transmisión se deja completamente al protocolo TCP/IP [51].

3.3.3. Capa manejadora de tramas.

Esta capa está conformada por tres procesos.

3.3.3.1. DAOCore:

Este se basa en el patrón de diseño DAO el cual independiza la lógica del middleware de la

responsabilidad de persistencia, reduce la complejidad de la lógica de transacciones y

mejora el rendimiento a través de transacciones gestionadas por contenedores [52], lo que

permite a los intérpretes definir e interactuar con diferentes bases de datos. El middleware

para el proceso de captura de información requiere una estructura mínima a nivel de base

de datos para operar; esta estructura, además de almacenar los datos de las variables

leídas, cuenta entre otras con la capacidad de almacenar información de los diferentes tipos

de tramas que serán válidos por el middleware; así como la de almacenar los nombres, Ips

o MACs de los Nodos Agrícolas Inteligentes, dispositivos o datalogger para poder cumplir

con el enfoque MOM [46] y otra para definir descriptores que permiten almacenar

identificadores de tópicos para cada websocket.

3.3.3.2. INTCore:

Gestiona los intérpretes que se encargan de analizar los diferentes formatos de mensajes

(tramas) recibidos desde los clientes y definidas en el la base de datos. Su función principal

es velar por la validez y calidad de las tramas y orquestar la entrega de la tarea de

procesamiento al interprete indicado.



3.3.3.3. TIMERProcess:

Este proceso se encuentra permanente monitoreando las reglas en la base de datos; una

vez identifique el cumplimiento de una condición, la procesa y lo despacha al Nodo Agrícola

Inteligente a través del despachador de comandos, bien sea para traer datos faltantes por

pérdida de conexión o activar acciones en un dispositivo actuador de manera que tenga un

efecto sobre la realidad física [25], como abrir o cerrar el paso de agua, encender o apagar

una máquina de bombeo de agua entre otras.

3.3.4. Capa de servicios

3.3.4.1. WebSockets:

Proporciona un canal bidireccional de comunicaciones en tiempo real para aplicaciones y

servicios web avanzados [53]. En él, se expone la información contenida en cada socket /

hilo como tópicos que podrán ser consultados por diferentes clientes; proporcionando una

comunicación en tiempo cercano al real.

3.3.4.2. Sniffer:

Este expone algunos sucesos que están ocurriendo dentro del núcleo. Fundamentalmente

es un servicio TCP que permite una conexión por medio de un cliente Telnet.

3.3.4.3. WebServices: Expone una API para consultar información o disparar eventos del

núcleo; los servicios expuestos en este son:

● list: Lista los dispositivos conectados.

● Broadcast: Envía un mensaje a todos los dispositivos conectados.

● closeByIp: Cierra la conexión con un dispositivo por medio de la ip.

● close: Cierra todas las conexiones clientes.

● closeAll: Cierra todas las conexiones clientes y reinicia el servidor core.

● ReloadInterpretes: Permite reiniciar el controlador de intérpretes y disponer

en el middleware un intérprete recientemente creado.

● sendByIp: Envia comands hacia los Nodos Agrícolas Inteligentes.



3.3.5. Intérpretes

Son archivos con rutinas de código JavaScript que permiten procesar cada formato de trama

de manera única y personalizada, si bien instancian procesos del NUCLEO, son autónomos

e impedientes y básicamente traduce las tramas enviadas desde el INTCore. El usuario del

middleware solo debe modificar dos clases, una para realizar la extracción de información

de la trama y realizar cualquier tratamiento como por ejemplo aplicar alguna ecuación,

realizar corrección de los datos o generar una notificación y la otra para ajustar los campos

al modelo antes de insertar la información a la base de datos.

3.4. FLUJO DE COMUNICACIÓN ENTRE LOS COMPONENTES

La figura 6 muestra el diagrama de comunicación entre los componentes, donde el

middleware se encuentra permanentemente escuchando por un puerto específico. Los

clientes o dispositivos (dn) se conectan al servidor a través de este puerto vía TCP/IP,

generando la apertura de un socket tcp (sn) por cliente; cada uno de estos es manejado por

un hilo (hn) garantizando así, la comunicación simultánea con múltiples dispositivos.

Figura 6. Flujo de operaciones del middleware.



La información que circula por cada hilo es pasada al intérprete, el cual parsea los datos de

acuerdo con la información preestablecido para cada tipo de dispositivo, generando así un

nivel de seguridad a las tramas, las tramas no definidas en la base de datos son descartadas.

Por otro lado, la probabilidad que se forme un cuello crítico en el flujo de la comunicación

o una sobrecarga en el proceso anterior es muy baja debido al bucle de eventos propio de

Node.js [42], lo cual se ampliará en el escenario tres del capítulo IV. Una vez validada y

procesada la trama, los datos son expuestos a través del servicio WebSocket, garantizando

una comunicación cercana al tiempo real; simultáneamente la información es enviada a la

base de datos para su almacenamiento.

Para que cada mensaje pueda ser aceptado y procesado por el middleware, este debe ser

identificado por un tipo único de mensaje de acuerdo con el formato de trama definido por

el usuario.

La tabla 2 presenta ejemplos de mensajes recibidos antes de ser procesados por los

intérpretes donde:

Tabla 2. Frame formats supported by the middleware.

Id Tipo Formato

101 Meteorológicas

101,81508,2017-02-28,14:11:00,26.83,"2017-02-28 14:10:20",26.85,27,"2017-02-28 14:10:10",0.34,52.68,"2017-02-28 14:10:50",53.13,53.56,"2017-02-28 14:10:20",1.15,"2017-02-28 14:10:00",0,0.031,1.144,0.853,0.931,36.02,14.38,1.098,"2017-02-28 14:10:20",52.24,"2017-02-28 14:10:20",0,0.014,1.196,0.931,35.94, C508^M

160 Pluviómetros 160, PL20,2017-02-26,12:30:00,0.00, f948 160 Pluviómetros XBee ~�8ï¿½�ï¿½�@Ö¼Rï¿½ï¿½ï¿½|SETI160,PL0006,2017-02-26,12:30:00,0.00,f944

166 Matriz granular 166,81506,2017-02-20,09:34:00,23.47,"2017-02-2009:34:00",23.47,23.47,"2017-02-20 09:34:00",0,71.62,"2017-02-20 09:34:00",72.1,72.91,"2017-02-20,09:34:00",1.02,"2017-02-20 09:34:00",0,0.001,1.171,0.061,0,D971

a. El id 101, es un mensaje que contiene información diaria de lecturas de diferentes

sensores de estaciones meteorológicas; la versatilidad del enfoque basado en

mensajes permite que el middleware a través de los intérpretes procese los 36

parámetros contenidos en este tipo de trama.

b. El primer id 160, corresponde a variables de pluviometría, envidas por un dispositivo

a través de una red GSM; en él, se puede observar el identificador de mensaje

(trama) 160.



c. El segundo id 160, muestra una trama que también contiene lecturas de variables

de pluviómetros enviadas por un dispositivo conectado a una red Xbee; donde el

parámetro 1 y 2 son descartados y representan la cabecera de un trama Xbee y un

delimitador respectivamente, el parámetro 3 es el identificador del tipo de trama

mientras que el parámetro 4 es el nombre o identificador asignado a un sensor que

para esta implementación es un pluviómetro; los parámetros 5, 6 corresponden

fecha y hora del dato leído por el sensor, por último está el parámetro

correspondiente al checksum, que representa la suma del número de bytes de los

parámetros 3 y 4; en otras palabras, 9 + N bytes, como se muestra en la tabla 3.

d. El id 166, corresponde a una trama que contiene lecturas de sensores de matriz

granular, con los cuales se calcula el potencial mátrico o contenido volumétrico de

agua del suelo.

El middleware válida también la calidad de la trama a través del procesamiento de

checksum, esta tarea se delega al intérprete permitiendo que la validación de calidad de los

datos sea definida por el usuario, al sumar o restar parámetros al cálculo del checksum.

Tabla 3. Formato de trama red Xbee.

3.5. MODELO DE DATOS

La figura 7 muestra el modelo de base de datos que permite un acceso común a todas las

soluciones implementadas a través del middleware; comenzando desde la parte superior

en la figura 7, vemos la entidad “estacion”. Una estación es un nodo de sensoramiento, el

cual está conformado por uno o varios dispositivos entre los que podrían encontrase:

Arduinos, Raspberrys o cualquier placa electrónica basada en microcontroladores,



sensores, fuentes de energía, sistema de comunicación inalambricos o GSM y dataloggers

independiente de si son basados en software o hardware. En la entidad “lectura” es donde

se almacenan todas las lecturas identificando el tipo de variable a la que pertenece y la

estación donde fue leída. En la entidad “variable” se definen todas las posibles variables a

ser sensadas y su correspondiente unidad de medida. En la entidad “variable_trama” se

relacionan las variables que pertenecen a un formato de trama específico, cada variable

debe ocupar una posición para facilitar su extracción y almacenamiento. La entidad “trama”

define las características que tendrán la trama o mensajes enviados al middleware, debe

tener un código único e irrepetible y debe también definirse un separador mandatorio

siendo este, el carácter que permitirá la división de las tramas y la extracción de la

información contenida en ella. Por otro lado, se encuentran las entidades “regla” y

“estacion_regla” que permiten definir para esta implementación, reglas básicas para ser

enviadas a los dispositivos actuadores.

Figura 7. Modelo de datos común.

CAPÍTULO IV. MÉTODO DE INVESTIGACIÓN

En esta sección se realiza el planteamiento de la métodogia seguida para resolver la

pregunta de invetigación.

4.1. PREGUNTA DE INVESTIGACIÓN

¿El desarrollo de un middleware en un ambiente de internet de las cosas, puede contribuir

a la reducción del consumo de agua en el sector agrícola?

4.2. DISEÑO DE LA INVESTIGACIÓN

La metodología a seguir para el desarrollo del presente proyecto y dar respuesta a la

hipótesis, obedece al “Modelo Integral para un Profesional en Ingeniería” [54]. Este modelo

constituye una referencia metodológica integral útil para el establecimiento de procesos

adecuados de investigación en las disciplinas ingenieriles.

De acuerdo con este modelo, para abordar un proyecto integral de ingeniería se deben

identificar dos grandes componentes: el Modelo de investigación Documental que facilita

la generación de la base conceptual, encaminado a enriquecer los aportes científicos

partiendo de un hecho abstracto y el Modelo para construcción de soluciones en el proceso

de desarrollo del prototipo experimental.

Los dos componentes se detallan a continuación:

4.2.1. El Modelo de Investigación Documental

Este modelo propone varios lineamientos flexibles que se adaptan a las características de

este proyecto. Este componente está dividido en cuatro fases donde se desarrollan varias

actividades:

4.2.1.1. Fase Preparatoria



En esta fase se identificó de manera clara los conceptos más importantes alrededor de las

temáticas trasversales a este proyecto como lo son middleware para IoT, paradigma ECA

[55][56], motores de Regla, redes inalámbricas de sensores[18][19][57][58], e Internet de

las cosas.

4.2.1.2. Fase Descriptiva

En esta fase se realizó una revisión del estado actual del conocimiento acerca la aplicación

de las tecnologías y técnicas identificadas en la fase anterior; del cual se obtuvo literatura

para realizar una revisión de las diversas herramientas existentes para el diseño,

administración y monitoreo de sensores a través redes inalámbricas y su aporte para el

desarrollo de soluciones IoT, la tabla 4, muestra algunas características encontradas en las

cinco herramientas más relevantes, mientras que en el ítem 4.3 de este capítulo “proyectos

analizados” se describen los tópicos o enfoques a los que están dirigidos.

Tabla 4. Características en las cinco herramientas más relevantes

Autor Título Tema / Objetivo Fortalezas Debilidades

P. Grace, G. S. Blair, and S. Samuel,

“ReMMoC: A Reflective Middleware to Support Mobile Client Interoperability.

Plataforma middleware configurable y dinámicamente reconfigurable que soporta interoperabilidad en entornos móviles heterogéneos.

Computación reflexiva Apoyo a las solicitudes de descubrimiento. Interoperar con servicios heterogéneos en el entorno móvil.

Modelo de programación ReMMoC. Enfocado a móviles. No soporte de sensores de humedad.

WebNMS Framework

WebNMS Framework

Gestión y la Orquestación de Servicios de IoT.

Compatible con gran variedad. Escalabilidad masiva tanto en el cliente y el lado de la red. Apps personalizadas en unas pocas semanas.

Dirigida a personas con alto conocimiento desarrollo de software. No soporte de sensores de humedad.

N. Kefalakis, S. Petris, J. Soldatos, and N. Kefalakis,

Core OpenIoT Middleware Platform

Proporcionar una infraestructura de código abierto para aplicaciones de IoT bajo demanda

Permite la configuración de aplicaciones basadas en utilidad, sobre una infraestructura en la nube para los servicios de Internet de las cosas.

Lenguaje SPARQL Usuarios con conocimiento desarrollo de software. Requiere conocimiento chips electrónicos.

A. Everlet, J. Pastor

Carriots Carriots es una Plataforma como Servicio diseñada para proyectos del Internet de las Cosas (IoT) y de Máquina a Máquina (M2M).

API RESTsobre HTTPS. Flexibilidad de gestionar datos heterogéneos. Configuración remota de dispositivos Eventos tratados con una aproximación tipo if-then-else.

Múltiples opciones. Conocimiento en programación. Conocimiento en Groovy.

Tomas Sabol1, Jan Hreno1

“Hydra: A Development Platform for Integrating Wireless Devices and Sensores into Ambient Intelligence Systems

es una plataforma de IoT de código abierto para desarrollar aplicaciones de IoT para varios dominios, como Smart Cities, Industrie 4.0, Smart Grid.

Estos incluyen administración de datos en vivo y avanzados como la minería de secuencias y el aprendizaje automático en línea.

Alto nivel de complejidad, aun para expertos que no pertenecen a la comunidad de la web semántica.



4.2.1.3. Fase de construcción teórica global

En esta fase se presenta un balance del conjunto de resultados del estudio adelantado y

logros obtenidos durante el desarrollo del proyecto.

4.2.1.4. Fase de extensión y publicación

En esta fase se realiza la divulgación de los resultados obtenidos en el desarrollo del

proyecto mediante la presentación de artículos en eventos o revistas nacionales e

internacionales con relevancia y prestigio, se presentará para su revisión al “SMART

ACCESSIBILITY 2018“, el artículo científico “SAMIoT – Middleware based on IoT for irrigation

planning on large-scale crops.

4.2.2. Modelo para Construcción de Soluciones.

Este modelo propone realizar las siguientes fases: 4.2.2.1. Estudio de Pre-factibilidad

El sector azucarero en el valle del río Cauca, Colombia, decidio realizar un monitoreo del

contenido de humedad presente en el suelo donde se desarrolla la planta a través de la

medición del potencial mátrico, con la intención de determinar con mayor precisión el

momento justo para realizar el riego y hacer más eficiente el uso del agua requerida para la

explotación agrícola. Como resultado de esta investigación se espera impactar de manera

positiva la conservación del medio ambiente y mejorar la rentabilidad en la producción de

caña. De manera que este proyecto busca apoyar al sector azucarero colombiano en la

captura de variables de matriz granular, su correspondiente conversión a potencial mátrico,

disposición de datos a través de websocket y su posterior almacenamiento.

La viabilidad el proyecto está dado por la necesidad y el aporte de recursos y expertos para

apoyar su ejecución, brindada por Cenicaña.

4.2.2.2. Formulación del Proyecto



En esta fase se estudió los aspectos principales relacionados con el desarrollo del proyecto

y la construcción del prototipo, como resultado se definió adoptar dos enfoques de

arquitecturas para el diseño de middlewares, presentados en el capitulo III – Estrategia

propuesta.

4.2.2.3. Ejecución del Proyecto

Esta fase tiene por objeto el desarrollo de la herramienta de software que integra las

tecnologías expuestas fase preparatoria.

4.2.2.4. Validación de la solución

Para realizar la prueba de concepto se definieron tres escenarios:

a) Escenario uno: Consistió en la recolección y procesamiento de tramas provenientes

de una red pluviométrica con sistema de comunicación inalámbrica; esta, se diseñó

a partir de una red existente para el monitoreo de los suelos en un ingenio azucarero

en el Valle del Cauca, esta red fue implementada haciendo un híbrido basado en el

protocolo ZigBee y tecnologías móviles que combinan las mejores características

para formar una red versátil que proporcione adquisición y visualización de datos

obtenidos por sensores y almacenados en dataloggers, como son sistemas móvil

(GPRS HSDPA UMTS), implementadas a través de módulos de radio frecuencia XBee

y módems celulares [43].

En este escenario se parametrizó la red de comunicaciones hibrida para leer datos

de pluviómetros, estos datos son enviados a un módulo XBee PRO asignado a un

arduino por sensor; este, envía de manera transparente la información recibida al

XBee “coordinador” a través de la red Zigbee (DigiMesh) para llegar a un modem

“cliente” SA-G+ de Novatel Wireless Inc. el cual se encuentra a 6 km de distancia en

una localización donde si existe cobertura de una red móvil celular. De aquí los datos

son enviados vía celular hasta el middleware a través del modem “servidor”,



entonces, los datos son procesados siguiendo el flujo descrito en la figura 6 “Flujo

de operación del middleware”.

b) Escenario dos: Si bien el middleware respondio perfectamente a las solicitudes o

peticiones demandadas por la red de pluviómetros, al procesamiento de las tramas

y a la inserción de la información procesada en la base de datos; las lecturas de estos

sensores no proporcionaron información suficiente para validar la capacidad

operacional y la estabilidad del middleware, debido a que solo se contaba con nueve

pluviómetros y los intervalos de envío eran de 15 minutos.

Figura 8. Sistema de Comunicación para una Red de Monitoreo de pluviómetros en el Valle del Cauca.

Lo que obligo a definir otro escenario, que consistió en la creación de un script figura

9 que simula múltiples conexiones concurrentes, en la tabla 5 se muestra el número

de conexiones, los tiempos de ejecución, así como el porcentaje de CPU y Memoria

consumido por el middleware, estos valores son los promedios de cuatro

ejecuciones para cada prueba, es de resaltar que en el momento de la pruebas en el

servidor se encontraban corriendo varios procesos como Apache, PostgresSQL, JAVA

entre otros. En las curvas de la figura 10 observa como al aumentar el número de

conexiones simultaneas, aumenta el porcentaje de consumo de CPU, sin embargo,

el consumo de memoria RAM no se ve afectado en la misma proporción y por el



contrario disminuye a medida que las conexiones aumentan, debido a que estas, van

siendo delegadas del bucle de eventos a los subprocesos internos de CPU, pasando

la carga a los procesadores [42].

Figura 9. Código java script que simula múltiples conexiones concurrentes.

Figura 10. Comportamiento de la CPU vs la memoria RAM, según el número de conexiones simultaneas en el middleware.



Estos resultados permiten evidenciar la confiabilidad y estabilidad tanto en el middleware

como en la robustez de node.js para soportar implementaciones encaminadas a apoyar la

IoT.

Tabla 5. Tabla porcentaje de consumo de CPU y memoria por número de conexiones

Prueba # Conexiones

%CPU %MEM Tiempo

1 100 1 0,7 0:00:19

2 500 2 0,9 0:00:46

3 1000 5 1,3 0:01:30

4 2000 8 1,7 0:01:42

5 5000 11 1,5 0:03:32

6 10000 15 0.2 0:04:16

c) Escenario tres: El sector azucarero colombiano requiere conocer las condiciones de

viento para realizar labores de aerofertilización; para este tipo de labor, es de vital

importancia tener la información en tiempo real de las condiciones de al menos 3

estaciones medidoras del viento para poder elaborar y graficar el campo del viento,

el cual consiste en determinar la velocidad y dirección del viento en cada punto del

túnel [59] y crear una interpolación, para así calcular la dirección y la velocidad que

toma el viento en un punto específico donde no existe una medición figura 11.



Figura 11. Mapa del campo del viento. Fuente Cenicaña, software SINPAVESA.

La figura 12 muestra como la interpolación de varios vectores de viento, hacen que

la velocidad y dirección medida por el sensor en el punto de interés (P1) sea

totalmente diferente a la observada en los sensores de viento en los puntos 2 al 6,

(P2 .. P6), estas diferencias hacen que el cálculo del campo del viento sea de vital

importancia puesto que permite deducir la dirección que tomará el viento y planear

medidas para minimizar el impacto pueda tener la labor sobre alguna población, una

fuente hídrica, zona restringida o un área donde se encuentra un cultivo.

Figura 12. Diferencia de velocidad/dirección del viento un punto de interés y cuatro puntos de medición.



La figura 13 muestra el flujo de una solicitud para generar el campo del viento. Donde el

usuario realiza una consulta (1) pasando los parámetros de la ubicación donde va a

monitorear la velocidad y dirección del viento, así como la labor a realizar; el software

SINPAVESA identifica las 8 estaciones de viento más cercanas al sitio donde se va a realizar

la labor como se observa en la figura 14; estos parámetros se almacenan en una base de

datos (2) para que, en caso de ser requeridos por las corporaciones medio ambientales

colombianas, se pueda recrear la consulta en tiempo, fecha y condiciones de vientos del

momento en que se realizó. El proceso TIMERProcess (3) identifica que existe una regla o

un comando para ser despachado y le pasa al Dispatcher (4) el comando y el dispositivo de

destino al que debe ser enviado. El nodo agrícola inteligente (5) procesa y resuelve la

petición enviada que, para este caso es, consultar las condiciones del viento en los últimos

5 minutos de las ocho estaciones cercanas al sitio de la labor.

Figura 13. Flujo de información para generar mapa campo del viento.

El nodo envía un mensaje con las tramas que contiene la información solicitada, esta es

recibida y procesada por el INTCore (6) una vez identificada la validez de la trama y la calidad

de sus datos, se llama el intérprete específico para que la procesa e inserta los datos de

interés en la base de datos (7) y el software SINPAVESA grafica el campo del viento figura

11.



La figura 14 muestra una instantánea del software SINPAVESA, en la cual se observan las

ocho estaciones de monitoreo de viento mas cercanas al sitio donde se va a realizar la labor,

en ella se puede ver que las estaciones “Florida” y “Cenicaña” que fueron adatadas para

trabajar con el SAMIoT, mejoran en sus tiempos de respuesta alrededor de un 75% mas

rápida que el esquema actual.

Figura 14. Captura de pantalla SINPAVESA. Fuente CENICAÑA

Sin embargo, el mayor logro se describe en el capítulo V, donde se presenta los resultados

de una solución que demuestra el uso del middleware en la planificación de riegos en

cultivos de grandes extensiones de tierra sembradas con caña de azúcar, satisfaciendo el

principal objetivo de esta investigacion.

4.3. PROYECTOS ANALIZADOS

Para la realización de la investigación y la comprobación de los resultados, se revisaron los

sigueintes proyectos: ReMMoC [60], OpenIoT [61], WebNMS Framework [62] Herramientas

que contribuyen a la implementación de soluciones IoT; la mayoría de estos se enfocan en

dar soluciones a dispositivos móviles y a sensores de uso general, donde los tópicos que se

cubren están dirigidos a los hogares y a las áreas urbanas dejando de lado las restricciones

o limitaciones del entorno agrícola; algunos se han centrado en cómo dotar aplicaciones



móviles con la interoperabilidad, reconfiguración y adaptación a los cambios del entorno

[63], otros presenta una arquitectura para el despliegue de servicios en un ambiente de

semántica generalizada [64] como HYDRA (LinkSmart) [65] que permite crear aplicaciones

de inteligencia ambiental (AmI), a través de su combinación única de arquitectura orientada

a servicios (SoA) y una arquitectura basada en modelos semánticos.

En este mismo sentido, se presenta ReM-MoC [60], una plataforma de middleware reflexivo

que adapta dinámicamente su enlace y protocolo para permitir la interoperabilidad con

servicios heterogéneos. Además, proponen el modelo de programación ReMMoC, que se

basa en el concepto de Web Services de servicios abstractos para dar apoyo a desarrollo de

aplicaciones móviles a través de una plataforma de middleware. Pero la necesidad de

permitir que los usuarios tomen el control de la IoT, incrementa la importancia del

middleware, puesto que permite simplificar el desarrollo de nuevos servicios y tecnologías

y la integración con las ya existentes. De ahí la importancia de proyectos como OpenIoT [66]

cofinanciado por la unión europea FP7-287305 y cuyo objetivo principal es investigación y

desarrollo de una plataforma middleware que permite la configuración de aplicaciones

basadas en utilidad, así como servicios de detección basados en la nube, permitiendo

desplegar o proveer servicios en entornos cloud.

Plataformas con WebNMS [62] busca ayudar a las empresas a alcanzar sus objetivos IoT /

M2M, de manera que puedan tomar decisiones oportunamente u optimizar sus procesos

con sus innumerables posibilidades de aplicación como la administración de nivel de

servicio, aprovisionamiento y topología, y que además requieran alta capacidad de

personalización y extensibilidad entre dominios, no obstante, el uso de esta herramienta

está dirigida a personas con alto conocimiento desarrollo de software.

En cuanto a la agricultura, no se encontraron estudios relevantes que evidenciaran el

desarrollo de middlewares para soportar un gran número de sensores propios para la

agricultura; en su trabajo [63], busca la digitalización de cada proceso en todos los aspectos

de la agricultura incluyendo producción agrícola, ganadería, industria de productos



acuáticos y silvicultura a través de la Tecnología de la Información, la conectividad a internet

y la aplicación de IoT.

También, en el campo de la agricultura es muy común encontrar en la literatura gran

cantidad de aplicaciones dedicadas a la monitorización del entorno en diversas disciplinas,

como por ejemplo, control de establos ganaderos [67], la agricultura de precisión [68],

siendo esta la tecnología la que más se acerca a la aplicación de IoT en la agricultura.

Por otro lado CarrIoTs [69] presenta una plataforma en la nube como servicio diseñada para

proyectos IoT, soporta especialmente comunicaciones M2M y se centra en la escalabilidad

inmediata a nivel de red. CarrIoTs no garantiza la seguridad del almacenamiento y ofrece

un soporte limitado para la interoperabilidad [70].

CAPÍTULO V – RESULTADOS Y ANÁLISIS

La solución propuesta para demostrar el uso del middleware en la planificación de riegos

en cultivos de grandes extensiones de tierra sembradas con caña de azúcar se basa, en un

sistema capaz de procesar peticiones y tramas correspondientes a mediciones de las

condiciones del agua en el suelo donde se encuentran el cultivo. Una de estas condiciones

es la energía con la que las partículas o matriz del suelo retienen el agua, esta propiedad es

conocida como potencial matricial del suelo (PMS)[42]. Este potencial, se ha considerado

particularmente en algunas áreas como el mejor criterio para la caracterización de la

disponibilidad de agua en el suelo, respecto a los contenidos volumétricos o gravimétricos

[71].

Si bien existen varias metodologías [72] que buscan alcanzar las mejores eficiencias en el

uso del agua de riego sin afectar los rendimientos; el monitoreo del estado hídrico o

potencial mátrico del suelo en tiempo real es el que presenta el mayor acierto como

herramienta para la programación del riego [73], debido a que indica la cantidad total de

agua disponible para ser absorbida por la planta.

En este escenario, se evalúa el comportamiento del agua en el suelo, en un cultivo

sembrado con caña de azúcar en un terreno a 1200 metros sobre el nivel del mar, con un

tipo de suelo franco limoso con la ubicación geográfica definida por latitud 3.4281 y longitud

–76.3071.

Las tramas con la información capturada son enviadas a través de una red híbrida

implementada, donde se combinó la topología DigiMesh (Red ZigBee) con una red punto a

punto (Red Móvil Celular) figura 15.



Figura 15. Red híbrida implementada en el sitio de monitoreo. Fuente [43]

En la figura 15 se muestra la unión de dos topologías y su punto de convergencia como

sigue:

… Esta topología proporciona la opción de conectar todos los nodos como una red en malla. La segunda

topología, resaltada en azul, sigue un modelo de cliente / servidor, donde el módem de cliente se conecta en

serie a uno de los módulos XBee® y el módem de servidor al terminal de computadora remota, ubicado en este

caso en CENICAÑA. Sin embargo, para que el módem de servidor tenga comunicación con el cliente, debe estar

ubicado en un área, en este caso en Colombia, que tiene cobertura de un proveedor de servicios de telefonía

móvil.

Para configurar la red, los tres dispositivos (módulos XBee®, dataloggers y módems) deben configurarse para

que todos tengan un lenguaje común y funcionen como uno. La interfaz en serie permite la interconexión de

dispositivos. En otras palabras, los módulos XBee®, que se ensamblan en tarjetas de serie y proporcionan una

interfaz serie al módulo, conéctelo a los registradores de datos y al módem a través de su puerto serie RS 232

[43].

La tabla 6, presenta el agrupamiento de los sensores de matriz granular y su respectiva

profundidad en la que fueron instalados para esta implementación.

La figura 16 muestra el comportamiento del potencial mátrico por cada sensor de matriz

granular pertenecientes a un Nodo Agrícola Inteligente, este nodo recibe datos de seis

sensores instalados en la zona radicular de la caña separado en dos grupos P1 y P2, a una

profundidad de 30 cm y 45 cm de la superficie del suelo respectivamente, en una zona

representativa de las características físicas del suelo donde se encuentra la mayor parte de

raíces de las plantas, los datos de cada grupo son enviados al middleware con un formato

trama tipo 166 tabla 2 a intervalos de 15 minutos, el intérprete promedia los valores de los

grupos de variables, según la definición de la trama aplica a cada lectura de cada sensor la

ecuación de calibración (1) para el cálculo del potencial mátrico [74]; esta describen las



relaciones entre la resistencia en kilo ohmios (�Ω) de los sensores y el potencial hídrico del

suelo en kilopascales (kPa). A continuación, se describe las variables que ayudan al cálculo

del potencial mátrico:

�� =�,��(�.��∗�)

��(.��∗�)�(.��∗�) Ecuación 1

Donde PM es el potencial de la mátrico del suelo en kPa, R es la lectura del sensor en �Ω, y

T es la temperatura estimada o medida del suelo en °C.

Los valores de potencial mátrico resultantes de la aplicación de la ecuación de calibración,

permite definir principalmente dos niveles de interés para programar labores de riegos

donde, valores inferiores a -80 kPa se considera que el suelo presenta déficit de agua

(humedad) y la posibilidad de que el cultivo sufra de estrés hídrico, por el contrario, valores

por encima de 0 KPa, se considera que el suelo presenta exceso de agua (humedad), figura

17.

Tabla 6. Profundidad y agrupación de sensores de matriz granular.

Sensor MG Grupo Profundidad

1, 2, 3 P1 30 cms

4, 5, 6 P2 45 cms

Es decir que a medida que aumenta la tensión, la disponibilidad de agua es más baja, en

contraposición en la medida que la tensión disminuye la disponibilidad de agua es más alta,

entendiéndose este como "cambio de potencial hídrico del suelo". El agua disponible se

encuentra entre ± -20 kPa y ± -80 kPa; según criterios establecidos en Cenicaña mediante

la experimentación con lisímetros pesaje o contenedores de suelos descritos en [75].

Basado en estos ± máximos y mínimos podrá implementarse en el intérprete del

middleware el envío de notificaciones push o emails para informar al agricultor encargado

de ejecutar la labor de riego.



Las zonas de despliegue de los sensores presentan aproximadamente una variabilidad de 8

°C en la temperatura del suelo; de manera que los rangos entre ± -20 y ± -80 kPa , son los

que permiten compensar esa diferencia de temperatura [74] en el rango de 17 y 25 °C.

Figura 16. Curvas de potencial mátrico para cada sensor de matriz granular.

Figura 17. Curvas de potencial matricial un período de tiempo .

La figura 17 muestra curvas de potencial mátrico promediado, donde se observa cómo el

26/06/2017, justo antes del riego programado para el 11/07/2017 se produjo un evento de

precipitación fuerte según datos pluviométricos de la estación meteorológica de Cenicaña,

provocando un aumento del contenido de humedad del suelo, cuando el potencial mátrico

del promedio de los sensores instalados a 45 cm era de -53 kPa y de -24 kPa para los

sensores instalados a 30 cm de profundidad, situación que no permitió observar el cambio



de la humedad del suelo y posteriormente ver el comportamiento del periodo normal de

drenaje.

El día 08/08/2017 el evento de riego comenzó en el momento “indicado” cuando el

contenido de agua del suelo alcanzó un límite cercano al déficit. Mientras que el evento de

riego programado para el día 11/09/2017, inicia cuando el contenido volumétrico de agua

del suelo se encontraba en condiciones de déficit observándose el periodo de drenaje antes

del riego y el posterior periodo de recarga después del riego.

También esta gráfica permite visualizar a través de la curva que corresponde a las

mediciones de sensores instalados a 30 cm de profundidad, como el descenso en la

humedad de agua es más rápida en la superficie del suelo debido al calor que ejerce la

temperatura ambiente.

En general, el contenido volumétrico de agua del suelo se encuentra muy cercano a los

límites establecidos, manteniendo el agua y los nutrientes dentro de la zona en que las

raíces realizan su mayor absorción, es decir, que los valores se mantuvieron cercanos a la

capacidad de campo, permitiendo observar los periodos de recarga y drenaje del agua en

el suelo. Además, con la información del contenido del agua de suelo en el cual se desarrolla

la planta, la persona encargada de programar el riego puede tomar decisiones de ejecutar

la labor sólo cuando el contenido de humedad del suelo se encuentre en un nivel adecuado

(-cuándo-), así como la decisión de cuándo parar (-cuánto-) el evento de riego.

CAPITULO VI – CONCLUSIONES Y TRABAJOS

FUTUROS

En esta investigación se presentó el diseño e implementación un middleware capaz de

ayudar a la planificación de riegos en Cultivos de Grandes Extensiones de Tierra en un

ambiente IoT, a través del protocolo TCP.

El middleware está compuesto por cuatro módulos principales: El Núcleo, que permite

asociar componentes de hardware, software, sistemas y plataformas para establecer una

comunicación de máquina a máquina; por lo general se centra en garantizar la

comunicación de los protocolos y proveer la infraestructura necesaria para que los

protocolos puedan operar. El DAOCore que independiza la lógica del middleware (negocio)

de la responsabilidad de persistencia reduce la complejidad de la lógica de las

transacciones. El INTCore que gestiona los intérpretes que se encargan de analizar los

diferentes formatos de mensajes (tramas) recibidos desde los clientes y definidas en la base

de datos y el Monitor que se encarga de enviar los comandos definidos por los usuarios o

aplicaciones hacia los Nodos Agrícolas Inteligentes, proporcionando un canal bidireccional

de comunicaciones en tiempo real para aplicaciones y servicios web avanzados y expone

los sucesos que se están dando dentro del núcleo.

Se implementó en una solución real para apoyar la captura de variables de sensores de

matriz granular, procesarlas y transformarlas a potencial mátrico y observar los periodos de

recarga y drenaje del agua en el suelo; ayudando a la toma de decisiones de cuanto y cuanto

regar. Además, existen siete haciendas esperando se realice la implementación del sistema

de monitoreo de potencial mátrico, sumando entre todas más de 84 hectáreas sembradas

con caña.

Es de resaltar que la solución permite satisfacer la necesidad que tiene el sector azucarero

de optimizar el uso del agua, reducir costos y disminuir el riesgo del impacto ambiental



sobre los caudales de agua y sobre las aguas subterráneas, debido a que este notifica a las

personas encargadas de programar la labor de riego justo cuando la planta lo necesite, es

decir la solución responde a la incertidumbre de cuándo y cuánto regar.

Por otro lado, los coeficientes en cada ecuación son específicos del suelo, para una medición

óptima, se debe realizar la calibración del sensor para cada tipo de suelo donde se tomará

la medición.

Aunque el middleware lo soporta, no se logró contar con un escenario de apertura y cierre

automática de compuertas.

En trabajos futuros se propone generar un intérprete de manera automática justo cuando

se defina un tipo de trama con sus características, además se espera que el middleware

permita gestionar una red de monitoreo del potencial mátrico del suelo en el Valle del río

Cauca, con la cual aparte de generar una alternativa a la determinación del momento

oportuno de aplicación de riego tradicional, se espera poder adquirir un conocimiento

amplio sobre el comportamiento del potencial mátrico diferentes tipos de suelo y

microclimas, para relacionarlo con el nivel menos limitante de agua para las diferentes

cultivos, así como apoyo a modelos de riego ampliamente aceptados como el balance

Hídrico.

CAPÍTULO VII – BIBLIOGRAFÍA

[1] T. Liu, Y. W. Guan, Y. Q. Yan, L. Liu, and Q. C. Deng, “A WSN-Oriented Key Agreement

Protocol in Internet of Things,” Appl. Mech. Mater., vol. 401–403, pp. 1792–1795,

2013.

[2] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A survey,” Comput.

Networks, vol. 54, no. 15, pp. 2787–2805, 2010.

[3] T. A. Howell and M. Meron, “Microirrigation for Crop Production - Design, Operation,

and Management,” Dev. Agric. Eng., vol. 13, no. 2, pp. 61–130, 2007.

[4] J. R. Cruz and T. S. Jorge, “El cenirrómetro. Segunda ed. Serie Divulgativa No. 3. Cali.

CENICAÑA. 4 p,” 1995.

[5] J. Torres, J. Cruz, and F. Villegas, “Avances técnicos para la programación y el manejo

del riego en caña de azúcar. Segunda ed. Serie técnica No. 33. Cali. CENICAÑA. 66 p,”

Ser. Técnica, no. 33, p. 2004, 2004.

[6] E. Hincapié Gómez, “Estudio y modelación del movimiento del agua en suelos

volcánicos de ladera Estudio y modelación del movimiento del agua en suelos

volcánicos de ladera,” pp. 63–111, 2011.

[7] L. Zotarelli, M. D. Dukes, and K. T. Morgan, “Interpretación del contenido de la

humedad del suelo para determinar capacidad de campo y evitar riego excesivo en

suelos arenosos utilizando sensores de,” pp. 2–5, 2013.

[8] A. C. McCarthy, N. H. Hancock, and S. R. Raine, “Development and simulation of

sensor-based irrigation control strategies for cotton using the VARIwise simulation

framework,” Comput. Electron. Agric., vol. 101, pp. 148–162, 2014.

[9] R. Nolz, G. Kammerer, and P. Cepuder, “Calibrating soil water potential sensors

integrated into a wireless monitoring network,” Agric. Water Manag., vol. 116, pp.

12–20, 2013.

[10] S. R. Evett, R. C. Schwartz, J. J. Casanova, and L. K. Heng, “Soil water sensing for water

balance, ET and WUE,” Agric. Water Manag., vol. 104, pp. 1–9, 2012.

[11] T. Ojha, S. Misra, and N. S. Raghuwanshi, “Sensing-cloud: Leveraging the benefits for

agricultural applications,” Comput. Electron. Agric., vol. 135, pp. 96–107, 2017.

[12] R. Morais, M. A. Fernandes, S. G. Matos, C. Serôdio, P. J. S. G. Ferreira, and M. J. C. S.

Reis, “A ZigBee multi-powered wireless acquisition device for remote sensing

applications in precision viticulture,” Comput. Electron. Agric., vol. 62, no. 2, pp. 94–

106, 2008.

[13] J. A. López Riquelme, F. Soto, J. Suardíaz, P. Sánchez, A. Iborra, and J. A. Vera,

“Wireless Sensor Networks for precision horticulture in Southern Spain,” Comput.

Electron. Agric., vol. 68, no. 1, pp. 25–35, 2009.

[14] H. Navarro-Hellín, R. Torres-Sánchez, F. Soto-Valles, C. Albaladejo-Pérez, J. A. López-

Riquelme, and R. Domingo-Miguel, “A wireless sensors architecture for efficient

irrigation water management,” Agricultural Water Management, vol. 151. pp. 64–

74, 2015.

[15] E. Asfaw, K. V Suryabhagavan, and M. Argaw, “Soil salinity modeling and mapping

using remote sensing and GIS: The case of Wonji sugar cane irrigation farm, Ethiopia,”

J. Saudi Soc. Agric. Sci., p. , 2016.

[16] A. Ojamaa and K. Duuna, “Assessing the security of Node.js platform,” 7th Int. Conf.

Internet Technol. Secur. Trans., pp. 348–355, 2012.

[17] J. A. López-Riquelme, N. Pavón-Pulido, H. Navarro-Hellín, F. Soto-Valles, and R.

Torres-Sánchez, “A software architecture based on FIWARE cloud for Precision

Agriculture,” Agric. Water Manag., vol. 183, pp. 123–135, 2016.

[18] J. Haule, “Deployment of Wireless Sensor Networks ( WSN ) in Automated Irrigation

Management and Scheduling Systems : a review,” pp. 86–91, 2014.

[19] W. Chebbi, M. Benjemaa, a. Kamoun, M. Jabloun, and a. Sahli, “Development of a

WSN integrated weather station node for an irrigation alert program under Tunisian

conditions,” Int. Multi-Conference Syst. Signals Devices, SSD’11 - Summ. Proc., no.

figure 1, pp. 1–6, 2011.

[20] S. Roy, “Evolution of Middleware Technology and Its Widespread Applications.”

[21] T. Bishop and R. Karne, “A survey of middleware,” Proc. ISCA 18th Int. Conf. Comput.

Their Appl. Honolulu, Hawaii, USA, March 26-28, 2003, pp. 254–258, 2003.

[22] “What Is Middleware?” [Online]. Available:

http://web.archive.org/web/20120629211518/http://www.middleware.org/whatis

.html. [Accessed: 02-Aug-2015].

[23] A. Kevin, “That ‘Internet of Things’ Thing - RFID Journal.” [Online]. Available:

http://www.rfidjournal.com/articles/view?4986. [Accessed: 09-Jul-2015].

[24] B. N. Gershenfeld, “The Internet of Things.”

[25] D. Miorandi, S. Sicari, F. De Pellegrini, and I. Chlamtac, “Internet of things: Vision,

applications and research challenges,” Ad Hoc Networks, vol. 10, no. 7, pp. 1497–

1516, 2012.

[26] A. Whitmore, A. Agarwal, and L. Da Xu, “The Internet of Things-A survey of topics and

trends,” Inf. Syst. Front., no. March 2014, pp. 1–14, 2014.

[27] K. Finkenzeller, Fundamentals and applications in contactless smart cards, radio

frequency identification and near-field communication, Third edit. 2003.

[28] C. C. Shock, J. M. Barnum, and M. Seddigh, “Calibration of Watermark Soil Moisture

Sensors for Irrigation Management,” Int. Irrig. Show, no. February, pp. 139–146,

1998.

[29] a Bertolino, A. Souza, and N. Fernandes, “Comparison of the soil matrix potential

using tensiometers and Watermark sensors,” Irrometer.Com, vol. 1759, no. 1, pp. 13–

16, 1996.

[30] J. Y. Jung, J. Park, S. K. Han, and K. Lee, “An ECA-based framework for decentralized

coordination of ubiquitous web services,” Inf. Softw. Technol., vol. 49, no. 11–12, pp.

1141–1161, 2007.

[31] P. R. Pietzuch, B. Shand, and J. Bacon, “A Framework for Event Composition in

Distributed Systems,” Office, vol. 2672, pp. 62–82, 2003.

[32] Y. Zhang, L. Duan, and J. L. Chen, “Event-Driven SOA for IoT Services,” 2014 IEEE Int.

Conf. Serv. Comput., pp. 629–636, 2014.

[33] A. B. S. Saman, P. Sebastian, N. A. Malek, and N. Z. M. Hasidin, “Implementation of

autonomous vehicle navigation algorithms using event-driven programming,” ICIAS

2012 - 2012 4th Int. Conf. Intell. Adv. Syst. A Conf. World Eng. Sci. Technol. Congr. -

Conf. Proc., vol. 1, no. 1, pp. 12–17, 2012.

[34] D. Locke, “MQ Telemetry Transport (MQTT) V3.1 Protocol Specification,” p. 42, 2010.

[35] O. Message, Q. Telemetry, and T. Mqtt, “MQTT Version 3.1.1,” no. October, 2014.

[36] J. Alferes, F. Banti, and a Brogi, “An event-condition-action logic programming

language,” Logics Artif. Intell., pp. 29–42, 2006.

[37] W. May, J. J. Alferes, and R. Amador, “Active rules in the semantic web: Dealing with

language heterogeneity,” Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif.

Intell. Lect. Notes Bioinformatics), vol. 3791 LNCS, pp. 30–44, 2005.

[38] S. Costantini and A. Tocchio, “The DALI Logic Programming Agent-Oriented

Language,” Society, pp. 685–688, 2004.

[39] T. Bosák, “Node . js Based Remote Control of Thermo-optical Plant,” no. February,

pp. 206–210, 2015.

[40] S. Tilkov and S. Vinoski, “Node.js: Using JavaScript to build high-performance network

programs,” IEEE Internet Comput., vol. 14, no. 6, pp. 80–83, 2010.

[41] S. Farah, A. Benachenhou, G. Neveux, D. Barataud, G. Andrieu, and T. Fredon,

“Flexible and real-time remote laboratory architecture based on Node.js server,” Exp.

Int. Conf., 2015.

[42] B. Tomáš and K. Žáková, “Node.js based remote control of thermo-optical plant,”

12th Int. Conf. Int. Remote Eng. Virtual Instrum., 2015.

[43] M. Eugenia, D. Mosquera, V. Cauca, and V. Cauca, “Communications System for a Soil

Monitoring Network in Valle del Cauca , Colombia,” Eng. Appl. - Int. Congr. Eng.

(WEA), 2015 Work., no. 1, pp. 1–5.

[44] A. Kumar, K. Kamal, M. O. Arshad, S. Mathavan, and T. Vadamala, “Smart irrigation

using low-cost moisture sensors and XBee-based communication,” Proc. 4th IEEE

Glob. Humanit. Technol. Conf. GHTC 2014, pp. 333–337, 2014.

[45] U. B. y B. D., “«Modems,» de Redes de transmisión de datos y proceso distribuido,”

in Prentice Hall, p. 60.

[46] M. A. Razzaque, M. Milojevic-Jevric, A. Palade, and S. Cla, “Middleware for internet

of things: A survey,” IEEE Internet Things J., vol. 3, no. 1, pp. 70–95, 2016.

[47] M. Elkhodr, S. Shahrestani, and H. Cheung, “A Middleware for the Internet of Things,”

Int. J. Comput. Networks Commun., vol. 8, no. 2, pp. 159–178, 2016.

[48] M. Mamei and F. Zambonelli, “Field-based coordination for pervasive multiagent

systems.” 2006.

[49] T. Di Noia, M. Mongiello, F. Nocera, and E. Di Sciascio, “Ontology-based reflective Iot

middleware-enabled agriculture decision support system,” pp. 1–2.

[50] H. Van Der Veer and A. Wiles, “Achieving Technical Interoperability: the ETSI

Approach,” Eur. Telecommun. Stand. Inst., no. 3, p. 29, 2008.

[51] S. M. Bellovin, “A Look Back at ‘Security Problems in the TCP/IP Protocol Suite,’” 20th

Annu. Comput. Secur. Appl. Conf., pp. 229–249, 2004.

[52] O.-B. Choi, S.-M. , Yoo, C.-J. , Chang, “Development of Integrated DAO Pattern

Applying Iterator Pattern,” in Computational Science and Its Applications - ICCSA

2006, 2006.

[53] J.-P. Erkkilä, “WebSocket Security Analysis,” 2012.

[54] C. Serrano, “Un Modelo Integral para un Profesional en Ingeniería,” Univ. del Cauca,

2003.

[55] E. E. Almeida, J. E. Luntz, and D. M. Tilbury, “Event-Condition-Action Systems for

Reconfigurable Logic Control,” IEEE Trans. Autom. Sci. Eng., vol. 4, no. 2, pp. 167–

181, 2007.

[56] N. W. Paton and O. Díaz, “Active database systems,” ACM Comput. Surv., vol. 31, no.

1, pp. 63–103, 1999.

[57] M. T. Lazarescu, “Design of a WSN platform for long-term environmental monitoring

for IoT applications,” IEEE J. Emerg. Sel. Top. Circuits Syst., vol. 3, no. 1, pp. 45–54,

2013.

[58] A. Azzara, S. Bocchino, P. Pagano, G. Pellerano, and M. Petracca, “Middleware

solutions in WSN: The IoT oriented approach in the ICSI project,” 2013 21st Int. Conf.

Software, Telecommun. Comput. Networks, SoftCOM 2013, 2013.

[59] G. Sanjuan, T. Margalef, and A. Cort??s, “Hybrid application to accelerate wind field

calculation,” J. Comput. Sci., vol. 17, pp. 576–590, 2015.

[60] P. Grace, G. S. Blair, and S. Samuel, “ReMMoC: A Reflective Middleware to Support

Mobile Client Interoperability,” pp. 1–18, 2003.

[61] N. Kefalakis, S. Petris, J. Soldatos, and N. Kefalakis, “OpenIoT - Open source blueprint

for large scale self-organizing cloud environments for IoT applications,” 2013.

[62] W. Framework, “WebNMS Framework - Build Element Management System /

Network Management System (EMS / NMS) Quickly - Element Management System

| EMS | NMS | Network Management Systems | EMS Framework | EMS Platform.”

[Online]. Available: https://www.webnms.com/webnms/. [Accessed: 04-Jul-2015].

[63] D. Yan-E, “Design of intelligent agriculture management information system based

on IoT,” Proc. - 4th Int. Conf. Intell. Comput. Technol. Autom. ICICTA 2011, vol. 1, pp.

1045–1049, 2011.

[64] W. Zhang and K. M. Hansen, “Semantic web based self-management for a pervasive

service middleware,” Proc. - 2nd IEEE Int. Conf. Self-Adaptive Self-Organizing Syst.

SASO 2008, pp. 245–254, 2008.

[65] M. Eisenhauer, P. Rosengren, and P. Antolin, “Hydra: A Development Platform for

Integrating Wireless Devices and Sensors into Ambient Intelligence Systems. In:

Giusto D., Iera A., Morabito G., Atzori L. (eds) The Internet of Things. Springer, New

York, N,” pp. 367–373, 2010.

[66] P. C. Reference, S. Priority, G. A. Number, and P. Type, “OpenIoT - Open Source

blueprint for large scale self - organizing cloud environments for IoT applications,” p.

2011, 2011.

[67] J. Lee, “Design And Implementation of middleware for Cattle barn based on

Ubiquitous Sensor network,” 2010.

[68] C. Albaladejo, J. A. L. Riquelme, F. Soto, P. Sánchez, and A. Iborra, “Plataforma de

monitorización para una red de sensores en agricultura deprecisión.” 2018.

[69] A. E. J. Pastor, “Carriots,” Introd. al Internet las Cosas, 2015.

[70] S. Sathyadevan, B. S. Kalarickal, and M. K. Jinesh, “Security, trust and implementation

limitations of prominent IoT platforms,” Adv. Intell. Syst. Comput., vol. 328, pp. 85–

95, 2015.

[71] D. Wang, Y. Kang, and S. Wan, “Effect of soil matric potential on tomato yield and

water use under drip irrigation condition,” Agric. Water Manag., vol. 87, no. 2, pp.

180–186, 2007.

[72] N. Castilla and T. Montalvo, Programación del riego. In_ Fertirrigación, cultivos

hortícolas, frutales y ornamentales, 3a. Madrid: Ediciones Mundi-Prensa, 2005.

[73] A. Fares and A. K. Alva, “Evaluation of capacitance probes for optimal irrigation of

citrus through soil moisture monitoring in an entisol profile,” Irrig. Sci., vol. 19, no. 2,

pp. 57–64, 2000.

[74] E. P. Eldredge, C. C. Shock, and T. D. Stieber, “Calibration of granular matrix sensors

for irrigation management,” Agron. J., vol. 85, no. 6, pp. 1228–1232, 1993.

[75] U. Federal Do Recôncavo, D. Bahia, C. Das Almas, C. Daniel, S. Schmidt, F. Adriano De

Carvalho Pereira, A. Silva De Oliveira, J. Fonseca, G. Júnior, and L. M. Vellame,

“Design, installation and calibration of a weighing lysimeter for crop

evapotranspiration studies,” vol. 2, no. 2, pp. 77–85, 2013.

Un middleware para la gestión labores agrícolas en un ...

Documents

Transcript of Un middleware para la gestión labores agrícolas en un ...