Implementaci´
on de Software para
Plataforma Integral de Gesti´
on de
Sistemas de Riego
David Antonio Millan Orduz
Danny Fabian Mora Pe˜
na
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenier´ıa, Ingenier´ıa electr´onica
Bogot´a, Colombia
Plataforma Integral de Gesti´
on de
Sistemas de Riego
David Antonio Millan Orduz
Danny Fabian Mora Pe˜
na
Trabajo de grado en la modalidad INVESTIGACI ´ON INNOVACI ´ON para optar al titulo de:
Ingeniero Electr´onico
Director:
(Ing.) Julian Rolando Camargo Lopez
Grupo de Investigaci´on:
L.A.S.E.R. (Laboratorio De Automatizacion Sistemas Embebidos y Robotica)
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenier´ıa
Bogot´a, Colombia
Tu trabajo va a llenar gran parte de tu vida, y
la ´unica forma de estar realmente satisfecho con
´el es hacer lo que creas que es un gran trabajo.
Y la ´unica manera de hacer un trabajo genial
es amar lo que haces. Si no lo has encontrado,
sigue buscando. No te detengas. Al igual que
con todos los asuntos del coraz´on, lo sabr´as
cuando lo encuentres. Y, como cualquier gran
relaci´on, s´olo se pondr´a mejor y mejor, conforme
los a˜nos pasen. As´ı que sigue buscando hasta
que lo encuentres. No te detengas..
El presente trabajo esta dedicado a todos los que hicieron posible que estuvi´eramos aqu´ı y permitir que se realizara el proyecto.
Por ello agradecemos a nuestro director el profesor Julian Camargo, por su apoyo en la realizaci´on de este proyecto, de igual manera que al profesor Cesar Perdomo director del proyecto el cual nos brindo todas las herramientas necesarias para poner en funcionamiento la plataforma, al C.I.D.C (Centro de Investigaci´on y Desarrollo Cient´ıfico de la Universidad Distrital Francisco Jos´e de Caldas ) por la financiaci´on del proyecto.
v
Resumen
Como resultado de una b´usqueda detallada de software para la administraci´on, gesti´on y control de cualquier tipo de cultivo o jardiner´ıa, el cual brinde herramientas para mejorar la producci´on, costos y el impacto ambiental que se produce normalmente. Se encuentra una nueva oportunidad del desarrollo de un software que cumpla con todas estas necesidades. En la actualidad existe software que realiza funciones aisladas, con costos considerables para agricultores y que no est´an al alcance en Colombia, por otra parte, estos sistemas no cuen-tan con un control centralizado que permita generar reportes y estad´ısticas para los diversos actores que intervienen en la agricultura.
Con las razones nombradas anteriormente se muestra a continuaci´on el desarrollo de un software denominado Plataforma Integral de Gesti´on de Sistemas de Riego el cual ha sido presentado y aprobado ante el C.I.D.C, la plataforma o software se desarroll´o con el fin de: controlar, generar reportes y estad´ısticas, con una interfaz sencilla, de f´acil manejo y que tenga acceso a diferentes tipos de usuarios.
Palabras clave: software, automatizaci´on, cultivos, riego, Android, Bluetooth,
Abstract
As a result of a detailed search of software for the administration, management and control of any crop or gardening, which provides tools to improve production, costs and environ-mental impact normally occurs. It is a new opportunity for the development of software that meets all these needs. There is now software that isolated functions, with significant costs for farmers and that are not available in Colombia, on the other hand these systems do not have a centralized control that can generate reports and statistics for the various actors involved in agriculture .
With the reasons listed above is shown below the development of a software called underline Integral Management Platform Irrigation Systems which has been submitted and approved before the CIDC, platform or software development in order to: control , generate reports and statistics, with a simple interface, easy to use and have access to different types of users. Keywords: software, automation, crops, irrigation, Android, Bluetooth, JavaScript,
Contenido ix
4.6.6 Rutas de Ejecutivos . . . 43
4.7 Configuraci´on del servidor . . . 44
4.7.1 Certificados de seguridad . . . 44
5 Integraci´on de la plataforma 45 5.1 AngularJS [9] . . . 45
7 An´alisis de resultados 71 7.1 Pruebas del servidor . . . 71
7.1.1 Comportamiento de servidor . . . 72
7.1.3 Consumo de recursos computacionales . . . 73
7.2 Interfaz de usuario . . . 75
7.2.1 Virtudes . . . 76
7.2.2 Aspectos por mejorar . . . 76
8 Conclusiones y Trabajos futuros 77 8.1 Conclusiones . . . 77
8.2 Trabajos futuros . . . 79
1 Introducci´
on
Los sistemas de riego son principalmente un conjunto de estructuras, que hacen posible que se cultive un terreno con la aplicaci´on de agua necesaria a las plantas. Dichos sistemas de riego se utilizan desde ya hace varios a˜nos y han ca´ıdo en desuso, esto debido a la escasez del recurso h´ıdrico, al uso de tecnolog´ıas obsoletas, sumado a esto los cambios clim´aticos que producen los gases de efecto invernadero no son tenidos en cuenta en los antiguos sistemas de riego, generando problemas en ´epocas de sequ´ıas o ´epocas lluviosas.
En este documento se muestra el desarrollo de una plataforma la cual integra tanto aplica-ci´on m´ovil como aplicaci´on web, cuyo principal objetivo es el control de un dispositivo que realiza las tareas de riego y recolecci´on de datos v´ıa Bluetooth.
La aplicaci´on m´ovil y web tienen las mismas funciones las cuales se describen a continuaci´on:
Gesti´on de Usuarios:Se manejan distintos roles y permisos dentro de la plataforma, con el fin de brindar seguridad a los datos el control de los dispositivos, existen tres tipos de usuarios:
• Administrador: Tiene permisos de realizar todas las actividades, tales como adi-cionar o eliminar dispositivos, adiadi-cionar o eliminar usuarios y crear nuevas rutinas
• Usuario Ordinario: Tiene permisos de ver datos de los sensores, crear y modificar rutinas de riego y recolecci´on de datos.
• Invitado: este tipo de usuario solo tiene acceso a los datos, podr´a solamente
Gesti´on de Comunicaciones:La aplicaci´on se conecta al dispositivo v´ıa Bluetooth. cuenta con la opci´on de configurar los tiempos de la comunicaci´on.
Gesti´on de Actuadores:En esta opci´on se podr´an: etiquetar, agrupar y eliminar los actuadores esto con la restricci´on del tipo de usuario que lo realice . De tal forma que se puedan realizar la programaci´on.
Gesti´on del registro de actividades:Esta opci´on guarda las modificaciones reali-zadas por cada usuario, las cuales pueden ser supervisadas por el administrador.
Gesti´on de Mediciones Calculadas: Con los datos de los sensores y actuadores se calculan a trav´es de operaciones b´asicas datos de inter´es.
2 Objetivos
2.1.
Objetivo General
Dise˜nar e implementar una plataforma con software libre para la administraci´on y control de una Plataforma Integral de Gesti´on de Sistemas de Riego.
2.2.
Objetivos Espec´ıficos
Determinar los tipos de datos que ser´an variables de entrada y salida de la plataforma, as´ı como el tipo de usuarios que pueden acceder a la misma, para realizar el dise˜no de na base de datos.
Dise˜nar una plataforma de gesti´on y administraci´on de datos que permita el monitoreo de variables de un cultivo y la activaci´on remota de actuadores.
Dise˜nar e implementar un panel de control puede ser consultado v´ıa Internet a trav´es de un computador o dispositivo m´ovil. Los datos se muestran en la interfaz gr´afica.
Realizar operaciones con los datos de los sensores con el fin de obtener datos de inter´es sobre el cultivo.
3.1.
Tipos de Bases de Datos
3.1.1.
Bases de datos no relacionales NoSQL [12]
La aparici´on del t´ermino NoSQL viene de la mano con la llegada de la web 2.0 ya que hasta ese momento el contenido de la red era subido por empresas que ten´ıan un portal, pero con la llegada de aplicaciones como Facebook, Twitter o Youtube, cualquier usuario pod´ıa subir contenido, provocando as´ı un crecimiento exponencial de los datos.
Es en este momento cuando empiezan aparecen los problemas de la gesti´on de toda esa in-formaci´on almacenada en bases de datos relacionales. En un principio, para solucionar estos problemas de accesibilidad, las empresas optaron por utilizar un mayor n´umero de m´aquinas aun asi la solucion era muy costosa y seria a corto plazo. La otra soluci´on era la creaci´on de sistemas pensados para un uso espec´ıfico que con el paso del tiempo han dado lugar a soluciones robustas, apareciendo as´ı NoSQL.
Por lo tanto, hablar de bases de datos NoSQL es hablar de estructuras que permiten alma-cenar informaci´on en aquellas situaciones en las que las bases de datos relacionales generan ciertos problemas debido principalmente a escalabilidad y rendimiento de las bases de datos relacionales donde se dan cita miles de usuarios concurrentes y con millones de consultas diarias.
3.1 Tipos de Bases de Datos 6
Ventjas Bases de Datos NoSQL [12]
Las bases de datos NoSQL tienen ciertas ventajas, sobre las bases de datos relacionales de las cuales de destacan:
Consumen poco recurso: A diferencia de las bases de datos SQL, no requieren dema-siado recurso computaci´onal, por lo que se pueden montar en m´aquinas m´as baratas.
Escalabilidad horizontal: Para mejorar el rendimiento de estas bases de datos simple-mente se consigue a˜nadiendo m´as nodos, con la ´unica operaci´on de indicar al sistema cu´ales son los nodos que est´an disponibles.
Gran cantidad de datos: Est´an en la capacidad de procesar gran cantidad de datos debido a que utiliza una estructura distribuida, en muchos casos mediante tablas Hash.
No genera cuellos de botella: El principal problema de las bases de datos SQL es que necesitan transcribir cada sentencia para poder ser ejecutada, y cada sentencia compleja requiere adem´as de un nivel de ejecuci´on a´un m´as complejo, lo que constituye un punto de entrada en com´un, que ante mucha petici´on puede ralentizar el sistema.
Diferencias con Bases de Datos SQL [12]
No utilizan SQL como lenguaje de consultas: La mayor´ıa de las bases de datos NoSQL evitan utilizar este tipo de lenguaje o lo utilizan como un lenguaje de apoyo. Por ejemplo: Cassandra utiliza el lenguaje CQL, MongoDB utiliza JSON o BigTable hace uso de GQL.
No utilizan estructuras fijas como tablas para el almacenamiento de los datos. Permiten hacer uso de otros tipos de modelos de almacenamiento de informaci´on como sistemas de clave–valor, objetos o grafos.
la operaci´on no es la b´usqueda de una clave, la sobrecarga puede llegar a ser muy cos-tosa. Las soluciones m´as directas consisten en desnormalizar los datos, o bien realizar el JOIN mediante software, en la capa de aplicaci´on.
Arquitectura distribuida: Las bases de datos relacionales suelen estar centralizadas en una ´unica m´aquina o bien en una estructura m´aster–esclavo, sin embargo, en los casos NoSQL la informaci´on puede estar compartida en varias m´aquinas mediante mecanismos de tablas Hash distribuidas.
Tipos de bases de datos NoSQL [12]
De acuerdo a como se organiza la informaci´on encontramos diversos tipos de bases de datos NoSQL
1. Bases de datos clave–valor: Son el modelo de base de datos NoSQL m´as popular, por ser la m´as sencilla en cuanto a funcionalidad. En este tipo de sistema, cada elemento est´a identificado por una llave ´unica, lo que permite la recuperaci´on de la informaci´on de forma muy r´apida, informaci´on que habitualmente est´a almacenada como un objeto binario (BLOB). Se caracterizan por ser muy eficientes tanto para las lecturas como para las escrituras. Algunos ejemplos de este tipo son Cassandra, BigTable o HBase.
Figura 3-1: Bases de datos clave–valor [12].
3.1 Tipos de Bases de Datos 8
adem´as de realizar b´usquedas por clave–valor, realizar consultas m´as avanzadas sobre el contenido del documento.
Son las bases de datos NoSQL m´as vers´atiles. Se pueden utilizar en gran cantidad de proyectos, incluyendo muchos que tradicionalmente funcionar´ıan sobre bases de datos relacionales. Algunos ejemplos de este tipo son MongoDB o CouchDB.
Figura 3-2: Bases de datos Documentales [12].
3. Bases de datos en grafo: En este tipo de bases de datos, la informaci´on se representa como nodos de un grafo y sus relaciones con las aristas del mismo, de manera que se puede hacer uso de la teor´ıa de grafos para recorrerla. Para sacar el m´aximo rendimiento a este tipo de bases de datos, su estructura debe estar totalmente normalizada, de forma que cada tabla tenga una sola columna y cada relaci´on dos.
Figura 3-3: Bases de datos en grafo [12].
4. Bases de datos orientadas a objetos: En este tipo, la informaci´on se representa mediante objetos, de la misma forma que son representados en los lenguajes de programaci´on orientada a objetos (POO) como ocurre en JAVA, C# o Visual Basic .NET. Algunos ejemplos de este tipo de bases de datos son Zope, Gemstone o Db4o.
Escogeremos MongoDB el cual est´a escrito en C++, aunque las consultas se hacen pasando objetos JSON como par´ametro. Es algo bastante l´ogico, dado que los propios documentos se almacenan en BSON. Por ejemplo:
db . C l i e n t e s . f i n d ({Nombre : ” Pedro ”}) ;
La consulta anterior buscar´a todos los clientes cuyo nombre sea Pedro.
MongoDB viene de serie con una consola desde la que podemos ejecutar los distintos co-mandos. Esta consola est´a construida sobre JavaScript, por lo que las consultas se realizan utilizando ese lenguaje. Adem´as de las funciones de MongoDB, podemos utilizar muchas de las funciones propias de JavaSciprt. En la consola tambi´en podemos definir variables, funciones o utilizar bucles.
3.1.2.
MongoDB
3.2 Elecci´on Base de Datos 10
b´usquedas y consistencia estricta.[10]
Figura 3-4: MongoDB [10].
MongoDB ha sido creado para brindar escalabilidad, rendimiento y gran disponibilidad, es-calando de una implantaci´on de servidor ´unico a grandes arquitecturas complejas de centros multidatos. MongoDB brinda un elevado rendimiento, tanto para lectura como para escritu-ra, potenciando la computaci´on en memoria (in-memory). La replicaci´on nativa de MongoDB y la tolerancia a fallos autom´atica ofrece fiabilidad a nivel empresarial y flexibilidad opera-tiva. [10]
3.2.
Elecci´
on Base de Datos
Para la elecci´on de la base de datos se tomaron en cuenta diversos aspectos los cuales se nombran a continuaci´on:
Compatibilidad con el servidor:Al tomar como lenguaje base JavaScript, se realiz´o una consulta sobre la compatibilidad con diversas bases de datos, la cual arrojo co-mo resultado que JavaScript y Node.JS el cual gestiona y compila el c´odigo, tiene compatibilidad y soporte para bases de datos SQL y NoSQL.
es decir en cualquier momento un nuevo dispositivo podr´ıa incluir un nuevo tipo de variable, en las bases de datos SQL la adici´on de una nueva variable implica un cambio en el modelo entidad relaci´on, por el contrario una de las m´as grandes virtudes de las bases de datos NoSQL es su escalabilidad, esta es una de las razones que motiva al uso de bases de datos NoSQL.
Recurso Computacional: Uno de los aspectos relevantes de las bases de datos NoSQL es que realizan consultas utilizando un lenguaje diferente a SQL, debido a que esto implica transcribir cada sentencia para que sea ejecutada, y las sentencias requieren un nivel de ejecuci´on m´as complejo, lo cual constituye que todas estas solici-tudes generen un punto de entrada en com´un, lo cual antes muchas peticiones pueden ralentizar el sistema.
3.2.1.
Teorema CAP o Teorema de Brewer [3]
Formulado por Eric Brewer, profesor de la Universidad de Berkeley, su teorema trata acerca de las tres dimensiones de los sistemas distribuidos (de almacenamiento de datos en este caso), los cuales son:
Consistencia (Consistency): implica que la informaci´on permanece coherente y consis-tente despu´es de cualquier operaci´on sobre los datos, de modo que cualquier usuario que acceda a los mismos ver´a la misma informaci´on.
Disponibilidad (Availability): significa que toda la informaci´on del sistema de almace-namiento de datos distribuido est´a siempre disponible.
Tolerancia de las Particiones (Partition Tolerance): se refiere a que las diferentes partes del sistema distribuido (los nodos) continuar´an funcionando normalmente, aunque la comunicaci´on entre ellos se vea interrumpida o no sea confiable.
3.2 Elecci´on Base de Datos 12
C y A: Son sistemas en los que si falla la comunicaci´on entre sus nodos el conjunto no puede trabajar.
C y P: en estos, si algo ocurre parte de la informaci´on no estar´a disponible, pero seguir´an funcionando y la informaci´on disponible ser´a consistente.
A y P: durante un fallo de uno de los nodos (o falta de comunicaci´on) la informaci´on estar´a disponible, pero puede que no sea consistente.
Con estas combinaciones es posible clasificar los sistemas de almacenamiento de datos y conocer a qu´e categor´ıa pertenece cada uno de los sistemas usados com´unmente, sabiendo en cada caso qu´e caracter´ısticas proporcionan y si se adaptan a las necesidades, sabiendo que cada una tendr´a sus deficiencias. a continuaci´on, se muestra un diagrama que representa el teorema y ubica dichos sistemas:
Figura 3-5: Teorema CAP [2].
3.3.
Modelos
Los modelos son constructores compilados a partir de nuestras definiciones de esquema. Estos modelos representan documentos que se pueden guardar y recuperar de la base de datos. Toda la creaci´on y recuperaci´on de documentos de la base de datos est´a a cargo de estos modelos. Los modelos se guardan en Mongo DB como colecciones(collections).
Con la ayuda de Mongoose el cual ofrece una soluci´on sencilla, basada en esquemas para modelar los datos de aplicaci´on, as´ı como provee validaci´on, generaci´on de consultas, ganchos de l´ogica de negocios, creamos los modelos.
Para nuestra base de datos tenemos los siguientes modelos:
3.3.1.
Usuarios(user)
Tabla 3-1: Colecci´on de Usuarios.
3.3 Modelos 14
ayuda para que la contrase˜na sea encriptada, es decir agrega un nivel de seguridad a las credenciales del usuario, tampoco es posible saber la contrase˜na desde la base de datos, por eso se hace necesario una opci´on que provea una nueva contrase˜na, esta opci´on se implementa m´as adelante.
Tabla 3-2: Colecci´on de Productos.
3.3.3.
Sensors
Tabla 3-3: Colecci´on de Sensores.
Este modelo es donde se guardar´an los datos tomados por los sensores, el cual tiene una breve descripci´on de qu´e tipo de medida se va a realizar, la unidad de medida, el dato, la fecha y la hora en las que estos fueron tomados.
3.3.4.
Granjas(farm)
Tabla 3-4: Colecci´on de Granjas.
3.3 Modelos 16
seguridad de que los datos y los dispositivos solo pueden ser modificados por el administrador o el empleado de la granja, de este modelo podemos destacar la localizaci´on, la cual se usa para tener ubicada la granja en el mapa y as´ı tener una interfaz m´as sencilla para el usuario, en el caso de que tenga diversas granjas.
3.3.5.
Mis Granjas(MyFarms)
Mis Granjas
Nombre Tipo
PostedBy Id user Farms Id Farm
Tabla 3-5: Colecci´on de Mis Granjas.
Con este modelo un usuario que este registrado y sea administrador podr´a crear una nueva granja y adicionarla a mis granjas, de esta manera solo ´el y los empleados que designe podr´an acceder a las granjas que est´en en MyFarms.
3.3.6.
Ejecutivos(leaderships)
Con este modelo adicionamos nuevos ejecutivos a la p´agina, esto con el fin de dar a conocer informaci´on sobre los creadores y los administradores de la aplicaci´on.
3.3.7.
Modelo Equivalente Entidad/Relaci´
on
4 Servidor (REST Server)
Para el dise˜no e implementaci´on del servidor se utiliz´o un servidor de tipo REST el cual de-riva de Representational State Transfer.o“transferencia de representaci´on de estado”. REST es que un servicio que no tiene estado (es stateless), lo que quiere decir que, entre dos lla-madas cualquiera, el servicio pierde los datos. Esto es, que no se puede llamar a un servicio REST y pasarle unos datos y esperar este recuerde nuestros datos en la siguiente petici´on. De ah´ı el nombre: el estado lo mantiene el cliente y por lo tanto es el cliente quien debe pasar el estado en cada llamada. Para que un servicio REST recuerde, hay que recordarle quien soy en cada llamada. Para nuestro caso usaremos un token.
Para mantener un estado se requiere que este en alg´un sitio com´unmente se usa memoria en el cual se guarda los estados de todos los clientes. Entre m´as clientes, m´as memoria, hasta que en cierto punto en el cual no podemos admitir m´as clientes, por falta de memoria. Un problema de la web tradicional.
4.1.
NodeJS
Node es un int´erprete Javascript del lado del servidor que cambia la noci´on de c´omo deber´ıa trabajar un servidor. Su meta es permitir a un programador construir aplicaciones altamente escalables y escribir c´odigo que maneje decenas de miles de conexiones simult´aneas en una s´olo una m´aquina f´ısica.
Node es un gestor de eventos en tiempo de ejecuci´on as´ıncrono impulsado por JavaScript, Node est´a dise˜nado para construir aplicaciones de red escalables Node es similar en dise˜no los sistemas como la m´aquina de eventos de Ruby o Python’s Twisted. Node toma el modelo de eventos un poco m´as all´a, se presenta un bucle de eventos como una construcci´on en tiempo de ejecuci´on en lugar de una librer´ıa. En otros sistemas, siempre hay una llamada de interrupci´on para iniciar el bucle de eventos.
4.1 NodeJS 20
Figura 4-1: Node.JS [8].
Las siguientes son las ventajas de utilizar Node.js:
Los desarrolladores tienen alta probabilidad de familiaridad con el lenguaje Java debido a su estatus como un est´andar de facto para la web y para m´oviles desarrollo.
El uso de un solo idioma para front-end y back-end de desarrollo acelera el proceso de codificaci´on. El cerebro de un desarrollador no tiene que cambiar entre diferentes sintaxis, un denominado cambio de contexto. los el aprendizaje de m´etodos y clases va m´as r´apido.
Con Node.js, se pod´ıa crear prototipos r´apidamente e ir al mercado para hacer el desarrollo de clientes y captaci´on de clientes temprana. Esta es una importante ventaja competitiva frente a otras empresas que utilizar tecnolog´ıas menos ´agiles (por ejemplo, PHP y MySQL).
4.1.1.
Pila de Aplicaciones
¿Qu´e partes necesitan ser implementadas para poder satisfacer nuestros casos de uso? este es uno de los primeros interrogantes que surgen al iniciar con el desarrollo de la aplicaci´on a continuaci´on se muestran dichas partes:
Queremos servir p´aginas web, de manera que necesitamos un Servidor HTTP. Dicho servidor necesitar´a responder directamente peticiones (requests), dependiendo de qu´e URL sea pedida en este requerimiento, es que necesitaremos alg´un tipo de enrutador (router) de manera de mapear los peticiones a los handlers (manejadores) de ´estos.
Para satisfacer a las peticiones que llegaron al servidor y han sido enrutados usando el enrutador, es necesario el uso de handlers (manejadores) de peticiones, el Enrutador probablemente deber´ıa tratar cualquier informaci´on POST que llegue y entregarla a los handlers de peticiones de una forma conveniente, luego necesitaremos manipulaci´on de dicha de petici´on.
Por otra parte una funci´on conveniente es desplegar contenido cuando estas URLs sean pedidas, lo que significa que necesitamos alg´un tipo de l´ogica en las vistas a ser utilizada por los handlers de peticiones, de manera de poder enviar contenido al navegador del Usuario.
Por ´ultimo, el usuario o los diferentes tipos de usuario ser´an capaz de subir im´agenes o archivos, as´ı que necesitaremos alg´un tipo de manipulaci´on de carga de archivos.
en principio se pens´o en una de las soluciones mas usadas en los ´ultimos a˜nos para desarrollar la pila de aplicaciones con esto con PHP. Cuya configuraci´on t´ıpica ser´ıa un Apache HTTP server con mod php5 instalado. Lo que, significa que necesitamos ser capaces de servir p´ agi-nas web y recibir peticiones HTTP algo que no ocurre dentro de PHP.
4.2 Especificaci´on de requisitos de software 22
4.1.2.
Modulos
Otra de las funciones ampliamente usadas en este proyecto es la de adicionar m´odulos debido a que Javascript nativo no da soporte a los m´odulos. Esto es algo que se ha agregado en NodeJS y se realiza con la sentencia require().
La instrucci´on require() recibe como par´ametro el nombre del paquete que queremos incluir e inicia una b´usqueda en el sistema de archivos, en la carpeta ”node modules”, que contienen todos los m´odulos que podr´ıan ser requeridos.
Por ejemplo, si deseamos agregar la librer´ıa para hacer un servidor web, que escuche solici-tudes http, har´ıamos lo siguiente:
v a r h t t p = r e q u i r e ( ” h t t p ” ) ;
Existen distintos m´odulos que por defecto en cualquier proyecto NodeJS y que por tanto no necesitamos traernos previamente a local mediante el gestor de paquetes npm. Esos toman el nombre de ”M´odulos nativos 2 ejemplos de ellos tenemos el propio ”http”, ”fs”para el acceso al sistema de archivos, ”net”que es un m´odulo para conexiones de red todav´ıa de m´as bajo nivel que ”http”.
4.2.
Especificaci´
on de requisitos de software
A continuaci´on, se muestra la Especificaci´on de Requisitos Software (ERS) para el Sistema de informaci´on para la gesti´on de procesos y control de inventarios. Esta especificaci´on se ha estructurado bas´andose en las directrices dadas por el est´andar IEEE Pr´actica Recomendada para Especificaciones de Requisitos Software ANSI/IEEE 830, 1998.
Prop´osito: El presente documento tiene como prop´osito definir las especificaciones funcionales, no funcionales para el desarrollo de una plataforma de gestion de siste-mas de riego que permitir´a gestionar distintos procesos administrativos, agr´ıcolas y de automatizaci´on.
la cual tiene por objetivo principal el gestionar los distintos procesos (comunicaciones, actuadores, registro de actividades,mediciones calculadas y copia de seguridad).
4.2.1.
Personal involucrado
Nombre Danny Mora
Rol Analista, dise˜nador y programador
Categoria profesional Estudiante
Responsabilidad An´alisis de informaci´on, dise˜no y programaci´on del PIGSR-I Infomracion de contacto [email protected]
Nombre David Millan
Rol Analista, dise˜nador y programador
Categoria profesional Estudiante
Responsabilidad An´alisis de informaci´on, dise˜no y programaci´on del PIGSR-I Infomracion de contacto [email protected]
4.2.2.
Definiciones, acr´
onimos y abreviaturas
Nombre Descripcion
Usuario Persona que usar´a el sistema para gestionar procesos PIGSR-I Plataforma integral de gesti´on de sistemas de riego
ERS Especificaci´on de Requisitos Software RF Requerimiento Funcional RNF Requerimiento No Funcional
4.3 Descripci´on general 24
4.2.3.
Referencias
Titulo del Documento Referencia
Standard IEEE 830 - 1998 IEEE
4.2.4.
Resumen
Este documento consta de tres secciones. En la primera secci´on se realiza una introducci´on al mismo y se proporciona una visi´on general de la especificaci´on de recursos del sistema. En la segunda secci´on del documento se realiza una descripci´on general del sistema, con el fin de conocer las principales funciones que ´este debe realizar, los datos asociados y los factores, restricciones, supuestos y dependencias que afectan al desarrollo, sin entrar en excesivos detalles.
Por ´ultimo, la tercera secci´on del documento es aquella en la que se definen detalladamente los requisitos que debe satisfacer el sistema.
4.3.
Descripci´
on general
4.3.1.
Perspectiva del producto
4.3.2.
Funcionalidad del producto
Figura 4-2: Funcionalidad del producto.
4.3.3.
Caracter´ısticas de los usuarios
Tipo de usuario Invitado
Formacion Basica
Actividades Observa informaci´on
Tipo de usuario Administrador
Formacion Agr´ıcola
4.3 Descripci´on general 26
Tipo de usuario Ordinario
Formacion B´asico en agricultura
Actividades Observa informaci´on y crea rutinas
Tipo de usuario SuperUsuario
Formaci´on Ingeniero
Actividades Acceso a todo el sistema
4.3.4.
Restricciones
Interfaz para ser usada con internet.
Uso de Dominio (X)
Lenguajes y tecnolog´ıas en uso: HTML, JAVASCRIPT.
Los servidores deben ser capaces de atender consultas concurrentemente.
El sistema se dise˜nar´a seg´un un modelo cliente/servidor.
El sistema deber´a tener un dise˜no e implementaci´on sencilla, independiente de la pla-taforma o del lenguaje de programaci´on.
4.3.5.
Suposiciones y dependencias
Se asume que los requisitos aqu´ı descritos son estables
4.4.
Requisitos espec´ıficos
4.4.1.
Requerimientos Funcionales
Identificaci´on del requeri-miento
RF01
Nombre del Requerimiento Autentificaci´on de Usuario.
Caracter´ısticas Los usuarios deber´an identificarse para acceder a cual-quier parte del sistema.
Descripci´on del requeri-miento
El sistema podr´a ser consultado por cualquier usuario dependiendo del m´odulo en el cual se encuentre y su nivel de accesibilidad.
Caracter´ısticas Los usuarios deber´an registrarse en el sistema para ac-ceder a cualquier parte del sistema.
Descripci´on del requeri-miento
El sistema permitir´a al usuario (empleado, ordinario, superusurario y Administrador) registrarse. El usuario debe suministrar datos como: CI, Nombre, Apellido, E-mail, Usuario y Password.
Requerimiento NO funcio-nal
RNF01, RNF02, RNF05, RNF06, RNF07
4.4 Requisitos espec´ıficos 28
Identificaci´on del requeri-miento
RF03
Nombre del Requerimiento Consultar Informaci´on.
Caracter´ısticas El sistema ofrecer´a al usuario informaci´on general acerca de la granja, sensores, actuadores, calendario de riegos. Descripci´on del
requeri-miento
Consultar Mis Granjas: Muestra informaci´on general sobre las granjas que la, dispositivos asociados, carac-ter´ısticas de estos dispositivos.
Nombre del Requerimiento Consultar Informaci´on.
Caracter´ısticas El sistema ofrecer´a al usuario informaci´on general acerca de la granja, sensores, actuadores,calendario de riegos. Descripci´on del
requeri-miento
Consultar Calendario de Eventos: Muestra a los usuarios informaci´on relevante sobre sus sensores y actuadores. Requerimiento NO
funcio-nal
RNF01, RNF02
Identificaci´on del requeri-miento
RF05
Nombre del Requerimiento Modificar.
Caracter´ısticas El sistema permitir´a al administrador y superusuario modificar los datos personales, rutinas de sensado y ta-reas de riego.
Descripci´on del requeri-miento
Permite al administrador modificar datos de los usua-rios, productos y cuentas creadas asociadas a sus gran-jas.
Nombre del Requerimiento Gesti´on de Granjas.
Caracter´ısticas Permite gestionar informaci´on referente a las granjas. Descripci´on del
requeri-miento
Crear Granjas: Permite al administrador una vez haya accedido con su cuenta, crear una granja y suministrar informaci´on relevante sobre los productos, as´ı como aso-ciar empleados.
Requerimiento NO funcio-nal
RNF01, RNF02, RNF05, RNF06, RNF07
4.4 Requisitos espec´ıficos 30
Identificaci´on del requeri-miento
RF07
Nombre del Requerimiento Gesti´on de Granjas.
Caracter´ısticas Permite gestionar informaci´on referente a los productos. Descripci´on del
requeri-miento
Agregar productos: Permite al administrador una vez haya accedido con su cuenta, acceder a una granja y agregar un producto el cual suministra informaci´on re-levante sobre los productos.
Nombre del Requerimiento Gesti´on de Granjas.
Caracter´ısticas Permite gestionar informaci´on referente a las granjas. Descripci´on del
requeri-miento
Registrar empleados: El empleado deber´a suministrar su c´edula de identidad y nombre juntamente con una contrase˜na para poder incluirse en una granja. Granja:
El estudiante deber´a suministrar su nombre juntamente con una contrase˜na para poder acceder a una granja.
Requerimiento NO funcio-nal
RNF01, RNF02, RNF05, RNF06, RNF07
Identificaci´on del requeri-miento
RF09
Nombre del Requerimiento Gesti´on de Granjas.
Caracter´ısticas Permite gestionar informaci´on referente a las granjas. Descripci´on del
requeri-miento
Consultar productos: permite a los empleados, adminis-trador ver informaci´on de productos.
Requerimiento NO
funcio-Nombre del Requerimiento Gesti´on de Granjas.
Caracter´ısticas Permite gestionar informaci´on referente a las granjas. Descripci´on del
requeri-miento
Descargas: Permite a los usuarios descargar datos de los sensores que est´an asociados a sus productos.
Requerimiento NO funcio-nal
RNF01, RNF02, RNF05, RNF06, RNF07
4.4 Requisitos espec´ıficos 32
Identificaci´on del requeri-miento
RF11
Nombre del Requerimiento Gesti´on de Actuadores.
Caracter´ısticas Permite gestionar informaci´on referente a los actuado-res.
Descripci´on del requeri-miento
Permite a los usuarios empleado y administrador, ges-tionar las rutinas de los actuadores, las cuales se ver´an reflejadas al d´ıa siguiente.
Nombre del Requerimiento Integraci´on de componentes.
Caracter´ısticas El sistema tendr´a una gesti´on administrativa y operati-va.
Descripci´on del requeri-miento
Los componentes deben integrarse al sistema de infor-maci´on web proporcionando los recursos necesarios, con el prop´osito de que la interacci´on con los usuarios sea provechosa en la administraci´on de la informaci´on de la granja.
Requerimiento NO funcio-nal
RNF01, RNF02, RNF05
Identificaci´on del requeri-miento
RF13
Nombre del Requerimiento Gestionar Reportes.
Caracter´ısticas El sistema permitir´a generar reportes. Descripci´on del
requeri-miento
Permite al administrador visualizar gr´aficas de los sen-sores y reportes de los actuadores, as´ı como tambi´en, ver listados de productos.
Caracter´ısticas El sistema permitir´a generar reportes. Descripci´on del
requeri-miento
Permite al administrador visualizar gr´aficas de los sen-sores y reportes de los actuadores, as´ı como tambi´en, ver listados de productos.
Requerimiento NO funcio-nal
RNF01, RNF02
4.4 Requisitos espec´ıficos 34
Identificaci´on del requeri-miento
RF15
Nombre del Requerimiento Auditor´ıa del sistema.
Caracter´ısticas Garantizar las soluciones de problemas existentes me-diante la utilizaci´on del sistema.
Descripci´on del requeri-miento
Evaluar y analizar los procesos del sistema, proponien-do soluci´on de problemas existentes dentro del sistema utilizado.
Nombre del Requerimiento Interfaz del sistema.
Caracter´ısticas El sistema presentara una interfaz de usuario sencilla para que sea de f´acil manejo a los usuarios del sistema.
Descripci´on del requeri-miento
El sistema debe tener una interfaz de uso sencilla y que su uso sea amigable con el usuario.
Identificaci´on del requeri-miento
RNF02
Nombre del Requerimiento Ayuda en el uso del sistema.
Caracter´ısticas La interfaz del usuario deber´a de presentar un sistema de contacto para que los mismos usuarios del sistema se les faciliten el trabajo en cuanto al manejo del sistema. Descripci´on del
requeri-miento
La interfaz debe estar complementada con un buen siste-ma de ayuda (la administraci´on puede recaer en personal con poca experiencia en el uso de aplicaciones inform´ ati-cas).
Prioridad del requerimiento: Alta
Identificaci´on del requeri-miento
RNF03
Nombre del Requerimiento Dise˜no de la interfaz a la caracter´ıstica de la web. Caracter´ısticas El sistema deber´a de tener una interfaz de usuario,
te-niendo en cuenta las caracter´ısticas dadas por el usuario. Descripci´on del
requeri-miento
La interfaz de usuario debe ajustarse a las caracter´ısticas de la web, dentro de la cual estar´a incorporado el sistema de gesti´on de procesos y el inventario.
4.4 Requisitos espec´ıficos 36
Identificaci´on del requeri-miento
RNF04
Nombre del Requerimiento Desempe˜no
Caracter´ısticas El sistema garantizara a los usuarios un desempe˜no en cuanto a los datos almacenado en el sistema ofreci´endole una confiabilidad a esta misma.
Descripci´on del requeri-miento
Garantizar el desempe˜no del sistema inform´atico a los diferentes usuarios. En este sentido la informaci´on al-macenada o registros realizados podr´an ser consultados y actualizados con cierta frecuencia, sin que se afecte el tiempo de respuesta.
Prioridad del requerimiento: Alta
Identificaci´on del requeri-miento
RNF05
Nombre del Requerimiento Nivel de Usuario
Caracter´ısticas Garantizara al usuario el acceso de informaci´on de acuer-do al nivel que posee.
Descripci´on del requeri-miento
Facilidades y controles para permitir el acceso a la infor-maci´on al personal autorizado a trav´es de Internet, con la intenci´on de consultar y subir informaci´on pertinente para cada una de ellas.
Identificaci´on del requeri-miento
RNF06
Nombre del Requerimiento Confiabilidad contin´ua del sistema.
Caracter´ısticas El sistema tendr´a que estar en funcionamiento las 24 horas los 7 d´ıas de la semana. Ya que es una p´agina web dise˜nada para la carga de datos y comunicaci´on entre usuarios.
Descripci´on del requeri-miento
La disponibilidad del sistema debe ser continua con un nivel de servicio para los usuarios de 7 d´ıas por 24 ho-ras, garantizando un esquema adecuado que permita la posible falla en cualquiera de sus componentes, contar con una contingencia, generaci´on de alarmas.
Prioridad del requerimiento: Alta
Identificaci´on del requeri-miento
RNF07
Nombre del Requerimiento Seguridad en informaci´on
Caracter´ısticas El sistema garantizara a los usuarios una seguridad en cuanto a la informaci´on que se procede en el sistema. Descripci´on del
requeri-miento
Garantizar la seguridad del sistema con respecto a la informaci´on y datos que se manejan tales sean docu-mentos, archivos y contrase˜nas.
4.5 Requisitos comunes de las interfaces 38
4.5.
Requisitos comunes de las interfaces
4.5.1.
Interfaces de usuario
La interfaz con el usuario consistir´a en un conjunto de ventanas con botones, listas y campos de textos. ´Esta deber´a ser construida espec´ıficamente para el sistema propuesto y, ser´a visualizada desde un navegador de internet o aplicaci´on para tel´efono inteligente.
4.5.2.
Interfaces de hardware
Ser´a necesario disponer de equipos de c´omputos en perfecto estado con las siguientes carac-ter´ısticas:
Sistema Operativo: Windows 7 o superior, GNU Linux, Mac.
Explorador: Mozilla, Chrome e Internet Explorer.
4.5.4.
Interfaces de comunicaci´
on
4.6.
Rutas
Para realizar las consultas, modificaciones, creaci´on y eliminaci´on, es necesario la creaci´on de rutas estas rutas est´an organizadas en archivos separados para cada uno de los modelos. Para realizar las solicitudes se usan los cuatro m´etodos, principales en el protocolo HTTP lo cuales son: GET, POST, PUT y DELETE.
GET: Se usa para cualquier operaci´on no destructiva, segura y que no causa efectos secundarios. Una petici´on GET puede ser pasada por un proxy y se puede crear un marcador. Es una operaci´on muy ´util.[11]
POST: La m´as importante de las cuatro operaciones. Puede realizar cualquier ac-cion.Por lo tanto se debe ser muy cuidadoso al momento de utilizarlo. No se puede hacer un marcador, no se debe hacer nada con POST sin consultar con el usuario.[11]
4.6 Rutas 40
4.6.2.
Rutas de Granjas
Granjas (farms)
Ruta Metodo Descripcion Entrada(JSON) Permisos
/
get consultar todas las granjas - superUser post crear una nueva granja /models/leaderships adminUser
delete todas las granjas - superUser
/:farmId
get consultar granjas por Id - ordinaryUser put actualizar granja por Id $update adminUser delete eliminargranja por Id - adminUser
Tabla 4-2: Descripci´on de las rutas de granjas.
4.6.3.
Rutas de Mis Granjas
4.6 Rutas 42
4.6.4.
Rutas de Producto
Productos (Products)
Ruta Metodo Descripcion Entrada(JSON) Permisos
/
get consultar todos los productos - superUser post crear un nuevo producto /models/product ordinayUser delete borrar todos los productos - superUser
/:productId
get consultar un producto - ordinayUser put actualizar un producto {’a’:”,’b’:”} ordinayUser
delete borrar un producto - adminUser
Tabla 4-4: Descripci´on de las rutas de producto.
4.6.5.
Rutas de Sensores
post crear un nuevo sensor /models/sensors ordinayUser delete borrar todos los
senso-res
- superUser
/:sensorId
get consultar un sensor - ordinayUser put actualizar un sensor {’a’:”,’b’:”} ordinayUser delete borrar un sensor - adminUser /:sensorId/download get generar reporte como
csv
4.6.6.
Rutas de Ejecutivos
Ejecutivos (leaderships)
Ruta Metodo Descripcion Entrada(JSON) Permisos
/
get consultar todos los ejecutivos
-superUser post crear un nuevo ejecutivo /models/leaderships
delete eliminar todos los ejecutivos
-/:leaderId
get consultar un ejecutivo por Id - -put actualizar un ejecutivo por Id $update
superUser delete eliminar un ejecutivo por Id
4.7 Configuraci´on del servidor 44
4.7.
Configuraci´
on del servidor
En las anteriores secciones se muestran las rutas y la funci´on que cada una cumple, estas rutas tienen que ir anexadas a una url base, esta conexi´on se realiza en app.js, adicional a esto se usa Secure Sockets Layer SSL (capa de puertos seguros), la cual provee seguridad al servidor mediante certificados adicionados en el archivo www
4.7.1.
Certificados de seguridad
Se utilizaron certificados SSL los cuales proporcionan autenticaci´on y privacidad de la in-formaci´on entre extremos sobre Internet mediante el uso de criptograf´ıa. Para nuestro caso ´
unicamente el servidor es autenticado, el cliente se mantiene sin autenticar. El uso de estos certificados nos permiten usar HTTPS Hypertext Transfer Protocol Secure (Protocolo seguro de transferencia de hipertexto), es un protocolo de aplicaci´on basado en el protocolo HTTP, que tiene como objetivo realizar una transferencia segura de datos. node provee m´odulos para realizar las conexiones https, se utiliza el puerto 3000 que es un puerto seguro.
5.1.
AngularJS [9]
Para el desarrollo de la plataforma, se utiliz´o el framework AngularJS, el cual provee paquetes y funciones, los cuales brindan los requisitos m´ınimos para ejecutar la p´agina. AngularJS [6] tiene disponibles m´odulos los cuales son fundamentales en el desarrollo y tienen como funci´on organizar el c´odigo en librer´ıas.
Figura 5-1: Descripcion AngularJS [5].
5.2 API de Google Maps 46
Controladores: Los controladores ayudan a implementar la l´ogica de la presenta-ci´on en AngularJS. Con ellos es posible mantener el c´odigo necesario para iniciar una aplicaci´on y gestionar eventos. Adicional gestionan el flujo del lado del cliente, para implementar la funcionalidad asociada a la presentaci´on.
Las funciones de los controladores son principalmente separar ciertas partes del c´odigo de una aplicaci´on y evitar Javascript este en la vista. Con el fin que HTML utilizado no se mezcle con Javascript.
Factorias:Las factor´ıas son contenedores de c´odigo usados en el desarrollo de nuestro sitio web. Son un tipo de servicio, con el que entre otras cosas podemos implementar librer´ıas de funciones o almacenar datos.
Tienen como particularidad retornar un dato, de cualquier tipo. Para nuestro caso un objeto de Javascript. A diferencia de los controladores, las factor´ıas se caracterizan de ser instanciados una ´unica vez dentro de las aplicaciones, por lo que no pierden su estado.
$Scope:El scope es la permite que los datos en los controladores pasen a las vistas, y viceversa. Es el enlace transporta esos datos de un lugar a otro.
5.2.
API de Google Maps
Google maps provee un API el cual consiste de archivos JavaScript que contienen las clases, m´etodos y propiedades que se usan para el comportamiento de los mapas, ademas nos provee los siguientes servicios:
Integra mapas b´asicos, mapas con estilos, edificios en 3D y planos para pisos de inte-riores.
Agrega el nivel de la calle e im´agenes satelitales.
5.3.
Vistas
5.3.1.
Inicio
Al ingresar a la plataforma cuya url es http://rita.udistrital.edu.co:23617/ se tiene la si-guiente vista:
Figura 5-2: Vista inicio plataforma
5.3 Vistas 48
Aqu´ı encontramos en la parte superior de izquierda a derecha, icono de la p´agina, inicio, Quienes somos, Cont´actenos, Mis Fincas y por ultimo inicio de sesi´on.
En el cuerpo vemos la informaci´on general de la p´agina, luego vemos los productos disponibles a la venta y en la parte inferior la informaci´on de contacto de la p´agina.
5.3.2.
Inicio de Sesi´
on
Cuando se hace click sobre el inicio de sesi´on se muestra la siguiente vista:
Figura 5-4: Inicio de Sesi´on plataforma
Aqu´ı podemos acceder a nuestra cuenta con el nombre de usuario y la contrase˜na y poner la opci´on de recordar contrase˜na.
Registrar como nuevo usuario
Al hacer click sobre Click aqui para registrarse se muestra la siguiente vista:
En esta opci´on podremos crear un nuevo usuario llenando el formulario y poder ser admi-nistrador de nuestra finca, o empleado de la misma.
Olvido de contrase˜na
Al hacer click sobre olvidaste tu contrase˜na se muestra la siguiente vista:
Figura 5-6: Restablecer contrase˜na plataforma
En esta opci´on podremos restablecer la contrase˜na con el correo electr´onico, esta opci´on env´ıa un link al correo electr´onico para realizar el cambio de la contrase˜na.
5.3.3.
Quienes Somos
Al hacer click en la pesta˜na quienes somos se muestra la siguiente vista:
5.3 Vistas 50
Figura 5-8: Quienes somos vista inferior
En esta pesta˜na se muestra informaci´on de inter´es sobre los creadores y administradores de la p´agina, as´ı como una breve historia del grupo de investigaci´on.
5.3.4.
Cont´
actenos
Al hacer click en la pesta˜na Cont´actenos se muestra la siguiente vista:
Figura 5-10: Cont´actenos vista insferior
en la imagen 5-9 se observa la informaci´on de contacto de los administradores de la p´agina web y de los dispositivos con el fin de dar soporte, en la imagen 5-10 vemos un formato en el cual se puede enviar una opini´on sobre los productos.
5.3.5.
Mis fincas
Al hacer click en la pesta˜na Mis fincas se muestra la siguiente vista:
Figura 5-11: vista Mis fincas
5.3 Vistas 52
Figura 5-12: Crear una nueva finca
Figura 5-13: Nueva finca en el mapa
al dar click sobre la nueva finca, se muestran los productos que pertenecen a esta finca, la imagen 5-14 muestra c´omo se ver´ıa una finca sin ning´un producto
para agregar un nuevo producto o modulo es necesario dar click en el bot´on agregar modulo, la imagen 5-15 muestra como agregar un nuevo producto
Figura 5-15: agregar un nuevo producto a mi finca
en la figura 5-16 vemos como quedara nuestra finca al agregar un producto
5.4 Controladores 54
5.4.
Controladores
Controlador Funci´on Servicios usados
HeaderController Permite hacer registro de un nuevo usuario o iniciar
se-AboutController Solicita la informaci´on de todos los integrantes del proyecto
corporateFactory
ContactController Adquiere los datos ingre-sados del formulario y los env´ıa a la base de datos
feedbackFactory
farmController Solicita al servidor la in-formaci´on fincas vinculadas al usuario registrado, coloca en el mapa la ubicaci´on de cada una de las fincas aso-ciadas y permite hacer el re-gistro de una nueva finca
farmDetail Con-troller
solicita la informaci´on de la finca seleccionada anterior-mente, solo si el usuario lo requiere consume los datos de cada uno de los sensores y acatadores asociados con la posibilidad de descargar los datos en formato (.csv)
farmFactory, productFac-tory, universalFactory
PassController Este controlador solo ser´a usado mediante un link que se env´ıa al correo para rees-tablecer la contrase˜na.
passFactory
GraphController Realiza la solicitud de los datos de los sensores selec-cionados para poder repre-sentarlos en una gr´afica rec-tangular de tiempo vs valor
universalFactory
5.5 Servicios 56
5.5.
Servicios
Servicios Funci´on
AuthFactory Almacena, elimina y usa credenciales para mantener la sesi´on abierta en cualquier ventana, permite el inicio de la sesi´on, el registro de un nuevo usuario, consumiendo los recursos REST-SERVER de la ruta (users Tabla4-1) corporateFactory Consume los recursos REST-SERVER (leadership 4-6) productFactory Consume los recursos REST-SERVER (products 4-4) feedbackFactory Consume los recursos REST-SERVER (feedback 4-6) myfarmFactory Consume los recursos REST-SERVER (myfarms/:id
3-5)
farmFactory Consume los recursos REST-SERVER (farms 4-3) addProdFractory Consume los recursos REST-SERVER (farms/addprod
4-4)
passFactory Consume los recursos REST-SERVER (users/change-pass/ 4-1)
$localStorag Almacena y consulta datos de una variable o un objeto almacenados en la memoria local del navegador
5.6.
Mapa del sitio
6 Aplicaci´
on Android
6.1.
Dise˜
no
6.1.1.
Ionic
framework que trabaja con Cordova y que permite crear aplicaciones muy vistosas gracias a Angular.js. El framework est´a construido con Angular y SASS, SASS es un preprocesador CSS, el cual permite trabajar con elementos CSS de una forma muy c´omoda. As´ı, Ionic provee de una serie de componentes con los que se pueden crear aplicaciones que est´an a la par de las aplicaciones nativas. Con un punto muy interesante, debido a que solo se debe saber HTML, CSS y Angular.
Por otra parte permite desarrollar aplicaciones son hibridas, esto quiere decir que se pueden desarrollar aplicaciones que corran en Android, iOS, Windows Phone sin tener que desarro-llarla 2 o 3 veces como si se tuviera que hacer con el correspondiente lenguaje nativo de cada plataforma.
Ionic, permite trabajar y usar al maximo todas las capacidades del m´ovil mediante adicci´on de plugins desarrollados por la comunidad. Los plugin estan disponibles para toda la comu-nidad y pueden realizar todo tipo de funciones tales como acceder a las propiedades de la c´amara, un plugin que permita usar el GPS, plugins que permiten usar el bluetooth. Existen infinidad de plugin disponibles.
Por otra parte, dispone de un CLI (Commando Line Interface) con el que usando la terminal se pueden crear nuevos proyectos a gusto, por ejemplo, bien empezando con un proyecto en blanco o con alguna peque˜na estructura determinada acorde a las necesidades del cliente. Tambi´en es posible compilar el proyecto, emular nuestra aplicaci´on mediante un emulador o hacer que corra nuestra aplicaci´on en nuestro tel´efono mediante un solo comando.
Ionic por ser una colecci´on de librer´ıas y frameworks ser´a de gran ayuda para avanzar r´ api-damente en alg´un proyecto. A continuaci´on, se muestra un Flujo de Trabajo el cual se utiliz´o en el desarrollo de la aplicaci´on M´ovil. Ante un Proyecto de desarrollo m´ovil se identifican 5 etapas principales.
6.1.2.
Etapas del Desarrollo con Ionic [4]
Figura 6-2: Etapas del desarrollo [4].
6.2 Conexi´on con el dispositivo 60
Usuarios, etc.
Dise˜no: En esta etapa vamos a tener una mayor idea de lo que se est´a hablando. Normalmente, en esta etapa se trabaja de la mano de un dise˜nador gr´afico con el cual se obtienen unos wireframes inicialmente, los cuales son una versi´on muy temprana del aspecto general de las interfaces y son utilizados para convertirlos en Mockups, los cuales son una versi´on m´as parecida al producto final de que estamos buscando lograr.
Prototipado: Esta es la etapa en la que nos vamos a enfocar ya que es donde realmente se realiza el trabajo del desarrollador, aunque se recomienda dar un acompa˜namiento en las otras etapas, realmente lo que aprender´as en este libro lo podr´as aplicar aqu´ı.
Pruebas: En esta etapa probamos la funcionalidad que hemos implementado en la fase de prototipado en b´usqueda de errores en la funcionalidad, en la usabilidad, etc. Este libro toca un poco sobre esta fase, pero se recomienda profundizar con material m´as especializado.
Mediciones: En esta etapa tratamos de obtener datos de nuestros usuarios utilizando herramientas como Analytics implementados en nuestra App y Encuestas para nuestros usuarios. De esta manera podemos tomar decisiones sobre que caracter´ısticas agregar, eliminar y mejorar.
6.2.
Conexi´
on con el dispositivo
La aplicaci´on que en principio tiene las mismas funciones de la plataforma, con una funci´on adicional y es la conexi´on con el dispositivo que controlar´a el cultivo, esta conexi´on se dar´a por medio de la tecnolog´ıa Bluetooth.
Bluetooth [1]:se denomina como especificaci´on industrial para Redes Inal´ambricas de ´Area Personal (WPAN) pensada en principio para la transmisi´on de voz y datos entre diferentes dispositivos radiofrecuencia en la frecuencia de los 2.4 GHz. Cuyos objetivos son:
Eliminar cables y conectores como el de aud´ıfonos en m´oviles.
Se crea la posibilidad usar peque˜nas redes inal´ambricas.
Ionic dispone de m´odulos los cuales proveen funciones con las cuales se pueden usar los perif´ericos, para la conexi´on del dispositivo se us´o el siguiente modulo:
6.2.1.
Bluetooth Low Energy (BLE)[1]
Este complemento permite la comunicaci´on en serial a trav´es de Bluetooth. Fue escrito en un principio para la este complemento permite la comunicaci´on entre un tel´efono y los perif´ericos Bluetooth Low Energy (BLE). El complemento proporciona una API JavaScript sencilla para iOS y Android.
B´usqueda de perif´ericos
Conectar a un perif´erico
Leer el valor de una caracter´ıstica
Escribir un nuevo valor a una caracter´ıstica
Se notifica cuando el valor de la caracter´ıstica cambia
Plataformas soportadas
iOS
Android (4.3 o superior)
6.2.2.
Protocolo de comunicaci´
on
6.2 Conexi´on con el dispositivo 62
Figura 6-3: Protocolo comunicaci´on con dispositivo.
el protocolo da inicio cuando el dispositivo y el Smartphone, tienen el Bluetooth encendido y en estado de escucha.
1. El Smartphone mediante la aplicaci´on hace el escaneo de los dispositivos activos a su alcance.
2. El usuario selecciona el dispositivo al cual se quiere conectar.
3. El dispositivo tiene que haber estado pareado con anterioridad en el Smartphone.
4. cuando el Usuario selecciona el dispositivo, se realiza la solicitud de conexi´on hacia el dispositivo.
6. El Smartphone env´ıa un saludo al dispositivo, esto con el fin de que el dispositivo inicie el envi´o de los datos.
7. Dispositivo responde con los Id de los actuadores asociados a este, organizados en un Json.
8. Smartphone consulta la informaci´on de los actuadores mediante el Id recibido del dispositivo.
9. Smarphone env´ıa la configuraci´on de los actuadores para que sea modificada en Dis-positivo.
10. Dispositivo modifica las rutinas de los actuadores y env´ıa listo actuadores.
11. Smartphone responde con una confirmaci´on Ok
12. Cuando dispositivo recibe la confirmaci´on, procede a enviar un Json con los Id de los sensores y los datos tomados desde la ultima conexi´on.
13. Smartphone recibe los datos de los sensores, y procede a enviarlos al servidor.
14. Smartphone env´ıa una confirmaci´on de que los datos quedaron guardados en el servidor.
6.3 Vistas Aplicaci´on 64
6.3.
Vistas Aplicaci´
on
Figura 6-4: Vista inicio de la plataforma.
Figura 6-6: Vista Acerca de nosotros de la plataforma.
6.3 Vistas Aplicaci´on 66
Figura 6-8: Vista Mis fincas de la plataforma.
Figura 6-10: Vista SensorTag de la plataforma.
6.3 Vistas Aplicaci´on 68
Figura 6-12: Vista confirmaci´on de inicio de sesi´on de la plataforma.
Figura 6-14: Vista Dispositivos de la plataforma.
6.4 Mapa del sitio 70
6.4.
Mapa del sitio
7.1.
Pruebas del servidor
Los resultados que se muestran a continuaci´on fueron realizados con el dispositivo SensorTag
7-1, el cual cuenta con diversos sensores, de los cuales se usaron:
sensor de temperatura.
sensor de temperatura infrarojo.
sensor de presi´on.
Figura 7-1: Sensor tag [7]
7.1 Pruebas del servidor 72
7.1.1.
Comportamiento de servidor
La prueba enviaba los datos del sensor hacia el servidor 10 veces en un segundo y se realizo durante 12 horas, entonces se tienen los siguientes datos:
3 sensores.
600 pruebas por minuto por cada sensor.
Duraci´on de la prueba: 12 horas.
Por sensor se tuvieron 7200 datos, es decir en total obtuvimos 21600 datos.
Durante el tiempo que se realiz´o la prueba, se observa se presentaban demoras a la hora de realizar una solicitud a la plataforma, al hacer una solicitud de los datos de un sensor mientras que la prueba est´a en curso esta se demoraba aproximadamente 1.5 segundos. En cuanto a seguridad, solo se puede acceder a los datos teniendo una cuenta y que esta cuenta este asociado a dicho producto.
Los datos solo pueden ser borrados por el administrador de la finca.
El servidor tiene los certificados de seguridad y estos previenen ataques durante la transmi-si´on y consulta de los datos.
7.1.2.
Consumo de recursos de red
Durante la prueba realizada con el SensorTag se tomaron datos de los paquetes de entrada y salida y los resultados se muestran a continuaci´on
Figura 7-3: Bytes de red
en esta gr´afica se observan unos picos, el m´as grande corresponde a la instalaci´on de un programa el cual involucraba una descarga de gran cantidad de paquetes. los otros picos corresponden a las consultas realizadas de los datos de todos los sensores, los picos m´as peque˜nos simbolizan las consultas de un sensor en particular.
Luego de ver estos resultados se tom´o la decisi´on de que cuando se realice una consulta ya sea de un sensor o de varios se retornen solo unos cuantos datos lo que se tomaron m´as recientemente, esto con el fin de reducir el uso de la red, de igual manera si se quisiera acceder al hist´orico de los datos se pueden descargar y realizar su an´alisis en una hoja de c´alculo.
7.1.3.
Consumo de recursos computacionales
La m´aquina sobre la que corre la plataforma fue proveida por R.I.T.A(Red de Investigaciones de Tecnolog´ıa Avanzada). y cuanta con los siguientes recursos
Sistema operativo: Debian 8
Memoria RAM: 1 GB
Disco duro 20 GB
7.1 Pruebas del servidor 74
el acceso a esta se realiza mediante un servidor ssh, debido a los recursos no cuenta con interfaz gr´afica, se tomaron diversos datos del consumo de los recursos de la maquina los cuales se prestan a continuaci´on:
Figura 7-4: Bytes de disco
Figura 7-6: Uso de CPU
En cuanto a los bytes de disco vemos que en escritura tiene ciclos repetitivos en los cuales se guardan datos, algunos picos que sobresalen corresponden a la instalaci´on del programa mencionado anteriormente, en cuanto la lectura del disco hacia el 2 de octubre vemos una recta creciente la cual corresponde a cuando se subieron los datos de la plataforma.
Para las operaciones del disco se tiene un comportamiento similar a la de los bytes del disco. El uso de la CPU que es tal vez uno de los indicadores m´as importantes muestra como en principia cuando se instal´o la maquina el uso era m´ınimo, pero durante los d´ıas que se realizaron las pruebas el uso aumento considerablemente esto debido a la gran cantidad de consultas que se realizaron, de igual manera se muestra que los recursos asignados a la maquina son suficientes y no es necesario de alternarlos en un futuro cercano.
7.2.
Interfaz de usuario
7.2 Interfaz de usuario 76
7.2.1.
Virtudes
Una interfaz de usuario sencilla y limpia.
Administraci´on intuitiva de las cuentas de usuario.
F´acil acceso a los datos, ya que estos se presentan de manera organizada.
Uso de certificados de seguridad del lado del servidor.
7.2.2.
Aspectos por mejorar
Disponibilidad de datos y uso de la plataforma cuando no existe conexi´on a internet.
8.1.
Conclusiones
En la actualidad la evoluci´on de las tecnolog´ıas de la informaci´on requiere una pla-taforma que este a la vanguardia, nuestra plapla-taforma est´a construida con tecnolog´ıas actuales que est´an en auge con un alto ´ındice de crecimiento, soporte y estabilidad.
Com´unmente las aplicaciones son desarrolladas bajo la configuraci´on LAMP (Linux, Apache, MySQL, PHP), la configuraci´on escogida para el desarrollo del proyecto MEAN (Mongo, Express, Angular, Node), la cual consume menos recursos de maquina que las configuraciones convencionales, ademas de que todas las partes usen Javascript, incluso esta plataforma puede funcionar en una computadora de bajo costo tipo Raspberry Pi.
En principio el dise˜no de la plataforma estaba pensado para ser compatible con un dispositivo, sin embargo debido al modo de construcci´on de la misma y a la versatilidad de la base de datos (MongoDB) la plataforma tiene unos requisitos m´ınimos para el envi´o de los datos, y las cualidades del dispositivo pueden ser cambiadas en cualquier momento sin necesidad de realizar un cambio en la base de datos.
El rendimiento de las aplicaciones nativas es mucho m´as alto en comparado con las aplicaciones hibridas, pero esto no presenta ninguna limitaci´on para el objetivo que esta desarrollada la aplicaci´on dado que el nivel procesamiento requerido es bajo.
8.1 Conclusiones 78
los mismos componentes tanto para aplicaciones nativas como web se facilita el trabajo en equipo de forma modular para lograr un solo objetivo.
8.2.
Trabajos futuros
Como continuaci´on de este trabajo y en general al proyecto, se muestran algunas propuestas que lo podr´ıan complementar y otras que podr´ıan ampliar su uso en otros ´ambitos diferentes a los sistemas de riego.
Adicionar tecnolog´ıas diferentes a Bluetooth, tales como Xbee, LoRa y WiFi, para la conexi´on del dispositivo.
Se propone implementar alg´un tipo de seguridad en el enlace del SmartPhone y el dispositivo.
Bibliograf´ıa
[1] 2016 Bluetooth SIG, Inc (Ed.): Tecnolog´ıa bluetooth. EEUU : ”https://www.
bluetooth.com”, 2015
[2] Alarc´on, Jos´e M. (Ed.): Campus MVP. Espa˜na : ”http://www.campusmvp.es/
recursos/image.axd?picture=CAP.png”, 2014
[3] Brewer, Erik A. Towards Robust Towards Robust Distributed Systems Distributed
Systems
[4] Co, Drifty: Ionic. http://ionicframework.com/img/ionic-logo-blog.png. 2016. – [En linea; consultado 19/Jul/2016]
[5] Google: AngularJS. https://angularjs.org/img/AngularJS-large.png. 2016. – [En linea; consultado 19/Jul/2016]
[6] G´amez, Alejandro M. (Ed.): Manual de AngularJS. Espa˜na : ”http://www.
desarrolloweb.com/manuales/manual-angularjs.html”, 2015
[7] Instruments, Texas: SensorTag. http://www.ti.com/ww/en/wireless_
connectivity/sensortag2015/images/sensortag-img-bluetooth.png. 2016. –
[En linea; consultado 3/Sep/2016]
[8] Joyent, Inc: NodeJS. https://nodejs.org/static/images/logos/
nodejs-new-white-pantone.png. 2015. – [En linea; consultado 19/Jul/2016]
[9] Marsh, H. (Ed.) ; E.A., Heintz (Ed.) ; Rodriguez-Reinoso, F. (Ed.): Full Stack
[10] MongoDB, Inc.: MongoDB. https://www.mongodb.com/es. 2015. – [En linea; consultado 19/Jul/2016]
[11] Society, The I.: Hypertext Transfer Protocol. https://tools.ietf.org/html/
rfc2616. 1999. – [En linea; consultado 2/Ago/2016]
