SISTEMA DE ALMACENAMIENTO Y TRANSMISIÓN DE DATOS …

1

SISTEMA DE ALMACENAMIENTO Y TRANSMISIÓN DE DATOS APLICADO A LA MEDICIÓN DE VARIABLES EN FUENTES HÍDRICAS

SANTIAGO MEJÍA SÁNCHEZ

UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES INFORME FINAL

2014-2

2

SISTEMA DE ALMACENAMIENTO Y TRANSMISIÓN DE DATOS APLICADO A LA MEDICIÓN DE VARIABLES EN FUENTES HÍDRICAS

SANTIAGO MEJÍA SÁNCHEZ

INFORME DE PROYECTO DE GRADO

DIRECTOR DE PROYECTO DE GRADO

ALVARO MORALES Ingeniero de Sistemas

UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES INFORME FINAL

2014-2

3

TABLA DE CONTENIDO

Pág.

INTRODUCCIÓN ...................................................................................................................... 9

SÍNTESIS ................................................................................................................................ 10

CAPITULO 1: ESPECIFICACIÓN DEL PROYECTO ..................................................................... 11

1.1 SITUACIÓN PROBLEMA ............................................................................................... 11

1.2 OBJETIVO GENERAL .................................................................................................... 13

1.3 OBJETIVOS ESPECÍFICOS ............................................................................................. 13

1.4 JUSTIFICACIÓN ............................................................................................................ 14

CAPÍTULO 2: MARCO TEÓRICO ............................................................................................. 15

2.1. ANTECEDENTES .......................................................................................................... 15

2.1.1 Streamgages: ........................................................................................................ 15

2.1.2 Sistema inalámbrico de medición del nivel del agua - Universidad Técnica de

Ostrava .......................................................................................................................... 16

2.1.3 Monitoreo automático de la calidad del agua en los ríos de Serbia ................... 19

2.1.4 Sistema de control de temperatura a través de Arduino y la tecnología

GPRS/GSM ..................................................................................................................... 20

2.1.5 Sistema de comunicación y transmisión de datos desde estaciones

meteorológicas .............................................................................................................. 21

2.2 MARCO CONTEXTUAL ................................................................................................. 23

2.2.1 Risaralda ............................................................................................................... 23

2.2.2 Pereira .................................................................................................................. 25

2.2.3 Río Consota .......................................................................................................... 26

2.3 MARCO CONCEPTUAL ................................................................................................. 28

2.3.1 Adquisición y Transmisión de Datos .................................................................... 28

2.3.2 Telemetría ............................................................................................................ 28

2.3.3 Sistemas de Telecomunicaciones: ........................................................................ 29

2.3.4 Comunicaciones Móviles ...................................................................................... 29

2.3.5 GSM ...................................................................................................................... 30

2.3.6 GPRS ..................................................................................................................... 33

4

2.3.7 Bases de Datos ..................................................................................................... 34

2.3.8 Sistemas de Gestión de Base de Datos ................................................................ 34

CAPÍTULO 3: METODOLOGÍA ................................................................................................ 37

3.2 CRONOGRAMA ............................................................................................................ 39

3.3 ESTIMACIÓN DE PRESUPUESTO .................................................................................. 42

CAPÍTULO 4: DISEÑO DE LA SOLUCIÓN ................................................................................ 43

4.1 REQUERIMIENTOS ....................................................................................................... 43

4.2 MODELO CONCEPTUAL BASE DE DATOS .................................................................... 49

4.3 MODELO FÍSICO DE LA BASE DE DATOS ..................................................................... 50

4.3.1 DICCIONARIO DE DATOS ...................................................................................... 51

4.4 DISEÑO DE RED ........................................................................................................... 53

4.5 DISEÑO DEL SOFTWARE SERVIDOR ............................................................................ 55

4.5.1 Diagrama de Casos de Uso ................................................................................... 55

4.5.2 Diccionario de Casos de Uso ................................................................................ 55

4.5.3 Diagrama de Clases .............................................................................................. 58

CAPÍTULO 5: IMPLEMENTACIÓN DEL DISEÑO ...................................................................... 59

5.1 DISPOSITIVOS PARA LA SOLUCIÓN ............................................................................. 59

5.1.1 DISPOSITIVO DE PROCESAMIENTO: Arduino Mega 2560 .................................... 59

5.1.2 DISPOSITIVO DE TRANSMISIÓN: Módulo GSM/GPRS SeedStudio v2.0 ............... 60

5.1.3 DISPOSITIVO DE TRANSMICIÓN: Arduino XBEE Pro Shield .................................. 62

5.1.4 ANTENA: Xbee Pro 50MW Serie 2 1500M ........................................................... 62

5.2 CONEXIÓN DE DISPOSITIVOS ...................................................................................... 63

5.3 PREPARACIÓN DE ENTORNO DE DESARROLLO........................................................... 66

5.3.1 Arduino Software ................................................................................................. 66

5.3.2 Lenguaje de Programación Arduino ..................................................................... 68

5.3.3 Sublime Text ......................................................................................................... 68

5.3.4 PHP ....................................................................................................................... 68

5.3.5 MVC (Modelo, Vista, Controlador) ....................................................................... 69

5.3.6 Programación Orientada a Objetos ..................................................................... 69

5.3.7 Apache .................................................................................................................. 70

5

5.3.8 Base de Datos MySQL ........................................................................................... 70

5.3.9 phpMyAdmin ........................................................................................................ 71

5.4 DESARROLLO DE SOFTWARE PARA ESTRUCTURA ARDUINO ..................................... 71

5.4.1 Importación de Librerías y Declaraciones Globales ............................................. 71

5.4.2 Configuración inicial de puertos .......................................................................... 72

5.4.3 Definición de funciones ........................................................................................ 72

5.4.4 Estructuración de ciclo infinito ............................................................................ 75

5.4.5 Definición de formato estándar para cadena de transmisión ............................. 75

5.4.6 Comandos AT para comunicación con módulo GSM/GPRS ................................. 76

5.5 DESARROLLO DE SOFTWARE PARA SERVIDOR ........................................................... 77

5.5.1 Especificación de métodos principales en clases ................................................. 77

5.5.2 Especificación de Controladores .......................................................................... 79

5.6 MEDICIÓN DE CONSUMO DE DATOS .......................................................................... 80

CONCLUSIONES ..................................................................................................................... 83

RECOMENDACIONES ............................................................................................................ 84

REFERENCIAS ........................................................................................................................ 85

ANEXOS ................................................................................................................................. 87

6

LISTA DE FIGURAS

Pág.

Figura 1. Concepciones básicas del sistema de medición y operación ................ 18

Figura 2 Diagrama de Red – Implementado y funcional - Sistema de la UNA ...... 22

Figura 3. Arquitectura de una red GSM ................................................................ 31

Figura 4. Diagrama Entidad Relación .................................................................... 49

Figura 5. Diagrama de Almacenamiento Físico de la Base de Datos ................... 50

Figura 6. Diagrama de Elementos de Red ............................................................ 53

Figura 7. Diagrama de Bloques (Transmisión y Almacenamiento) ........................ 54

Figura 8. Diagrama de Casos de Uso Aplicación Servidor .................................... 55

Figura 9. Diagrama de Clases Aplicación Servidor ............................................... 58

Figura 10. Arduino Mega 2560 .............................................................................. 59

Figura 11. Módulo GSM/GPRS SeedStudio v2.0 .................................................. 60

Figura 12. Arduino Xbee Pro Shield ...................................................................... 62

Figura 13. Xbee Pro Serie 2 .................................................................................. 63

Figura 14. Integración de SIM900 con Arduino Mega (Apilando) .......................... 63

Figura 15 Integración Arduino Mega, GSM/GPRS Shield, Xbee Shield y Antena

Xbee ...................................................................................................................... 65

Figura 16. Interfaz Principal Arduino Software 1.0.5-r2 ........................................ 67

7

LISTA DE TABLAS

Pág.

Tabla 1. Cronograma de Actividades .................................................................... 39

Tabla 2. Estimación de Presupuesto ..................................................................... 42

Tabla 3. Requerimiento 1: Módulo de transmisión ................................................ 43

Tabla 4. Requerimiento 2: Protocolo de transmisión ............................................. 43

Tabla 5. Requerimiento 3. Uso de Datos .............................................................. 43

Tabla 6. Requerimiento 4: Almacenamiento de Datos .......................................... 44

Tabla 7. Requerimiento 5. Almacenar información transmitida ............................. 45

Tabla 8. Requerimiento 6: Actualizar intervalos de sensado ................................. 46

Tabla 9. Requerimiento 7: Tipos de Datos ............................................................ 46

Tabla 10. Requerimiento 8. Mecanismo de almacenamiento ................................ 47

Tabla 11. Requerimiento 9: Cadena de sensado .................................................. 47

Tabla 12. Diccionario Entidad Estación ................................................................. 51

Tabla 13. Diccionario Entidad Sensor ................................................................... 51

Tabla 14. Diccionario Entidad Medición ................................................................ 51

Tabla 15. Diccionario Entidad Propiedad .............................................................. 52

Tabla 16. Caso de Uso 1: Insertar Mediciones...................................................... 55

Tabla 17. Caso de Uso 2: Reportar Estado Sensor .............................................. 56

Tabla 18. Caso de Uso 3: Consultar Intervalo de Sensado ................................... 56

Tabla 19. Caso de Uso 4: Ejecutar Consulta SQL ................................................ 57

Tabla 20. Caso de Uso 5: Cambiar Intervalo de Sensado .................................... 57

Tabla 21. Especificaciones Generales GSM/GPRS SeeedStudio Shield .............. 61

Tabla 22. Descripción de Estados de Leds GSM/GPRS SeedStudio v2 ............... 61

Tabla 23. Descripción de Funciones Construidas ................................................. 72

Tabla 24. Estandarización de cadenas para transmisión. ..................................... 75

Tabla 25. Comandos AT para transmisión GPRS ................................................. 76

Tabla 26. Descripción de métodos más importantes de la clase ‘medicion’ .......... 77

Tabla 27. Descripción de métodos más importantes de la clase ‘estacion’ ........... 79

Tabla 28. Descripción de Controladores ............................................................... 79

Tabla 29. Consumo de Datos Por Cantidad de Mediciones Enviadas .................. 80

Tabla 30. Consumo de Datos Estructura de 2 Estaciones .................................... 81

Tabla 31. Consumo de Datos Estructura de 12 Estaciones .................................. 81

8

LISTA DE ANEXOS

Pág.

Anexo A. Reporte de pruebas ............................................................................... 87

9

INTRODUCCIÓN

El agua como recurso primordial para la existencia de vida en el planeta, debe tener un alto grado de importancia en la investigación científica para su correcta preservación. Colombia es un país que posee considerables fuentes hídricas, y es uno de los países con más cantidad de agua por unidad de superficie, sin embargo en las últimas décadas por causa de la minería, tala de árboles, calentamiento global o actividades de explotación indiscriminada de los recursos, esas fuentes están disminuyendo en cantidades alarmantes, y las aún existentes, están siendo contaminadas por industrias o poblaciones aledañas que vierten sus desechos tóxicos en las mismas, sin ningún tratamiento previo. Es en este campo en donde deberían existir importantes desarrollos de innovación tecnológica para poder monitorear y controlar las fuentes de agua, y a partir de las mediciones obtenidas, tomar decisiones oportunas en cuanto a crecidas súbitas del nivel, niveles altos de toxicidad, niveles bajos de oxígeno, entre otras, con el fin de preservar y realizar una administración consciente y pertinente de las fuentes hídricas. Al analizar estas ideas planteadas se formó la propuesta de generar un sistema de monitoreo de las variables de nivel, caudal y condiciones físico-químicas y poder generar alertas tempranas de inundaciones o alteraciones de las condiciones físico-químicas que será aplicada inicialmente teniendo en cuenta el caso de estudio del tramo urbano del río Consota en la ciudad de Pereira. Como parte de esta propuesta surge el proyecto específico de la creación de un sistema de almacenamiento y transmisión de información desde las zonas de medición hacia el servidor principal que procesará y analizará los datos. Lo que pretenderá específicamente este proyecto es lograr el diseño e implementación de un prototipo del sistema de almacenamiento y transmisión de información, con la finalidad de que este diseño se pueda replicar sin problema en la cantidad de zonas necesarias para un control sólido del río.

10

SÍNTESIS

SÍNTESIS ABSTRACT

Este proyecto presenta el desarrollo de un prototipo para la transmisión y almacenamiento de un sistema de telemetría enfocado para la toma de variables físico-químicas en fuentes hídricas, tomando como caso de estudio el Río Consota de la ciudad de Pereira, Colombia.

Se muestra un acercamiento a la problemática para la que se desea plantear la solución, los diferentes modelos, diseños, diagramas y especificación de la implementación de dichos diseños, describiendo el proceso de desarrollo del prototipo de transmisión vía GPRS y la estructura de almacenamiento y el gestor para hacer efectivo la comunicación entre ambas partes, así como la integración con otros dos proyectos relacionados con el sistema autónomo de medición y el sistema de información web en el que se presentará la información.

Descriptores: Transmisión, Almacenamiento, Base de Datos, GPRS, MySQL, PHP, Telemática, Fuentes Hídricas, Arduino.

This Project presents the development of a transmission prototype and storage structure for a telemetry system, focused in the measurement of physicohemical variables in wáter sources, taking as a case of study the Consota River from Pereira, Colombia.

This shows and approach to the problem in need for solution, different processes, designs, diagrams and specification of the implementation of these designs, describing the process of developing the GPRS transmission prototype and the storage structure. It also presents the developing of a simple database manager to make effective comunication between both modules, as well as the integration with two other projects related with the autonomous measurement system and the web information system in which the information will be presented.

Descriptors: Transmission, Storage, Database, GPRS, MySQL, PHP, Telematics, water sources, Arduino.

11

CAPITULO 1: ESPECIFICACIÓN DEL PROYECTO

1.1 SITUACIÓN PROBLEMA En los últimos años se ha generado gran incertidumbre en cuanto al abastecimiento de agua pura para las futuras generaciones, puesto que las fuentes de agua dulce han estado experimentado diferentes fenómenos como la inestabilidad de laderas, crecidas súbitas y por consiguiente inundaciones en poblaciones aledañas, altos niveles de contaminación y cantidades considerables de residuos sólidos, que demuestran grandes falencias en el control y administración de las fuentes hídricas. Muchas de las problemáticas mencionadas se presentan en los ríos y quebradas que atraviesan la ciudad de Pereira, como sucede concretamente con el río Consota, el cual representa una de las dos cuencas más importantes de la ciudad, junto con el río Otún. El río Consota atraviesa a Pereira por el costado sur, con un flujo de oriente a occidente; posee una extensión de 132 kilómetros cuadrados, un recorrido de 48 kilómetros aproximadamente desde el sector de El Manzano hasta su desembocadura en el río La Vieja cera al municipio de Cartago. El tramo urbano del río Consota cubre 9 kilómetros, allí se albergan 240 mil personas y 60 mil viviendas aproximadamente, las cuales están distribuidas en 14 comunas y 217 barrios, por lo que representan una importante población que se encuentra a la expectativa de cualquier fenómeno natural o ambiental que pueda suceder con la cuenca en cuestión, ya que se verían directamente afectados con cualquier alteración de la fuente hídrica. Actualmente, la cuenca no cuenta con ningún sistema de monitoreo confiable que permita conocer variables como el nivel de agua, caudal y en general sus condiciones físico-químicas. Por estas razones se propone diseñar e implementar un sistema de monitoreo y alerta temprana de inundaciones y alteraciones físico-químicas para el tramo urbano de la cuenca del río Consota, el cual contará con un sistema de instrumentación, de alta tecnología que permitirá alertar de manera oportuna a las autoridades correspondientes y a la comunidad en general, generando además con su implementación un incremento significativo de conocimiento y acervo histórico sobre el comportamiento del río Consota. Como parte del proyecto anteriormente mencionado se plantea la necesidad de Diseñar e implementar un sistema de almacenamiento y transmisión de información desde los puntos de medición hasta el servidor central ubicado en la Universidad Católica de Pereira, por lo que este proyecto busca enfocarse principalmente en la creación de un sistema de obtención de datos desde las

12

estaciones de sensores ubicadas en la cuenca hasta la plataforma software en donde se realizará el análisis de la información.

13

1.2 OBJETIVO GENERAL Diseñar e implementar un sistema de almacenamiento y transmisión de información desde los puntos remotos de medición en fuentes hídricas hasta el servidor de base de datos.

1.3 OBJETIVOS ESPECÍFICOS

● Realizar un levantamiento de información de sistemas de almacenamiento y transmisión de información desde sitios de medición remotos de manera inalámbrica, para una posterior elección de tecnologías y protocolos a implementar.

● Diseñar y construir un sistema de almacenamiento que reciba periódicamente las mediciones enviadas desde las estaciones de medición.

● Diseñar e implementar un sistema de transmisión de datos que permita el envío de las mediciones desde las zonas determinadas hacia el servidor principal.

● Realizar la integración del sistema de almacenamiento con el sistema de transmisión, de tal manera que pueda ser replicable cuantas veces sea necesario para la cobertura de zonas amplias.

● Ejecutar las pruebas correspondientes en el sistema general de medición, para comprobar el correcto funcionamiento de los módulos de almacenamiento y transmisión.

14

1.4 JUSTIFICACIÓN El correcto desarrollo del sistema de almacenamiento y transmisión de información desde un sistema de sensado remoto al servidor principal apoya directamente al proyecto de mayor envergadura que permitirá un monitoreo completo de las variables ya mencionadas a medir en la cuenca. Para lograr cumplir los objetivos del proyecto, se debe implementar un sistema de base de datos, el cual integrará conocimientos en el diseño y gestión de base de datos, para generar un sistema de almacenamiento estable y de calidad, mientras que el campo de la transmisión de información integra conocimientos en protocolos de comunicaciones, comunicaciones inalámbricas, herramientas de desarrollo, especificación de equipos y estándares de comunicación. Además de los conceptos aportados desde estos dos módulos, es de gran importancia rescatar la integración que será necesaria entre ambos, por lo que se deberán examinar las diferentes tecnologías que puedan consolidar la comunicación entre ambos aspectos del proyecto y elegir la más adecuada para desarrollar sobre ella. Todos los aportes teóricos y prácticos que se generarán en el desarrollo del proyecto para complementar el sistema telemetría en fuentes hídricas, finalmente podrán brindar un completo sistema de almacenamiento y transmisión que podrá ser aplicado a cualquier otro tipo de sistema en el cual se necesite el envío y almacenamiento de información desde lugares remotos, y deberá permitir una escalabilidad estable al momento de replicar el sistema en más nodos de medición, es decir que todos los conceptos y conocimientos generados a partir del proyecto no sólo pueden llegar a ser funcionales en para el monitoreo específico del caso de estudio río Consota, sino que también podrán apoyar desarrollos futuros que ofrezcan aportes significativos a la región y el país.

15

CAPÍTULO 2: MARCO TEÓRICO

El agua es considerado como el recurso más importante, o por lo menos, uno de los recursos más importantes para el desarrollo de la vida de todos los seres humanos, y por ser un recurso limitado (en algunos lugares más limitado que en otros). Por la gran importancia que tiene el recurso en la vida de la humanidad, muchos han sido los proyectos enfocados a la preservación, administración e investigación del mismo, aunque en Colombia, son contados los proyectos enfocados a esto, quizás por la gran abundancia del recurso en el mismo, se llega a subestimar la preservación del mismo. En los últimos años el mundo ha atravesado por fuertes olas invernales, en las cuales suceden diversos fenómenos de inundaciones, derrumbes y tormentas tropicales, es allí donde los ríos empiezan a jugar un papel protagónico en cuanto a la seguridad y tranquilidad de las diferentes poblaciones Colombianos, por lo que la necesidad de tener sistemas de alerta temprana sobre inminentes crecidas de las fuentes hídricas ha incrementado a medida que las inundaciones en principales ciudades del país y en poblaciones cercanas a río s se vuelven cada vez más frecuentes y de mayor magnitud.

2.1. ANTECEDENTES El desarrollo de sistemas de monitoreo de flujo y calidad de agua en los ríos apoyan de diversas maneras el desarrollo sostenible de la sociedad en general, puesto que apoya a que las diferentes organizaciones estatales, de planeación y de regulación puedan desarrollar mecanismos y metodologías de prevención que permitan actuar de maneras más efectivas y seguras en fenómenos que impliquen el desbordamiento de ríos y contaminación de los mismos. A continuación se definen algunos proyectos, que se han desarrollado o planteado, los cuales muestran avances importantes que se han tenido en el mundo.

2.1.1 Streamgages: La USGS (Servicio Geológico de los Estados Unidos) opera alrededor de 7000 puntos de medición de las condiciones de flujo de ríos los cuales llaman “streamgages” en todo el país, y lo definen como “una estructura localizada junto a un río que contiene un dispositivo de medición y registro del nivel del agua en el río”. Estas mediciones son realizadas automáticamente cada 15 minutos y la mayoría de estas son enviadas vía satélite a las oficinas de la USGS cada 4 horas o más frecuentemente en épocas climáticas críticas.

16

“Good planning and good decisions depend on good information”1: Una buena planeación y decisiones acertadas dependen de una buena información, por lo que es de vital importancia que las comunidades, negocios y familias que viven en zonas aledañas a los ríos tengan una información confiable acerca de las diferentes variables de la fuente fluvial, por diversas razones las cuales se ven reflejadas en las siguientes necesidades planteadas por la USGS:

Los organismos de planeación necesitan saber qué áreas son propensas a inundaciones, para así evitar que las familias o empresas construyan en estas zonas.

La comunidad en general necesita alertas de inminentes inundaciones para así ayudar a la toma de decisiones sobre evacuaciones o traslado de objetos valiosos lejos de las zonas en peligro.

Las comunidades necesitan información para la planeación y administración de sus fuentes de agua para el futuro.

Las comunidades y agricultores necesitan información acerca de las condiciones de agua en sus fuentes para apoyar el desarrollo de estrategias que permitan sobrellevar fenómenos de sequía.

El estado y los departamentos de vías necesitan información para diseñar obras (puentes, carreteras y alcantarillas) que funcionen sin problemas en situaciones de inundación.

Las empresas de regulación y gestión del agua necesitan información del flujo de los ríos, así como de la calidad del agua, para desarrollar planes rentables para el mejoramiento y protección de la calidad del agua.

Las personas con actividades que involucren los ríos, como la pesca, deportes como el kayak, viajes y actividades de aventura, necesitan información para conocer las condiciones de inseguridad en los ríos y evitar los gastos en viajes a locaciones remotas aledañas a ríos cuando las condiciones no son adecuadas para la recreación. La caracterización realizada por la USGS pone en una perspectiva, bastante interesante y acertada, el proyecto y demuestra todos los beneficios que se pueden obtener con el registro de datos de nuestras fuentes naturales de agua y da unos muy buenos argumentos para apoyar la realización de este tipo de proyectos alrededor del mundo, argumentos que van desde cuidar la calidad y pureza del agua, pasando por la apoya la planeación de obras de toda una ciudad, hasta la optimización de las actividades recreativas realizadas en ríos.

2.1.2 Sistema inalámbrico de medición del nivel del agua - Universidad Técnica de Ostrava

1

U.S. Department of the Interior y U.S. Geological Survey. Information Sheet: Streamgages

- Measuring the Pulse of our Nation's Rivers. Abril 2001

17

Los ingenieros Viliam Gajdoš y Petr Novák del Departamento de Robótica de la Universidad Técnica de Ostrava desarrollaron un Sistema inalámbrico de medición del nivel del agua de un río, el cual sirve como ejemplo de un proyecto que plantea la utilización de varias tecnologías para lograr un control del nivel del río e incluye un sistema de alarma en la aplicación de gestión que funciona como prevención ante posibles inundaciones por el aumento del nivel del agua en el río. El sistema desarrollado por los checos mide el nivel del agua del río en tres diferentes lugares geográficos y utiliza un sistema de transmisión de datos inalámbrico entre los puntos de medición para su visualización en la aplicación que incluye el sistema de alarma. Las tres estaciones de medición poseen transferencia de datos inalámbrica entre ellas y hacia la estación principal que se encuentra en el centro de control. La estación de operación principal integra un computador personal con la aplicación de control y visualización que corre en la plataforma Windows NT4.0 y se encuentra comunicada gracias al modem tipo MC12F. El dispositivo módem se comunica con la aplicación de control vía serial RS-232. Cada estación de medición se basa en un micro controlador UTC 520S y una estación transmisora inalámbrica. El proceso de transmisión de datos entre el micro controlador y su correspondiente transmisor es realizado gracias al protocolo de transmisión serial RS-232. Cada sistema de medición cuenta con una sonda de ultrasonido la cual es encargada de obtener la señal de medición análoga y posteriormente procesada por el sistema de control del microprocesador. La interfaz del micro controlador contiene un módulo de conversión Análogo/Digital tipo M520AD1.

18

Figura 1. Concepciones básicas del sistema de medición y operación

Fuente: WGAJDOŠ, Viliam. NOVÁK, Petr WIRELESS RIVER WATER LEVEL MEASURING

SYSTEM

Los valores obtenidos por la sonda son tomadas en intervalos periódicos de tiempo, son procesadas y guardadas en la memoria del micro controlador temporalmente mientras son enviados y almacenados la estación de operación para posteriormente ser reemplazados en la memoria del micro controlador por nuevos registros. La aplicación de control fue desarrollada en el ambiente depurador MON520 usado en el computador personal, este ambiente permite la descarga y depuración de las aplicaciones y programas presentes en el micro controlador al computador personal guardándolo en una memoria reservada e independiente. La transmisión de datos usa el dispositivo Motorola tipo GM350. El cual es un dispositivo adecuado para la cooperación de todos los parámetros y funciones programables, dando una mayor efectividad a la comunicación. La estación de operación usa un dispositivo de comunicación inalámbrica Radio modem tipo MC12F y coopera con el computador personal vía serial RS-232. El MC12F Radio Data Interface es un dispositivo universal dirigido a la transmisión de datos radiales que convierte las señales de radio (HF/VHF/UHF) en señales de comunicación digital. El dispositivo permite la combinación de diferentes fuentes de información todas en una red de radio. La aplicación hace posible la visualización digestible de la información en tablas o gráficas, y el sistema de alarma vigila los valores límites (configurables) del nivel del agua y opera una sirena. En muchas características este proyecto sirve como ejemplo para el desarrollo a ser realizado para el tramo del río Consota, ya que implementa estaciones de

19

medición en diferentes partes del río, un sistema de comunicación inalámbrico (que sería lo más óptimo) y un centro de operación principal para controlar las alarmas en casos de aumentos inminentes del nivel del agua, A pesar de que algunos de los equipos y características descritas en el artículo científico, de los ingenieros Gajdoš y Novák, son algo difícil de conseguir o relacionar en el mercado Colombiano e incluso global, las características de la estructura general del sistema planteado pueden ser fácilmente relacionales con cualquier proyecto que pretenda la obtención de información de diferentes puntos de medición hacia un punto central de control.

2.1.3 Monitoreo automático de la calidad del agua en los ríos de Serbia La manera tradicional de monitorear la calidad del agua de un río consiste en tomar unas muestras manuales en locaciones remotas y transportar las muestras al laboratorio para sus respectivos análisis químicos, sin embargo esta manera de monitoreo toma bastante tiempo y tiene unos altos costos de trabajo, en ocasiones puede estar limitado por condiciones climáticas y puede dar resultados inconsistentes, además que no permite una continua recolección de datos. La Agencia de Protección del Medio Ambiente Serbio y el Servicio de Estado Hidrometeorológico de Serbia realizan proyectos de monitoreo automático de la calidad del agua en los ríos de Serbia. Un ejemplo de esto es la implementación de una estación de observación de parámetros básicos como la temperatura, nivel de pH, concentración de oxígeno disuelto y electro-conductividad en el río Kolubara, un afluente del río Sava (Localizado en Beli Brod). El cual fue puesto en funcionamiento en Julio del 2008 en cooperación con Alemania y su proyecto de hermanamiento ‘Fortalecimiento de las capacidades de la Dirección General del Agua’, monitoreando sólo parámetros básicos de la calidad del agua. El principio de esta estación automática es basado en la extracción del agua del río. Una parte del flujo del agua es direccionada a un depósito que contiene los sensores inmersos los cuales obtienen los datos y son guardados usando un data-logger, y es transmitido a través de un modem GSM al servidor en las sedes del Servicio Hidrometeorológico de la República de Serbia y finalmente es almacenado en una base de datos central. Los sensores se encuentran encapsulados en una sonda e instalados en la entrada del agua para la continua extracción del agua del río, proporcionando flujo de agua a la reserva. El sistema igualmente contiene un medidor para el flujo del agua. Las ventajas del concepto de la configuración de este sistema de medida están en que es más fácil acceder a los sensores para mantenimiento y limpieza regular, y

20

debido a que los sensores se encuentran en el flujo a la reserva, no pueden ser dañados, impactados o afectados por la presencia del hielo en invierno. En la estación se encuentra instalado un Datalogger SEBA MDS5 con un conversor Análogo/Digital de 16-bits. El almacén de datos es una memoria-flash serial con capacidad de 1MB (suficiente para alrededor de 480 mil valores de medida), la cual puede ser conectada al datalogger vía serial RS232, RS485 o USB. El logger recibe la energía por un adaptador a la red pública y el consumo de energía en modo de bajo consumo es menor a 7.5mAh. En caso de ocurrir una interrupción de energía externa, el logger tiene una batería de litio interna como reserva. La estación está equipada con un modem GSM/GPRS MC35iT, por lo que la comunicación es posible gracias al servicio GSM. El paquete de software para la recepción, ajuste y control consiste en los programas: Wbedien 32, DEMASole y DEMASdb. Los indicadores de la calidad del agua del río Kolubara son mostradas en tiempo real por el sitio web del Servicio Hidrometeorológico de la República de Serbia (RHMS), en al que se puede seleccionar los parámetros a visualizar, el inicio y final de la observación. Dos estaciones más fueron instaladas en el río Tisa con un número mayor de parámetros, sumándole a los parámetros básicos, tres sensores para turbiedad, ion de amonio y clorofila. Estas fueron instaladas también en el 2008 y sus datos fueron almacenados en la base de datos, sin embargo los parámetros observados no son realistas, lo que se indica una falta de calibración de los sensores en las sondas multi-parámetros, y debido a esto los resultados nunca han estado disponibles para el público.

2.1.4 Sistema de control de temperatura a través de Arduino y la tecnología

GPRS/GSM

Un proyecto de carrera realizado por Alberto Castro Domínguez en la Universidad Politécnica de Madrid fue realizado con el fin de estudiar las posibilidades de un sistema para el control de temperatura basa en la plataforma Arduino, realizando un sistema que permita la consulta y control de la temperatura ambiente a través de la red de comunicaciones móviles. En el desarrollo del proyecto se realizó una análisis de las distintas placas Arduino, se evaluaron una serie de módulos de expansión compatibles con tal plataforma para lograr la dotación de un sistema de comunicación basado en tecnología GPRS/GSM. Finalmente el proyecto concluyó con el diseño de una aplicación basada en el entorno de desarrollo Arduino, el cual permitió realizar la evaluación de las

21

distintas funciones y capacidades del sistema, así como la comunicación con la plataforma a través de SMS para el control remoto de la temperatura. Este proyecto es un ejemplo sólido de la arquitectura que podría ser planteada para la solución a diseñar como Sistema de monitoreo de la cuenca del río Consota, puesto que se logró construir una plataforma de pruebas en las que se analizó las diferentes funcionalidades que ofrecen el equipamiento de un micro-controlador Arduino, un shield GPRS, un sensor de temperatura y varios actuadores, logrando el propósito de conocer cómo se puede establecer comunicación a través del módulo GPRS/GSM y así interactuar con varios sensores y actuadores por medio de la plataforma Arduino.

2.1.5 Sistema de comunicación y transmisión de datos desde estaciones

meteorológicas

Los Ingenieros David Schvartzman, Jaime Julio Saavedra y los Profesores Jorge Andrés Molina, Delia Cohenca y Fernando Pio Barrios publicaron en la Revista Iberoamericana de Ingeniería Industrial de la Universidad Federal de Santa Catalina un artículo en la cual se plantea de manera cualitativa y se describe la propuesta de solución a la necesidad de obtener variables meteorológicas desde estaciones remotas y transmitirlas con eficiencia y seguridad a un servidor central encargado de almacenarlas en una base de datos. Los datos correspondientes a las variables censadas deben ser enviados a un servidor de manera que los mismos puedan ser publicados en forma gráfica o tablas, para cualquier usuario que requiera utilizar los datos en tiempo real o histórico. El proyecto se enfoca en la elección de la mejor opción desde el punto de vista de la ingeniería para lograr el diseño de un sistema de comunicación que pueda ser usada en cualquier sitio del país (Paraguay) permitiendo obtener mediciones precisas y actualizadas de las variables climáticas, planteando solución de utilizar la red de telefonía celular existente GSM, o mediante enlaces radioeléctricos dedicados a un punto central en la facultad de ingeniería de la Universidad Nacional de Asunción (UNA).

22

Figura 2 Diagrama de Red – Implementado y funcional - Sistema de la UNA

Fuente: SCHVARTZMAN, SAAVEDRA, MOLINA, COHENCA, & BARIOS, 2012

Como se observa en la Figura 2, se realizó un enlace que une las dos sed Facultad de Ingeniería. La sede ubicada en el campus de (FIUNA) y la sede ubicada en Isla Bogado, Luque (CITEC) En la realización del enlace, los investigadores consideraron que “El equipo que mejor se adapta a los requerimientos para realizar un puente de capa 2 (bridge) y que abarca estas distancias es el robustez y el protocolo que utilizan hacen a estos equipos los más adecuados. Con el AirMax habilitado se consigue un CCQ del 100%, lo que quiere decir que no hay pérdidas en la transmisión (sin el como máximo 80%).” Finalmente concluyeron que “El hecho de poseer un enlace dedicado entre la FIUNA y el CITEC garantiza que los datos de la estación meteorológica instalada en el CITEC podrán transmitirse regularmente en distintas condiciones. A su vez, el elevado ancho de banda de la red -60 Mbps Full Dúplex desplegada puede ser aprovechado para compartir archivos, servidores, bases de datos y otros tipos de aplicaciones.” (SCHVARTZMAN, SAAVEDRA, MOLINA, COHENCA, & BARIOS, 2012)

23

2.2 MARCO CONTEXTUAL

El campo de acción inicial del proyecto se plantea en el departamento de Risaralda, en la ciudad de Pereira, específicamente en su río Consota, tomando como muestra un tramo del mismo, para entender de mejor manera el contexto en el que se implementara el plan general cabe dar a conocer información general y descriptiva de los actores que hacen parte del proceso, empezando con los actores generales, para entrar a las especificidades del actor principal que es el río Consota:

2.2.1 Risaralda

El sitio web de la Gobernación de Risaralda en la sección “Conozcamos a Risaralda” lo describe como una región que se caracteriza por sus paisajes, riquezas naturales, culturales y étnicas, alta densidad de exportación, además, establece que sus 3.592 kilómetros cuadrados de territorio están enmarcados por una gran variedad ecológica y ambiental, menciona también que posee el parque natural de los nevados y señala que es la zona de producción del mejor café del mundo.

El sitio web, además, divide textualmente las características de dicho departamento de la siguiente manera:

● Localización El departamento de Risaralda es una entidad territorial ubicada en el sector central de la región andina, centro occidente de Colombia. Su exposición geográfica está determinada por las coordenadas de sus límites extremos: entre los 5º32´ y 4º39´ de latitud norte y entre 75º23’ y 76º18’ de longitud al oeste del meridiano 0º de Greenwich.

● Extensión El Departamento de Risaralda cuenta con extensión aproximada de 3.592 Km., lo que representa el 0.3% del área total del país, y hace parte del llamado Eje Cafetero.

● Límites El Departamento de Risaralda limita con seis (6) departamentos: Al norte con los departamentos de Antioquia y Caldas, por el Oriente con Caldas y Tolima, por el Sur con el Quindío y Valle del Cauca y por Occidente con Chocó.

● División administrativa El Departamento está dividido en 14 municipios: Pereira como ciudad capital, Apia, Balboa, Belén de Umbría, Dosquebradas, Guática, La Celia, La Virginia, Marsella, Mistrató, Pueblo Rico, Quinchía, Santa Rosa de Cabal y Santuario; 19 corregimientos, numerosos caserío s y centros poblados

● Relieve

24

Está conformado por una zona central de topografía ligeramente ondulada con una altura promedio inferior a los 2.000 msnm. Esta zona está bordeada por las cordilleras Central y Occidental, la Central supera los 4.500 msnm en los Nevados de Santa Isabel y Quindío y la Occidental alcanza en promedio los 4.000 msnm en el Cerro Tatamá; las dos cordilleras están separadas por el cañón del río Cauca.

● Economía Las actividades económicas del departamento son la agricultura, la ganadería, la industria y el comercio. En los productos agrícolas sobresale la producción de café, caña de azúcar, plátano, yuca, cacao, piña, papa, maíz, algodón y algunos frutales. La ganadería tiene propósitos lecheros y de carne. La producción industrial se concentra en los alimentos, las bebidas, los textiles, el papel y carbón. El comercio se localiza principalmente en la capital.

● Hidrografía La red hidrográfica está conformada por los ríos San Juan y Cauca; el primero ocupa el 32% del área, su afluente más importante es el río Tatamá y está constituido por los ríos Guarato, Agüita, Chamí, Río Negro, Mondo y Mistrató. La cuenca del río Cauca ocupa el 68% del área total; sus afluentes principales son los ríos La Vieja, Risaralda, Quinchía, Campoalegre, Otún, Opirama y San Francisco.

● Climatología El clima está influenciado por las masas de aire húmedo sobre la cordillera Occidental y la depresión del río Cauca; esta situación hace que se presenten dos marcadas tendencias, una muy húmeda con tendencia seca, en la vertiente oriental hacia el valle del río Cauca.

Los meses más lluviosos corresponden a abril-mayo, y octubre-noviembre; el promedio de precipitación para el departamento es de 3.000 mm al año. El departamento presenta 5 pisos térmicos desde el valle de los ríos San Juan, Risaralda y Cauca, hasta el nevado de Santa Isabel; el cálido representa el 9% del total departamental, con temperaturas promedio de 24ºC; el templado, entre 18 y 24ºC, representa el 51% el frío, con temperaturas inferiores a 12ºC, ocupa el 8%, y el nevado, que cubre el 1% del área total del departamento. Comparte el parque nacional natural Tatamá con los departamentos de Chocó y Valle del Cauca; y el parque nacional natural de Los Nevados con los departamentos de Caldas, Tolima y Quindío.

● Demografía Según datos preliminares del censo de 2005, su población es de 859.666 habitantes, de los cuales 665.104 corresponden a las cabeceras municipales y 194.562 al sector rural, de los cuales 418.236 son hombre y 441.430 mujeres, agrupados en 231.592 hogares que habitaban 231.780 viviendas.

A pesar de estas virtudes, no es un secreto que es una zona afectada en cierta medida por los fenómenos naturales, en concreto las inundaciones, y es que como

25

se establece en el reporte sobre las áreas afectadas por inundación mencionado en la situación del problema, Risaralda, que es uno de los departamentos más pequeños en hectáreas, se ve afectada el 0,5% de sus 356.035 hectáreas, es decir se ve afectado en 1.711 hectáreas de las cuales 608 son Agropecuarias y 1.103 generales.

Además, de manera más específica, el reporte menciona que en Risaralda resultan 1.868 predios parcialmente afectados y 227 predios totalmente afectados.

2.2.2 Pereira También conocida como "La Ciudad sin Puertas", municipio que pertenece y además es la capital de uno de los departamentos más importantes del país, Risaralda, el cual tiene una posición geográfica y económica privilegiada, ya que se encuentra inmerso en el triángulo de oro (Bogotá, Cali y Medellín), lo cual brinda grandes ventajas económicas, turísticas, laborales, etc.

"La ciudad de Pereira, "La Querendona, Trasnochadora y Morena", es la capital del departamento de Risaralda. Se encuentra ubicada en el centro del triángulo de oro de las tres principales ciudades del país (Bogotá, Cali y Medellín), por lo cual se le ha llamado “la ciudad más cerca de Colombia”” (SINIC).

Dicho municipio se encuentra en la cordillera central, sobre el valle del río del Otún, y parte del valle del río Cauca a 4 grados 49 minutos latitud norte, 75 grados 45 minutos de longitud y 1.411 metros sobre el nivel del mar. Su área municipal corresponde a 702 km2 y limita con los municipios de La Virginia, Marsella, Dosquebradas, Santa Rosa de Cabal y Balboa, además, con los departamentos del Tolima, Quindío, Valle del Cauca.

Pereira posee innumerables atractivos turísticos, lo que la hace ya no solo una ciudad económica y geográficamente privilegiada, sino que a su vez sea una ciudad rica a nivel turístico. "Esta pujante ciudad cuenta con un sinnúmero de atractivos turísticos de gran interés, entre los cuales se puede destacar el zoológico Matecaña, que cuenta con más de 1.200 especies de animales" (SINIC), otros sitios atrayentes de dicho municipio son:

● Edificio Biblioteca Pública Municipal Ramón Correa ● Catedral de Nuestra Señora de la Pobreza ● Viaducto César Gaviria Trujillo ● Parque Metropolitano del Café

Por último, con intención meramente informativa y con el fin de aclarar finalmente la ciudad objetivo, cabe mencionar que la Alcaldía de Pereira en su sitio web, establece una serie de categorías en las que la describe de la siguiente manera:

● Población

26

Consta de 488.839 personas de las cuales 410.535 se encuentran en el área urbana localizadas en 19 comunas y 78.304 en el área rural en 12 corregimientos.

Gentilicio: Pereiranos y Pereiranas

● Geografía El Municipio de Pereira cuenta con pisos térmicos que van desde las nieves perpetuas (Nevado de Santa Isabel a 5.200 mts / snm) en límites con el Departamento del Tolima, hasta pisos cálidos a 900 mts / snm y a orillas del rio Cauca. Por lo tanto, presenta distintas alternativas de uso agrícola. De hecho, existen áreas de bosques para protección de cuencas, zonas de diversificación y medias conocidas como la zona cafetera y zonas cálidas con actividad ganadera y agrícola (piña, caña de azúcar, caña panelera y pasto). La extensión geográfica municipal de Pereira es de 702 km2 y se encuentra a una altura promedio de 1.411 mts /snm y cuenta con una temperatura promedio de 21ºC.

● Clima El suelo de Pereira se distribuye según sus climas así:

Clima cálido el 9.9 %, clima medio el 60.7 %, clima frío el 11.5%, páramo 17.7%, su precipitación media anual es de 2.750 mm.

Esta característica climática y la conformación de los suelos, brinda también una variedad en la cobertura vegetal y paisajística, potencializando el municipio de Pereira con una de las biodiversidades más ricas de la nación. No obstante, la ciudad se presenta como zona de alta vulnerabilidad sísmica por el tipo de suelos que la conforman y por las fallas geológicas que la atraviesan.

2.2.3 Río Consota Una vez se ha contextualizado la ciudad objetivo, se da paso a entender y a establecer la información necesaria y suficiente de la cuenca de la cual se tomará el tramo correspondiente para la implementación del sistema; dicha fuente corresponde al Río Consota, tal como lo expresa Carolina Díaz Giraldo (2007) en su tesis sobre la búsqueda de una metodología disciplinaria con base a dicha cuenca, el río Consota (Pereira – Risaralda), cuenta con una extensión aproximada de 132 Km2 y está ubicado en la zona Andina del territorio Colombiano, el cual cuenta con una posición Geográfica excepcional, suelos y clima aptos para la agricultura además de una riqueza natural, sin embargo, a pesar de dichas virtudes y de algunas más que no se expresan en la Tesis de Giraldo, menciona además que, la función principal de dicha Cuenca en la actualidad es actuar como receptora de aguas residuales de la ciudad, por lo que es un territorio dividido por su sistema hídrico. Se encuentra sometido a una fuerte actividad sísmica y, a características edafológicas, climáticas y topográficas

27

que lo hacen susceptible, particularmente, a los procesos erosivos y a los deslizamientos y demás fenómenos que demandan capacidades y recursos técnicos y económicos para su intervención. Dicha fuente hídrica es una de las más importantes de la ciudad de Pereira, recorre alrededor de 9 km del tramo Urbano albergando 240.000 habitantes aproximadamente, con una estimación de 60.000 viviendas divididas entre 14 comunas y 217 barrios, los cuales están expuestos a diferentes desastres debido a un mal proceso de ubicación y de posicionamiento territorial.

A lo largo del tiempo, como lo mencionan Morales y Barrera (2013) en el plan general que especifica todo lo relacionado al proyecto del que este módulo hace parte, dicha cuenca expresa una serie de problemáticas y situaciones que han puesto en riesgo a habitantes y a sus viviendas, estos altercados son originarios por fenómenos de inestabilidad de las laderas manifestados en deslizamientos, causando represamiento natural de cauces lo cual genera crecimiento e inundaciones en sectores fronterizos, altamente poblados y significativamente vulnerables por su situación socioeconómica y geográfica. A pesar de lo anterior, no se ha establecido un sistema que permita la administración y reducción del riesgo allí presente.

Una contextualización más técnica de la Cuenca exigiría un proceso de investigación profundo, además, de varios procesos matemáticos, por lo tanto, teniendo en cuenta que para este módulo del plan general, dichos datos son de cierta manera irrelevantes y en primera instancia podría no tenerse en cuenta, sin embargo cabe mencionar que, según estudios realizados por el ingeniero civil Juan Pulecio (2008) especialista en ingeniería sanitaria y ambiental en su informe “Modelación hidráulica del río Consota sector “La curva” y “Mercasa – Galicia”, el área de una cuenca es un factor determinante en las crecidas y salidas de cauce de las misma, por lo que se determinó por medio del diseño asistido por computador, que el área del río Consota es de 163.86 Km2, lo cual establece que es una subcuenca (Si bien, a lo largo del documento se ha referenciado como una cuenca, a la hora de expresarla en manera de información es irrelevante si se da a saber cómo una Cuenca o una Subcuenca), esto teniendo en cuenta la clasificación de las cuencas según su área, definida por Henry Jiménez (1986) de la universidad del valle en su aporte “hidrología básica 1”. En donde afirma que a las áreas menores a 5 kilómetros cuadrados son denominadas “unidades”, aquellas áreas entre 5 y 20 km^2 son “Sectores”, las áreas entre 20 y 100 km^2 se denominan “micro cuencas”, las áreas entre 100 y 300 puede denominarse sub cuencas y finalmente las áreas de más de 300 km^2 se denominan cuencas.

El señor Pulecio establece también que el perímetro del río Consota, obtenido por un curvímetro digital pasando alrededor del área de la cuenca , es de 81.18 Km.

28

2.3 MARCO CONCEPTUAL Para el desarrollo integral del proyecto se deben definir, tener claros y relacionados diferentes conceptos que pertenecen a distintas ramas del conocimiento, desde las diferentes técnicas de adquisición y transmisión de datos, pasando por los diferentes estándares o tecnologías a ser potencialmente usadas, hasta la caracterización de elementos en un sistema de almacenamiento de información. A continuación se definirán los conceptos que se consideran más pertinentes para la ejecución del proyecto.

2.3.1 Adquisición y Transmisión de Datos El hombre ha tenido la necesidad de medir todos los fenómenos que lo rodean, por lo que en el transcurso de la historia, se han implementado diferentes maneras de obtener mediciones y datos de alguna circunstancia presentada, debido a esto se han presentado diferentes métodos que permiten esa adquisición y transmisión de información definidas a continuación:

● Manual: Es la adquisición de datos que requiere la presencia de un sujeto encargado de ejecutar la medición con el instrumento a utilizar, en el lugar determinado, en uno o varios instantes de tiempo.

● Semi-automática: El instrumento registra la información en algunos momentos programados, para que después un sujeto encargado se dirija al lugar de instalación del dispositivo a recoger los datos almacenados en una memoria o impresión.

● Automática: El instrumento registra los datos necesarios en los momentos en los que fue programado para hacerlo, y en un momento especificado igualmente, realiza la transmisión de la información ya sea a través de medios guiados o no guiados hacia un sistema de almacenamiento.

2.3.2 Telemetría La telemetría es definida como el sensado y medición de información en alguna locación remota para la posterior transmisión de información a una central o un dispositivo local. De ésta manera se puede monitorear o controlar un proceso en un sitio remoto. La telemetría a menudo se utiliza en conjunto con el telemando (uso remoto de dispositivos actuadores que responden ante las órdenes enviadas por una central), debido a que cuando existen sistemas que se encuentran localizados a

29

largas distancias, es necesario un método que permita obtener información de variables de manera rápida para llevar a cabo una acción.

2.3.3 Sistemas de Telecomunicaciones: Los sistemas de telecomunicaciones pueden ser clasificados según su medio de propagación:

Telecomunicaciones Terrestres: Son aquellas que existen gracias a la implementación de algún tipo de canal físico que conecta el emisor y el receptor, actuando como medio de propagación. Estos medios pueden ser cables de cobre, coaxial, fibra óptica, par trenzado, entre otros.

Telecomunicaciones Radioeléctricas: Son aquellas que utilizan la atmósfera terrestre como medio de propagación, transmitiendo señales en ondas electromagnéticas, ondas de radio, microondas, entre otras, dependiendo de la frecuencia en la que se transmite.

Telecomunicaciones Satelitales: Son aquellas comunicaciones radiales que se realizan entre estaciones espaciales, entre estaciones terrestres con espaciales, o entre estaciones terrestres usando una estación espacial como repetidora para la transmisión de información. Las estaciones espaciales se encuentran a distintas alturas fuera de la atmósfera dependiendo de la órbita en la que se encuentren. Para el desarrollo del proyecto, se considera de importancia profundizar en las Telecomunicaciones Radioeléctricas, debido a que éste será el tipo de comunicación requerido para la implementación.

2.3.4 Comunicaciones Móviles En lugar de depender de electrones moviéndose a través de cables, (a pesar de que requiere energía eléctrica para crear la transmisión), los sistemas inalámbricos hacen uso de ondas de radio. Este único medio de transmisión ha evolucionado mucho desde que Guglielmo Marconi inició con éxito la transmisión inalámbrica del telégrafo en 1895, pero el concepto no ha cambiado. Marconi demostró que las ondas eléctricas se podrían transmitir con éxito a una distancia considerable a través el aire. Jean Antoine Nollet de que ya había observado la transmisión eléctrica sin el uso de cables en el siglo 16. Logró una descarga eléctrica enviando sin hilos conductores, desde una orilla del río Seine a otra, ya que el agua en el río llevó a la carga eléctrica. Desde ese momento la comunicación inalámbrica se ha convertido en el tono febril como el rango y el poder de la tecnología inalámbrica continúa aumentando. “Las ondas radioeléctricas o hercianas permiten establecer una comunicación entre dos estaciones fija, pero, sobre todo, ofrecen la solución ideal para

30

establecer comunicación entre móviles de cualquier tipo, barcos, aviones, satélites, automóviles y peatones, y esto sin importar la distancia entre los interlocutores.”2

2.3.5 GSM En el año 1971 la compañía Bell Telephone presenta una serie de avances en cuanto a la comunicación inalámbrica, entre las cuales se introdujo el término de red celular, la cual utiliza una banda de frecuencias de anchura limitada, debido a que el recurso utilizable del espectro electromagnético se encuentra limitado, llevando así a encontrar mecanismos de optimización del mismo. Una red celular se basa en la división de un territorio, o espacio geográfico en pequeñas partes, las cuales se llaman células. En cada célula se encuentra una estación que constituye el conjunto emisor-receptor de la red correspondiente a las estaciones móviles que se encuentran dentro de los límites del territorio que abarca la célula. Una estación de red ejerce control sobre las frecuencias que tiene asignadas por la red para su célula, e igualmente el conjunto de abonados3 presentes en ella. Cuando un abonado realiza una llamada la estación le determina una frecuencia de emisión, y cuando el abonado se sale del área de cobertura de la célula, ésta pasa a ser controlada por otro emisor y se le asigna una frecuencia diferente a la que tenía en la célula adyacente.

2

TISAL, Joachim. La Red GSM. Madrid, 2000, p.2. 3

Abonado: Cualquier persona física o jurídica que haya celebrado un contrato con un

proveedor de servicios de comunicaciones electrónicas disponibles para el público, para la

prestación de dichos servicios.

31

Arquitectura GSM Como se mencionó anteriormente el concepto básico de una red celular es la división del territorio cubierto por una red en espacios más reducidos llamados células, sin embargo otro concepto primordial en la estructuración de las redes celulares es la asignación de canales de radio entre esas células. En cada célula hay una estación base que cumple la función de emisor-receptor y se encarga de interconectar la red móviles fije con la red básica conmutada de telefonía por hilos.

Figura 3. Arquitectura de una red GSM

Fuente: TISAL, Joachim. La Red GSM. Madrid, 2000, p.20.

Con la implementación de las redes celulares iniciales, se derivaron una serie de retos que a los que los operadores debían responder para poder establecer sólidamente la comunicación, como lo es el poder identificar a cada uno de sus abonados, localizar cada abonado, estimar la dirección de desplazamiento del mismo y mantener la comunicación durante el cambio de una célula a otra. Para dar solución a estas necesidades se implementan diferentes desarrollos, de la siguiente manera:

Para poder identificar a un abonado, el operador utiliza una tarjeta de identificación llamada SIM (Suscriber Identity Module), la cual posee un código de identificación

32

de cada usuario y en la red existe un centro de autenticación (AUC, AUthentication Centre) el cual controla la identidad de un abonado cuando éste enciende su dispositivo móvil.

Para lograr la localización de un abonado en la red, se dispone de una base de datos la cual almacena dinámicamente los registros de abonados locales (HLR, Home Location Register), estos registros hace contienen las referencias y coordenadas de cada abonado local.

Para la estimación de dirección de desplazamiento de un abonado en la red, las estaciones más próximas base miden la potencia que reciben del terminal en cuestión, teniendo en cuenta que cuando un terminal se aleja, la potencia es menor y cuando se acerca es mayor, así determinan la dirección de desplazamiento del dispositivo móvil.

Para mantener la comunicación de un abonado así esté atravesando una frontera entre 2 células, primeramente, la red sincroniza las dos estaciones base involucradas con el terminal, segundo, se verifica que el desplazamiento continúe en la dirección esperada, y finalmente se confirma el traspaso (hand-over, término en inglés) a la célula siguiente. En la comunicación entre una estación base y un terminal móvil, se utilizan dos canales, uno para transportar la información de la estación móvil a la estación base, y otro para el transporte de la información desde la estación base a la móvil. La energía utilizada para lograr ese transporte de una señal de radio entre las estaciones, está directamente relacionada con el cuadrado de la distancia entre los 2 puntos, de ahí viene la necesidad de la implementación de células con tamaños más pequeños, puesto que la distancia entre el emisor y receptor sería menor. El tamaño de una célula se determina por la apreciación de condiciones como el relieve del terreno, la localización, densidad de abonados, intensidad de tráfico esperada, tasa de solicitud de llamadas, naturaleza de edificios, entre otros. Cada célula tiene asignada un conjunto de frecuencias de radio que son las que definen los canales de comunicación, teniendo como condición que las células adyacentes no deben tener canales de comunicación en común, puesto que se generarían interferencias, debido a esto se deja una distancia de mínimo 2 células de separación entre 2 células que utilicen los mismos canales. La estandarización del GSM fue realizada por la ETSI (European Telecomnications Standard Institute) entre 1982 y 1992, finalmente permitiendo los servicios de transmisión y recepción de voz, de datos y envío de mensajes cortos de texto (SMS).

33

2.3.6 GPRS General Packet Radio Service, es una tecnología que subsana las deficiencias de GSM en cuanto a la transmisión de datos, introduciendo una red de conmutación de paquetes que funciona de forma paralela a la conmutación de circuitos de GSM. Con el sistema GPRS, introducido por la ETSI para el sistema GSM, el acceso a la red de paquetes se lleva al nivel del usuario del móvil a través de protocolos como TCP/IP, X.25 y CLNP (Connectionless Network Protocol), sin necesidad de utilizar otro tipo de conexiones intermedias por conmutación, es decir, GPRS aparece como una evolución a la red GSM, sin embargo no requiere modificaciones grandes, y se pueden mantener los equipos de transmisión y la misma interfaz radio que GSM, logrando transmitir datos a mayor velocidad. El servicio GPRS está dirigido a aplicaciones con características como transmisiones poco frecuentes de pequeñas o grandes cantidades de datos y transmisión intermitente de tráfico de datos, y en las aplicaciones que cumplen con estas características se encuentra la telemetría, tele alarma, RTI (Road Traffic Informatics), Controles de tráfico ferroviario, y acceso a la internet.

Protocolo GPRS Es un protocolo de nivel 3, transparente para las entidades de red comprendidas entre el terminal móvil y el nodo SGSN (Serving GPRS Support Node). El protocolo soporta el intercambio de informaciones de control (paquetes PDP-PDU Packet Data Protocol - Protocol Data Unit) entre el nodo al que se encuentra conectado. El formato de trama GPRS está compuesto por un identificador del protocolo GPRS, un identificador del protocolo PDU (PDP) y el mensaje GPRS

Identificador del protocolo: Es una información numérica cuyo objetivo es el de distinguir las ráfagas que contienen paquetes GPRS de las que contienen información GSM.

Identificador del protocolo PDU: Es necesario para direccionar las tramas GPRS hacia el correcto SAP (Service Access Point), cuando son encapsuladas. El identificador (que es tipo numérico) define un valor para los paquetes X25, IP, CLNP, y así sucesivamente con todos los tipos de paquetes existentes.

Mensaje GPRS: Puede contener datos o información de control. Los mensajes son definidos por un valor preestablecido del identificador PDP.

34

2.3.7 Bases de Datos Actualmente el método preferido para el almacenamiento estructurado de datos son las base de datos, teniendo su aplicación desde la grandes aplicaciones multiusuario hasta en los teléfonos o smartphones, buscando asegurar la integridad de los datos y facilitar el desarrollo de software, sin embargo para que el desarrollo de los sistemas de bases de datos existan actualmente, se evidenciaron diferentes avances y se presentaron diferentes necesidades que tuvieron que ser suplidas por con el fin de lograr tener la información más organizada y más segura. En los años sesenta las aplicaciones informáticas se daban por lotes (batch) y estaban pensadas para tareas muy específicas con pocos elementos o entidades. Cada aplicación utilizaba ficheros de movimientos para actualizar, creando siempre una nueva copia, y para consultar ficheros maestros, que normalmente se trataba de sólo un fichero maestro. El hecho de crear un nuevo fichero cada que se le hacía una actualización a una aplicación generaba redundancia. A medida que se fueron implementando las líneas de comunicación, discos, y terminales, se fueron desarrollando aplicaciones más robustas, que permitían a los usuarios consultar los ficheros online, o incluso hacer actualizaciones desde las redes. Las aplicaciones tenían que convivir con otras en un mismo entorno, por lo que la necesidad de interrelacionar sus ficheros fue evidente, para lograr suplir esta necesidad se debía eliminar la redundancia y buscar métodos para tener la información cada vez más unificada sin necesidad de tener datos repetidos en diferentes instancias, evitando así con la pérdida de la integridad de la información. Estos conjuntos de ficheros interrelacionados fueron desarrollados con estructuras complejas y compartían varios procesos de formas simultáneas; recibieron el nombre de Data Banks, posteriormente a los inicios de los años setenta, empezaron a recibir el nombre de Data Bases (Bases de datos). Finalmente, se puede definir una Base de Datos, como la representación integrada de un conjunto de entidades (instancias) interrelacionadas entre ellas.

2.3.8 Sistemas de Gestión de Base de Datos Los primeros SGBD podrían estar referenciados en los años 60, aunque en esa época no eran llamados con tal nombre, estaban orientados a facilitar la utilización de grandes conjuntos de datos en los que las interrelaciones eran completas, manejando un modelo como Bill of materials o Parts explosion, el cual era utilizado comúnmente por las industrias de automóviles o en la construcción de naves espaciales, siendo un sistema que trabajaba únicamente por lotes.

35

Para los años 80, en donde ya había una penetración importante por los ordenadores minis o micros en gran cantidad de empresas e instituciones, resultan bastante complejos los SGBD desarrollados en los 60s y 70s, debido a que ya se exigía que los desarrollos de aplicaciones fueran más sencillos y utilizables por personal no tan cualificado en el área. Allí fue donde se generaron los SGBD relacionales, indicando un avance considerable en la facilitación para la programación con aplicaciones con BD y así conseguir que los programas fueran independientes de los aspectos físicos de la base de datos. Como toda tecnología cuando empieza a ser masificada, entró la necesidad de estandarizar la utilización de estos sistemas, y así fue cómo se logró la estandarización del lenguaje estructurado de consultas SQL en 1986, con su primera publicación realizada por ANSI, y confirmada por la ISO en 1987.

Oracle Es el motor de base de datos relacional más usado a nivel mundial, puede ejecutarse en todas las plataformas, desde un PC hasta un supercomputador. Soporta todas las funciones que se esperan de un servidor robusto: Un lenguaje de diseño de bases de datos completo (PL/SQL) que permite implementar diseños activos, triggers y procedimientos almacenados, con una integridad referencial declarativa potente. Este sistema permite la adición de tipos de clases, referencias, tablas anidadas, matrices y otras estructuras de datos complejas, sin embargo Oracle no es un sistema gratuito y su costo es considerablemente alto.

PostgreSQL Es un sistema de gestión de bases de datos relacionales Open Source (de código abierto), gratuito. Permite el uso de particiones para la mejora de la eficiencia, de replicación e incluso ciertas versiones admiten la administración de bases de datos distribuidas. Soporta los tipos de datos, clausulas, funciones y comandos de tipo estándar SQL92/SQL99 y extendidos propios de PostgreSQL.

Microsoft SQL Server Es un SGBD Relacionales, puede ser útil para manejar y/o obtener datos de Internet, ofreciendo una potente forma de unir SQL e Internet. Utiliza una extensión al SQL estándar, que se denomina Transact SQL que soporta la definición, modificación y eliminación de bases de datos, tablas, atributos, índices, etc.

36

En cuando a seguridad, SQL permite administrar permisos a todo (a nivel de servidor, tablas, lectura, escritura, ejecución) y así gestionar la seguridad de los procedimientos almacenados.

MySQL Es un SGBD Open Source, por lo que es posible ser usado y modificado, y además posee una versión gratuita. Soporta el control de transacciónes en tablas transaccionales (tipo InnoDB), y posee soporte para procedimientos almacenados, subconsultas y disparadores (Triggers) en las últimas versiones de MySQL (5.x). Su servidor de base de datos es muy rápido y fiable de usar.

El Sistema de Gestión de Base de Datos a seleccionar, es una decisión, que por el contexto en el que se desarrolla el proyecto, estará potencialmente influenciada por los sistemas utilizados en las instalaciones de la Universidad Católica de Pereira, y la compatibilidad con los equipos disponibles.

37

CAPÍTULO 3: METODOLOGÍA

3.1 METODOLOGÍA Levantamiento de información: - Realizar indagaciones y consultas con respecto a otros sistemas de medición

(telemáticos) desde sitios remotos. - Consultar sistemas de inalámbricos de transmisión. - Especificar sistemas de almacenamiento de datos existentes en la región y el

mundo. - Definir conceptos básicos de transmisión de información inalámbricos. - Definir conceptos básicos de sistemas de almacenamiento. Conceptualización: - Especificar conceptos principales a ser potencialmente utilizados en el diseño

de la solución de comunicación. - Definir el modelo conceptual de la base de datos. - Realizar Diseño general de la integración del sistema de comunicación y de

datos. - Especificar sistemas compatibles como posibles opciones de implementación. - Seleccionar tecnologías de transmisión a ser potencialmente implementadas

en el desarrollo, especificando ventajas y desventajas de las mismas. - Seleccionar Bases de datos y Sistemas de Gestión a ser potencialmente

implementadas en el desarrollo, especificando pros y contras en la aplicación al contexto.

Elección de Tecnologías: - Realizar Conclusiones del análisis de conceptos y tecnologías. - Definir tecnologías finales a ser implementadas en los procesos de prototipado. - Definir base de datos y sistema de gestión a ser utilizada en la implementación

final, especificando las razones por las cuales sería la más óptima para el sistema.

Diseño de Sistema de Almacenamiento: - Realizar documento de requerimientos para el almacén de datos,

especificando las relaciones que tendrán las entidades y los datos a registrar. - Elaborar diagrama entidad-relación del sistema. - Elaborar diagrama relacional - Elaborar diccionario de datos.

Diseño Técnico del Sistema de Transmisión

38

- Elaborar esquema del circuito, incluyendo dispositivos y conexiones del

sistema de transmisión. - Especificar protocolos a utilizar. - Especificar Dispositivos a implementar. Construcción del Sistema de Almacenamiento: - Instalación de Base de Datos y Sistema de Gestión. - Creación de cuentas de usuario para la gestión y seguridad del mismo. - Creación de tablas (con sus respectivos atributos, claves primarias, claves

foráneas) y relaciones entre tablas. - Inserción de datos de prueba.

Construcción del Sistema de Transmisión: - Familiarización con dispositivos elegidos, analizando la documentación y

configuraciones para cada uno. - Interconectar dispositivos para la creación de los diferentes prototipos. - Manipular drivers y software de control para la obtención de datos en el

sistema. - Realizar pruebas de cada módulo del sistema. Integración del Sistema de Transmisión y de Almacenamiento: - Realización de configuraciones necesarias a ambos sistemas para lograr una

integración transparente. - Integrar ambos sistemas utilizando los protocolos y drivers necesarios. - Realizar pruebas locales de envío inalámbrico de información y

almacenamiento en la base de datos. - Documentar pruebas realizadas especificando los fallos detectados. - Ejecutar correcciones pertinentes a los fallos detectados.

Documentación: - Realizar manuales de implementación. - Integrar la documentación realizada en el transcurso del desarrollo incluyendo

conceptualización, modelos de transmisión, modelos de datos, esquemas técnicos, informes de pruebas e instrucciones de escalabilidad del sistema.

39

3.2 CRONOGRAMA

Tabla 1. Cronograma de Actividades

Actividad Fecha Inicio

Días

Levantamiento de información: 01/01/2014 31

Realizar indagaciones y consultas sistemas de medición telemáticos 01/01/2014

5

Consultar sistemas de inalámbricos de transmisión. 06/01/2014

6

Especificar sistemas de almacenamiento de datos existentes. 12/01/2014

3

Definir conceptos básicos de transmisión inalámbrica 15/01/2014

9

Definir conceptos básicos de sistemas de almacenamiento. 24/01/2014

8

Conceptualización: 01/02/2014 28

Especificar conceptos de la solución de comunicación. 01/02/2014

8

Definir el modelo conceptual de la base de datos. 09/02/2014 7

Realizar Diseño general de la integración 16/02/2014 4

Especificar sistemas compatibles 20/02/2014 4

Seleccionar tecnologías de transmisión candidatas 24/02/2014 4

Seleccionar BDs y SGBDs candidatas 28/02/2014 4

Elección de Tecnologías: 01/03/2014 31

Realizar Conclusiones del análisis 01/03/2014 10

Definir tecnologías finales 11/03/2014 13

Definir BD y SGBD final 24/03/2014 8

Diseño de Sistema de Almacenamiento: 01/04/2014 30

Realizar requerimientos para el almacén de datos 01/04/2014 7

Elaborar diagrama entidad-relación del sistema. 08/04/2014 8

Elaborar diagrama relacional 16/04/2014 8

Elaborar diccionario de datos. 24/04/2014 7

Diseño Técnico del Sistema de Transmisión: 01/05/2014 31

Elaborar esquema del circuito. 01/05/2014 10

Especificar protocolos a utilizar. 11/05/2014 11

Especificar Dispositivos a implementar. 22/05/2014 10

Construcción del Sistema de Almacenamiento: 01/06/2014 30

Instalación de BD y SGBD 01/06/2014 3

Creación de cuentas de usuario. 04/06/2014 3

Creación de tablas y relaciones 07/06/2014 15

40

Inserción de datos de prueba. 22/06/2014 9

Construcción del Sistema de Transmisión: 01/07/2014 31

Familiarización con dispositivos elegidos 01/07/2014 4

Interconectar dispositivos 05/07/2014 27

Manipular drivers y software de control 15/07/2014 16

Realizar pruebas de cada módulo del sistema. 20/07/2014 10

Integración del Sys. de Transmisión y de Almacenamiento: 01/08/2014

100

Realización de configuraciones necesarias 01/08/2014 22

Integrar ambos sistemas 11/08/2014 22

Realizar pruebas locales 11/08/2014 28

Documentar pruebas realizadas 15/08/2014 16

Ejecutar correcciones pertinentes 20/08/2014 12

Documentación: 01/10/2014 15

Realizar especificación de implementación. 01/10/2014 10

Integrar la documentación realizada. 28/10/2014 5

Fuente: Elaboración Propia

41

Figura 4. Diagrama de Grant: Cronograma


31 5

6 3

9 8

28 8

7 4

4 4

4 31

10 13

8 30

7 8

8 7

31 10

11 10

30 3

3 15

9 31

4 27

16 10

100 22

22 28

16 12

20 10

5

01/01/2014 20/02/2014 11/04/2014 31/05/2014 20/07/2014 08/09/2014 28/10/2014

Levantamiento de información:

Consultar sistemas de inalámbricos de transmisión.

Definir conceptos básicos de transmisión inalámbrica

Conceptualización:

Definir el modelo conceptual de la base de datos.

Especificar sistemas compatibles

Seleccionar BDs y SGBDs candidatas

Realizar Conclusiones del análisis

Definir BD y SGBD final

Realizar requerimientos para el almacén de datos

Elaborar diagrama relacional

Diseño Técnico del Sistema de Transmisión:

Especificar protocolos a utilizar.

Construcción del Sistema de Almacenamiento:

Creación de cuentas de usuario.

Inserción de datos de prueba.

Familiarización con dispositivos elegidos

Manipular drivers y software de control

Integración del Sys. de Transmisión y de Almacenamiento:

Integrar ambos sistemas

Documentar pruebas realizadas

Documentación:

Integrar la documentación realizada.

42

3.3 ESTIMACIÓN DE PRESUPUESTO

Tabla 2. Estimación de Presupuesto

Concepto Valor (COP)

Meses (1/2 Tiempo)

Levantamiento de información 1 294.750

Conceptualización 1 294.750

Elección de Tecnologías 1 294.750

Diseño de Sistema de Almacenamiento 1 294.750

Diseño Técnico del Sistema de Transmisión 1 294.750

Construcción del Sistema de Almacenamiento 1 294.750

Construcción del Sistema de Transmisión 1 294.750

Integración del Sys. de Transmisión y de Almacenamiento:

1 294.750

Documentación 1 294.750

Dispositivos 800.000

Software de Integración 1’200.000

Total: 3’747.500

Fuente: Elaboración propia.

43

CAPÍTULO 4: DISEÑO DE LA SOLUCIÓN

4.1 REQUERIMIENTOS

Tabla 3. Requerimiento 1: Módulo de transmisión

Número: 1

Nombre: Módulo de transmisión

Versión: 1.0

Entradas: Diseño de arquitectura de sensado

Salidas: Diseño de integración de arquitectura de sensado con el módulo de transmisión

Descripción: Diseñar una topología hardware que permita la transmisión de datos de un Arduino a una base de datos remota a través de Internet.

Clasificación: Funcional


Tabla 4. Requerimiento 2: Protocolo de transmisión

Número: 2

Nombre: Protocolo de transmisión

Versión: 1.0

Entradas: Diseño de arquitectura de transmisión

Salidas: Definición de protocolos y mecanismos

Descripción: Implementar el protocolo de transmisión por GPRS y definir un diagrama de flujo de información, teniendo en cuenta los posibles mecanismos para transmitir.

Clasificación: No Funcional


44

Tabla 5. Requerimiento 3. Uso de Datos

Número: 3

Nombre: Uso de datos

Versión: 1.0

Entradas: Diseño de arquitectura de transmisión

Definición de protocolos y mecanismos

Salidas: Informe de uso de datos

Descripción: Implementar una herramienta que permita calcular la cantidad de datos necesarios para el funcionamiento del sistema en el transcurso de un mes, para relacionarlo con el servicio que deberá ser contratado por un operador de redes móviles.



Tabla 6. Requerimiento 4: Almacenamiento de Datos

Número: 4

Nombre: Almacenamiento de Datos

Versión: 1.0

Entradas: Descripción de modelo lógico de datos

Salidas: Diagrama entidad relación

Descripción: Diseñar una estructura de datos relacionada en donde se almacene la información de sensado, así como sus relación con el sensor determinado y por consiguiente la ubicación de la misma.

Información de sensado:

Medida de sensado

Fecha y hora

Información de Sensor:

45

Identificador

Referencia

Serial

Propiedad de sensado (Nivel, Flujo, Ph, etc)

Intervalo de Sensado (Tiempo)

Estación (Ubicación)

Identificador

Nombre

Descripción



Tabla 7. Requerimiento 5. Almacenar información transmitida

Número: 5

Nombre: Almacenar información transmitida

Versión: 1.0

Entradas: Información de sensado:

Medida de sensado

Fecha y hora

Identificador del Sensor.

Salidas: Confirmación de almacenamiento

Descripción: Establecer las configuraciones necesarias de tal manera que los datos de cada medición de cada sensado represente un registro (tupla) almacenado en la base de datos del servidor central cada que haya una transmisión.



46

Tabla 8. Requerimiento 6: Actualizar intervalos de sensado

Número: 6

Nombre: Actualización intervalos de sensado

Versión: 1.0

Entradas: Identificador del Sensor

Salidas: Algoritmo

Descripción: Programar el módulo de transmisión actualizar los tiempos de intervalo de sensado tomándolas desde la base de datos cada que haya una transmisión para que los tiempos se conserven actualizados en las estaciones de sensado.



Tabla 9. Requerimiento 7: Tipos de Datos

Número: 7

Nombre: Tipos de Datos

Versión: 1.0

Entradas: Tipos de datos suministrados por la arquitectura de sensado, y tipos de datos necesarios suministrados a la aplicación.

Salidas: Diccionario de Datos

Descripción: Dependiendo de los datos suministrados por la arquitectura de sensado (Cadenas, Valores numéricos, fechas), generar el diccionario de datos para la estructura de la base de datos, teniendo en cuenta la información necesaria a ser almacenada para posteriormente ser utilizada por la aplicación.



47

Tabla 10. Requerimiento 8. Mecanismo de almacenamiento

Número: 8

Nombre: Mecanismo de almacenamiento en Base de Datos

Versión: 1.0

Entradas: Diccionario de Datos

Especificaciones de Servidor de Base de Datos

Salidas: Especificación de mecanismo de almacenamiento

Descripción: Teniendo en cuenta los datos a almacenar, y la integración con el software de administración (plataforma por la cual se gestiona la información), determinar el mecanismo de almacenamiento.



Tabla 11. Requerimiento 9: Cadena de sensado

Número: 9

Nombre: Cadena de sensado

Versión: 1.0

Entradas: Información de sensado

Salidas: Formato de cadena

Descripción: Generar un formato de cadena estándar para todas las mediciones en donde se involucre el identificador del sensor, y el dato de medición del sensor. Generar el formato de cadena de caracteres teniendo en cuenta la posibilidad de agrupar varios datos de un mismo o de varios sensores en una misma cadena y minimizando el uso de los caracteres para optimizar el recurso de datos.

Se realiza con el fin de poder estandarizar el envío de información al servidor.

48



Tabla 12. Requerimiento 10: Aplicación web

Número: 10

Nombre: Aplicación web

Versión: 1.0

Entradas: Diagrama de clases

Salidas: Formato de cadena

Descripción: Realizar una aplicación web en php para el control básico de base de datos del lado del servidor en donde permita realizar el Get de inserción de datos enviados desde la estación de medición y la posterior obtención del intervalo de sensado actualizado, la actualización del estado de sensores, que midan erróneamente o no midan, a “inactivo”, las consultas necesarias para mostrar la información en la integración con la aplicación web, así como la actualización del intervalo de medición desde la aplicación web para el usuario administrador de la misma.



49

4.2 MODELO CONCEPTUAL BASE DE DATOS

Figura 5. Diagrama Entidad Relación


El sistema está integrado por Estaciones de sensado las cuales tendrán un identificador único, un nombre, una ubicación (longitud y latitud) y un intervalo de sensado el cual representa cada cuanto debe realizar el sensado y transmitir al servidor, este intervalo solo es útil para las estaciones denominadas Maestras las cuales son las que tienen la capacidad de transmitir vía internet al servidor de base de datos. Una estación de tipo Maestra puede estar enlazada a varias estaciones Esclavas, las cuales envían sus mediciones a la Maestra para que esta pueda enviarlas al servidor, mientras que una Estación esclava sólo puede estar enlazada con una Estación maestra. Las estaciones pueden tener instalados varios Sensores los cuales tienen un identificador único, un nombre, una referencia y un estado (activo o inactivo), un sensor puede generar Mediciones, las cuales son almacenadas con un identificador único, una fecha y hora, y el valor numérico sensado, estas mediciones están relacionadas a un Propiedad físico-química la cual posee un identificador único, una descripción, la unidad de medición que representa el valor de la propiedad, un valor mínimo y un valor máximo los cuales son utilizados para generar las alertas necesarias en el sistema cuando una medición de determinada propiedad supere no se encuentre dentro del rango que se ha determinado como normal y se pueda informar la anomalía. Cuando una medición se encuentre por fuera de los límites se genera una Alerta con un tipo (se excedió el valor máximo, el valor mínimo, o se estabilizó), con un atributo enviada y normalizada, para tener el registro de cuando la alerta fue

50

enviada a los usuarios, o cuando el valor de dicha alerta ya retornó al rango de los valores permitidos. La propiedad ha sido tenida en cuenta como una entidad aparte debido a que hay algunos sensores que pueden medir diferentes propiedades simultáneamente, por lo cual también se decidió relacionarlo directamente con la medición. Aunque todos los atributos de Alerta podrían estar en la entidad Medición, y aun así se conservaría la integridad de la información, se ha preferido tener la entidad aparte para tener una mejor gestión de las Alertas, para evitar la agregación de más atributos a Medición teniendo en cuenta que no serán útiles para todos sus registros, y que además la entidad Medición poseerá gran cantidad de registros, por lo tanto entre más simple sea la misma más optimizado quedará el almacén de datos.

4.3 MODELO FÍSICO DE LA BASE DE DATOS

Figura 6. Diagrama de Almacenamiento Físico de la Base de Datos


51

4.3.1 DICCIONARIO DE DATOS

Tabla 12. Diccionario Entidad Estación

Entidad: Estación

Descripción: Representa la estación de sensado

Atributo Tipo (Tamaño) Descripción

id INT Identificador numérico de la estación

id_maestra INT Identificador de la estación maestra (Sólo aplica para las Esclavas, las estaciones Maestras almacenan NULL).

nombre VARCHAR(30) Nombre asignado a la Estación

ubicacion VARCHAR(24) Especificación de la ubicación de instalación de la estación. (latitud;longitud)

intervalo INT Específica los minutos de intervalo entre cada medición a ejecutar y transmitir. (Sólo aplica para las Maestras, las estaciones Esclavas almacenan NULL)


Tabla 13. Diccionario Entidad Sensor

Entidad: Sensor

Descripción: Representa el sensor instalado en una estación


id VARCHAR(10) Identificador Único de cada Sensor

id_estacion INT Identificador de la estación en la cual se encuentra instalado el sensor

nombre VARCHAR(30) Nombre del sensor a ser mostrado en la aplicación informativa (Ej. Sensor Temperatura 1, Sensor Caudal 2)

referecia VARCHAR(30) Referencia del sensor

estado VARCHAR(1) Estado del sensor, si se encuentra activo (ha enviado mediciones correctas y en el intervalo determinado) o inactivo (presenta errores en mediciones o no está funcionando). (Posibles valores: A, I)


Tabla 14. Diccionario Entidad Medición

Entidad: Medicion

Descripción: Representa el sensor instalado en una estación


id INT Identificador único de cada Medición

52

id_sensor INT Identificador de la estación en la cual se encuentra instalado el sensor

id_propiedad VARCHAR(20) Identificador propiedad físico-química que representa la medición

fecha_hora DATETIME Fecha

valor DOUBLE valor numérico de la medida


Tabla 15. Diccionario Entidad Propiedad

Entidad: Propiedad

Descripción: Representa la propiedad físico-química a sensar


id VARCHAR(20) Identificador único de cada Propiedad Físico Química (ej. tem, ph, cau)

descripcion VARCHAR(30) Descripción de la propiedad (ej. Temperatura, Ph, Caudal)

unidad VARCHAR(8) Define las unidades de la medida en que se representa la propiedad (ej. C, ph, L/min)


Tabla 16. Diccionario Entidad Alerta

Entidad: Alerta

Descripción: Representa medición con valor fuera de los límites establecidos en la propiedad


id_medicion INT Identificador de la medición

tipo VARCHAR(3) Tipo de la alerta generada, dependiendo del límite que haya pasado y si se ha normalizado la medición (Ej. min, max, nor)

enviada TINYINT(1) Indica si la alerta ha sido enviada o no (1 significa enviada, 0 significa no enviada)

normalizada TINYINT(1) Indica si la alerta ha sido normalizada es decir, si esta es una alerta tipo min o max, y posteriormente se genera otra alerta en donde el valor de este mismo sensor volvió al rango de sus valores normales (especificados en la propiedad). 1 Significa normalizada y 0 significa que no ha sido normalizada. Si una alerta es del tipo ‘nor’ el valor de este atributo siempre será 1.


53

4.4 DISEÑO DE RED

Figura 7. Diagrama de Elementos de Red


El sistema de transmisión se compone de los elementos ilustrados en la Figura 6. El punto A representa una estación esclava del sistema, se compone de un Arduino Mega y una tarjeta Xbee Wifi, el Arduino recopilará y procesará las señales provenientes de los sensores instalados a él, y por medio de la tarjeta Xbee Wifi se comunicará con la estación maestra representada por el punto B. La estación maestra consta de los mismos elementos que la estación esclava, con la diferencia que posee un módulo GPRS para la transmisión de los datos al servidor central a través de la red de un operador móvil. El módulo al tener instalado una sim-card de un operador móvil y un nombre de punto de acceso (APN) configurado correspondiente para dicho operador puede transmitir la información a través del servicio GPRS prestado por la empresa operadora, de esta manera poder acceder a Internet (D) y almacenar las medidas obtenidas por los sensores en el Servidor Central (E) conectado a Internet a través de una IP pública, consta de un servidor web para la recepción de datos, su posterior almacenamiento en el servidor de base de datos, y el envío de la respuesta a la estación maestra (B).

54

Figura 8. Diagrama de Bloques (Transmisión y Almacenamiento)


En la Figura 7 se muestra los diferentes elementos claves en cada bloque involucrado en el sistema de transmisión y almacenamiento planteado. Se inicia con la toma de variables en las estaciones de medición. Las variables tomadas en las estaciones esclavas envían su información por medio de un enlace Wifi gracias a los módulos Xbee Wifi instalados tanto en las estaciones esclavas como en la estación maestra. En la estación maestra son enviados todos los datos de medición recolectados por medio de un enlace GPRS al servidor web a través de un HTTP Request con un método GET en Php, gracias a la implementación del módulo GSM/GPRS Sim900 instalado y configurado en la estación maestra. Una vez se ha recibido la información en el servidor web éste gestiona la inserción de los mismos en el servidor de base de datos a través de sentencias SQL y consulta los tiempos de intervalo de sensado asignados a cada estación con el fin de actualizar dichos tiempos en las estaciones de sensado, la respuesta obtenida por la estación maestra al realizar el HTTP Request se compone de la confirmación de inserción de los datos más los tiempos de intervalo de sensado, para de esta manera lograr una comunicación en ambos sentidos con un mismo método, optimizando el recurso de datos. La respuesta obtenida del método GET es procesada por la estación maestra, actualiza su tiempo de intervalo de sensado, y vía Wifi comparte los intervalos a sus estaciones esclavas para que éstas mismas sean actualizadas.

55

4.5 DISEÑO DEL SOFTWARE SERVIDOR El software al ser desarrollado con una estructura Modelo Vista Controlador, sin embargo, al ser una aplicación enfocada solamente al lado del servidor, la capa de vista no se tendrá en cuenta. Además estará desarrollada bajo el paradigma de Programación Orientada a Objetos, por lo que se proponen el Diagramas de Casos de Uso para plasmar las funcionalidades de la aplicación y actores relacionados con cada una, y el Diagrama de Clases para especificar las clases necesarias para suplir las necesidades de gestión planteadas.

4.5.1 Diagrama de Casos de Uso

Figura 9. Diagrama de Casos de Uso Aplicación Servidor


4.5.2 Diccionario de Casos de Uso

Tabla 17. Caso de Uso 1: Insertar Mediciones

No Caso de Uso: 1

Caso de Uso: Insertar Mediciones

Actores: Estación Maestra, Base de Datos

56

Resumen: La estación maestra envía los datos de sensado a la aplicación maestra para ser insertados en la Base de Datos

Pre condiciones : La cadena de medición debe llegar completa y congruente en el formato determinado.

Post condiciones: La Aplicación debe informar a la Estación Maestra que la inserción se realizó correctamente para que la Estación descarte la cadena.

Flujo principal:

La Estación Maestra envía la cadena completa con todas las mediciones en un formato determinado, para que la aplicación procese la cadena e inserte cada una de las mediciones que contiene, si todas las inserciones fueron exitosas, se informa a la Estación Maestra que el proceso ha sido exitoso.

Sub flujos: Se ejecuta el Caso de Uso 2.

Excepciones: Si hay alguna inconsistencia con la cadena, o algún problema de comunicación con la base de datos, y la inserción no haya sido exitosa se envía el mensaje de error a la Estación Maestra.


Tabla 18. Caso de Uso 2: Reportar Estado Sensor

No Caso de Uso: 2

Caso de Uso: Reportar Estado Sensor

Actores: Base de Datos

Resumen: Se actualiza el estado del sensor de Activo a Inactivo o viceversa, dependiendo de la evaluación de la medición recibida.

Pre condiciones : Se debe evaluar la medición del sensor en el caso de uso 1.

Post condiciones: Se confirma actualización de estado en la Base de datos a la aplicación del servidor.

Flujo principal:

Cuando se encuentra una medición nula o errónea en la cadena de medición se actualiza el estado del Sensor en la Base de datos a “I” (inactivo), o si se recibe una medición válida de un sensor con estado “I” se actualiza a “A” (activo).

Sub flujos: Se obtiene el estado actual del sensor para determinar si la actualización es necesaria o no.


Tabla 19. Caso de Uso 3: Consultar Intervalo de Sensado

No Caso de Uso: 3

Caso de Uso: Consultar Intervalo de Sensado

Actores: Estación Maestra, Aplicación Usuarios, Base de Datos

Resumen: Se consulta en la Base de Datos el Intervalo de Sensado almacenado.

Flujo principal: Se recibe la petición de Intervalo de Sensado actualizado en la Base de Datos para ser enviada a la Estación maestra o a la Aplicación de Usuarios


57

Tabla 20. Caso de Uso 4: Ejecutar Consulta SQL

No Caso de Uso: 4

Caso de Uso: Ejecutar Consulta SQL

Actores: Aplicación usuarios, Base de Datos

Resumen: Se ejecuta la consulta SQL a la Aplicación Servidor para ejecutarla en la y enviar el resultado a la Aplicación Usuarios.

Pre condiciones : La consulta SQL debe ser válida.

Post condiciones: Se confirma que la consulta ha sido exitosa al enviar el resultado.

Flujo principal:

Se recibe una cadena con la consulta SQL enviada por la Aplicación usuarios a la Aplicación Servidor, ésta es validada para confirmar que se la cadena contenga una consulta, y ésta es ejecutada en el Servidor de Base de Datos y se retorna el resultado de la misma a la Aplicación usuarios

Excepciones: Si la cadena no contiene una CONSULTA SQL no se realiza y se envía un mensaje de error.


Tabla 21. Caso de Uso 5: Cambiar Intervalo de Sensado

No Caso de Uso: 5

Caso de Uso: Cambiar Intervalo de Sensado

Actores: Aplicación usuarios, Base de Datos

Resumen: Se actualiza el valor en la base de datos correspondiente al Intervalo de Sensado

Pre condiciones : El valor debe ser un número entero positivo.

Post condiciones: Se confirma a la Aplicación Usuarios que la actualización ha sido exitosa.

Flujo principal: Se recibe un valor de la Aplicación Usuarios correspondiente al Intervalo de Sensado y se actualiza en el campo correspondiente de la Base de Datos.

Sub flujos: -

Excepciones: Si la actualización no fue realizada se informa a la aplicación con un mensaje de error.


58

4.5.3 Diagrama de Clases Debido a las características, tamaño del software y las funciones planteadas en el diagrama de casos de uso, es necesario la implementación de solamente las clases ‘medición’ y ‘estación’ con sus respectivos atributos y métodos especificados a continuación.

Figura 10. Diagrama de Clases Aplicación Servidor


59

CAPÍTULO 5: IMPLEMENTACIÓN DEL DISEÑO

5.1 DISPOSITIVOS PARA LA SOLUCIÓN A continuación se especifican los dispositivos implicados en implementación de la solución y necesarios para el módulo de transmisión, sus características principales e información útil para su manipulación.

5.1.1 DISPOSITIVO DE PROCESAMIENTO: Arduino Mega 2560

Las placas Arduino resultan de vital importancia en el desarrollo del prototipo propuesto debido a su aplicación multidisciplinar, gracias a su precio considerablemente bajo y a sus múltiples características a favor como lo son la arquitectura de su microcontrolador, la cual es multiplataforma en cuestión de desarrollo software y la variedad de elementos electrónicos que son compatibles con esta tecnología se termina definiendo como base fundamental del prototipo solución, para este proyecto se elige placa más reciente de la familia de microcontroladores Arduino.

Figura 11. Arduino Mega 2560

Fuente: http://www.lib.sfu.ca/node/11940

El Arduino Mega 2560 brinda un aspecto primordial para un proyecto que pretende crecer en el tiempo dependiendo de la necesidad que se presente, dicho aspecto es la escalabilidad del sistema mismo, replicar el prototipo sensor resulta considerablemente barato para las múltiples aplicaciones que se le pueden dar y más que eso, al ser escalable la proporción de telemetría puede aumentar mucho más que el mismo sistema prototipo, la obtención de información se podría

60

expandir tanto que no solo se tomarían los datos en el caso de estudio sino en cualquier otra ubicación, así que podría establecerse toda una red de sensores inteligentes que se retroalimentan constantemente y que brindaría una calidad de información mucho más precisa, aparte de esto se puede modificar la configuración del prototipo de manera que se puedan medir más variables fisicoquímicas, esto va ligado a la tecnología que se utilice y a los sensores que se implementen con la tarjeta Arduino.

Esta tarjeta está basada en el microcontrolador ATmega2560, requiere un voltaje para el sistema de 5V, tiene una frecuencia de reloj de 16 Mhz, posee 54 entradas Digitales y 16 entradas analógicas, un puerto y una memoria flash de 32Kb.

5.1.2 DISPOSITIVO DE TRANSMISIÓN: Módulo GSM/GPRS SeedStudio v2.0 Es un módulo Quad-band GSM/GPRS, en un tipo SMT, diseñado con un chip integrando un núcleo AMR926EJ-S. Con una configuración minúscula de 24mm x 24mm x 3mm, ofrece desempeño GSM/GPRS 850/900/1800/1900MHz para voz, SMS, Datos y Fax.

Figura 12. Módulo GSM/GPRS SeedStudio v2.0

Fuente: http://www.seeedstudio.com/wiki/GPRS_Shield_V2.0

Esta versión del módulo cuenta con una cuatribanda (quad-band) GSM/GPRS de bajo consumo de energía, y mejoras en las interfaces, circuito básico y dos opciones para comunicarse con el escudo GPRS, pudiendo comunicarse vía SoftwareSerial o UART.

61

Tabla 22. Especificaciones Generales GSM/GPRS SeeedStudio Shield

Compatible Arduino UNO/Seeeduino directamente; para otras tarjetas con jumpers

Interface Seleccionable UART, Software serial

Soporte Quad Band 850/900/1800/1900MHz

Soporte de Comunicación Standard - GSM 07.07 & 07.05 and Enhanced - SIMCOM AT Commands

Temperatura de Operación

-40°C to +85 °C

Soporte de Protocolos 0710 MUX protocol, embedded TCP/UDP protocol, FTP/HTTP, FOTA, MMS, embedded AT

Certificación de SIM900 CE, IC, FCC, ROHS, PTCRB, GCF, ICASA, REACH, AT&T

Dimensiones 68.58 * 53.34mm

Alimentación 5v via 5V pin, 6.5~12v via Vin pin

Fuente: http://www.seeedstudio.com/wiki/GPRS_Shield_V2.0 Para la manipulación del dispositivo es importante entender el lenguaje en el que expresa el estado del mismo, por lo que esta tabla nos permite evidenciar el significado del estado de los leds que posee.

Tabla 23. Descripción de Estados de Leds GSM/GPRS SeedStudio v2

LED Estado Significado

Led Verde: Indicador de Alimentación

Off Sin alimentación

On Con alimentación

Led Rojo: Indicador de Estado

Off Dispositivo Apagado

On Dispositivo Encendido

Segundo Led Verde: Indicador de Red

Off SIM900 no funciona

64ms On/800ms Off SIM900 no encuentra red

64ms On/3000ms Off SIM900 encuentra la red

64ms On/300ms Off GPRS comunicándose

Fuente: http://www.seeedstudio.com/wiki/GPRS_Shield_V2.0

http://www.seeedstudio.com/wiki/GPRS_Shield_V2.0

62

5.1.3 DISPOSITIVO DE TRANSMICIÓN: Arduino XBEE Pro Shield

Módulo que permite acoplar fácilmente una antena Xbee para poder genera el enlace Wifi integrándolo con una tarjeta Arduino mientras esta es alimentada por el puerto ICSP de la misma, este es un módulo apilable sobre el Arduino Mega 2560 que extiende los pines analógicos (del 0 al 5) y los pines digitales (del 0 al 7). Ver Figura 10.

Figura 13. Arduino Xbee Pro Shield

Fuente: http://www.rapidonline.com/electronic-components/arduino-xbee-shield-w-o-rf-module-73-4469

5.1.4 ANTENA: Xbee Pro 50MW Serie 2 1500M Antena de transmisión y recepción de datos entre módulos de su misma configuración, está antena tiene un alcance de una milla y una configuración de varios módulos de estos dentro de su rango de cobertura permite crear una red mesh o red inalámbrica tipo malla, el montaje de esta tarjeta se facilita gracias al Xbee Shield que es compatible con todas las tarjetas Arduino actuales.

63

Figura 14. Xbee Pro Serie 2

Fuente: http://www.central-

electronic.com/index.php?route=product/product&product_id=206

5.2 CONEXIÓN DE DISPOSITIVOS

El módulo SeeedStudio GPRS Shield v2.0 puede ser instalado insertando el módulo SIM900 encima de Arduino Mega 2560 como se muestra en la Figura 9. Sin embargo no basta con insertarlo, para asegurar una conexión apropiada se realiza un puente entre el pin 7 y pin 10 (cable amarillo) y entre el pin 8 y pin 11 (cable negro), debido a que el Arduino Mega 2560 presenta algunas limitaciones con los pines para la comunicación (recepción y transmisión) 7 y 8, por lo que se enlazan a los pines 10 y 11 y así poder asegurar la comunicación entre la tarjeta Arduino y el módulo GPRS.

64

Figura 15. Integración de SIM900 con Arduino Mega (Apilando)

Fuente: Fotografía propia.

Sin embargo al integrarlo con el módulo Wifi o con el sistema de alimentación solar, puede llegar ser un poco incómodo trabajar con el sistema apilado y para esto también se considera esta según manera de integrar el SIM900 con Arduino mega. Para esto sería necesario conectar los pines de la siguiente manera:

5v y GND (Para alimentación y tierra)

Pin 9 (Para encender o apagar el SIM900)

Pines 7 y 8 en el SIM 900 a los pines 10 y 11 del Arduino Mega correspondientemente.

Es importante recordar que para el funcionamiento del dispositivo es necesaria una SIM Card de tamaño estándar y activa en un operador de redes móviles, igualmente es importante especificar que para la implementación en la solución sólo se utiliza la conexión a Internet, por lo que la SIM Card debe tener el servicio de datos activo con el operador. Teniendo integrado el Arduino Mega con el Módulo GSM/GPRS sólo queda realizar la conexión del módulo Wifi para ya tener todos los componentes relacionados con el sistema de transmisión de datos interconectados. El módulo de Xbee Wifi incluye el Xbee Shield que es el módulo a apilar encima del módulo de GSM/GPRS y posteriormente se debe conectar la Antena Xbee como se muestra en la Figura 10.

65

Figura 16 Integración Arduino Mega, GSM/GPRS Shield, Xbee Shield y Antena Xbee

Fuente: Fotografía propia.

Debido a que el Xbee Shield ocupa el pin 7 en donde se encontraba conectado el jumper del en el GSM/GPRS Shield, éste es trasladado al pin 7 del XBee Shield sin afectar el funcionamiento. La alimentación de todos los dispositivos es brindada por el Arduino Mega 2560 al ser conectada por el puerto serial, que viene integrado, a un puerto USB de computador (Inicialmente se realiza así para la configuración y pruebas iniciales), sin embargo en etapas posteriores del desarrollo se implementa el solar Shield el cual se conecta directamente a los pines ‘5v’ y ‘GND’ de la estructura.

66

5.3 PREPARACIÓN DE ENTORNO DE DESARROLLO Para la implementación del diseño propuesto es necesario desarrollar pequeños proyecto software para la integración del sistema de transmisión con el de almacenamiento, los cuales incluyen la programación del Arduino Mega 2560 para la Estación maestra (la cual incluye el módulo GPRS) con el fin de obtener los datos de sensado de las Estaciones esclavas para posteriormente integrarlos entre sí y con los datos de sensado propios tomados en la Estación maestra. Además de esto es necesario crear un proyecto básico para lograr la gestión de la base de datos necesaria para suplir las necesidades funcionales del sistema general, como lo es la inserción de las mediciones en la base de datos, la consulta y actualización del tiempo de intervalo y la actualización del estado de los sensores al detectar un error en alguna medición. A continuación se enuncian las herramientas software, modelos y tecnologías utilizadas para el desarrollo.

5.3.1 Arduino Software

El software “Arduino” es un ambiente open-source que permite desarrollar “Sketchs” o scripts de código que ejecuta el microcontrolador una vez que este es instalado en el mismo por medio de cable USB, este entorno de desarrollo integrado permite verificar si el código desarrollado está libre de errores o si requiere librerías externas para ejecutar funciones dentro del sketch, también permite configurar el puerto por el cual se conectará el dispositivo Arduino y selecciona también el tipo de placa que se está conectando, una característica adicional es su visualizador de consola serial, donde se pueden observar los datos que envía el microcontrolador y así mismo se le pueden enviar datos para revisar si el sketch desarrollado cumple con la función establecida.

67

Figura 17. Interfaz Principal Arduino Software 1.0.5-r2

Fuente: Captura de pantalla propia.

Arduino Software está disponible para la descarga en el sitio web arduino.cc en sus respectivas versiones para Windows, Mac OS X y Linux.

Al conectar por primera vez el dispositivo Arduino Mega al computador via USB, en el sistema operativo Windows, se intenta instalar como cualquier dispositivo USB pero falla en el intento, por lo que se debe acceder a Administrador de Dispositivos de Windows y en buscar el dispositivo ‘Arduino Mega’ en el apartado de Puertos (COM y LPT), hacer clic derecho sobre él y presionar en ‘Actualizar software de controlador…’, seleccionar la opción “Buscar software de controlador en el equipo’ y finalmente navegar al directorio “C:\Program Files (x86)\Arduino\drivers” y seleccionar el archivo ‘arduino.inf’ y continuar con el proceso de instalación.

68

5.3.2 Lenguaje de Programación Arduino

La plataforma Arduino se procesa mediante un lenguaje propio basado en un lenguaje de programación de alto nivel llamado Processing. Sin embargo es posible utilizar otros lenguajes de programación y aplicaciones populares en Android, debido a que Arduino usa la transmisión serial de datos soportada por la mayoría de los lenguajes de programación, Para los que no soportan el formato serie de forma nativa, es posible utilizar software intermediario que traduzca los mensajes enviados por ambas partes para permitir una comunicación fluida.

Las funciones básicas y los operadores del Lenguaje Arduino están basados en C, soporta algunas funciones del estándar C y otras de C++, Arduino brinda toda la documentación necesaria en lo referente a Sintaxis básica, operadores, cabeceras, estructuras de control, tratamiento de variables, constantes, tipos de datos, conversiones entre tipos, utilidades, manejo de entradas y salidas digitales, analógicas y avanzadas, así como todas las características propias del lenguaje su aplicación al momento de desarrollar.

5.3.3 Sublime Text

Para el desarrollo del aplicativo del lado servidor en PHP para la gestión básica de la base de datos se utiliza el editor de texto Sublime Text 2 al ser un editor sofisticado con diversas funcionalidades que pueden permitir una codificación cómoda y rápida, sin embargo cualquier otro editor de texto compatible con el formato de texto php pudo haber sido utilizado.

Sublime Text es un editor de texto y editor de código fuente escrito, está escrito en C++ y Python. Se distribuye de forma gratuita, sin embargo no es un software libre o de código abierto, se puede adquirir una licencia para su uso ilimitado, pero él no disponer de ésta no genera ninguna limitación más allá de una alerta cada cierto tiempo. Para obtener el software se puede realizar a través de la descarga en su sitio oficial sublimetext.com.

5.3.4 PHP

PHP es un lenguaje de secuencia de comandos del lado del servidor (En este caso es Apache), diseñado propiamente para aplicaciones web, dentro de un sitio web se puede incrustar código PHP que se ejecutará cada vez que se visite la página.

Todo código PHP debe empezar con el símbolo <?php y finalizar con ¿>, es similar a las etiquetas HTML ya que todas empiezan con un símbolo de menor que < y terminan con un símbolo de mayor que > . Estos símbolos se denominan etiquetas PHP que indican al servidor web donde empieza el código PHP y donde termina.

69

Para indicarle al intérprete de PHP que hacer, se introducen instrucciones de PHP entre las etiquetas de cierre y las etiquetas de apertura. En este se desarrollarían los procesos del software, en el mismo con el fin de implementar en la generación del código una arquitectura como lo es MVC (Modelo, Vista, Controlador).

5.3.5 MVC (Modelo, Vista, Controlador)

El MVC es una arquitectura de software que garantiza métodos de soluciones correctos para interacción con otros procesos, y su principal función es que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Es decir el esta arquitectura propone la independencia de procesos para así garantizar el buen funcionamiento y la estabilidad, mantenimiento, independencia; donde se separa la vista del usuario de la parte controladora del sistema y a su vez separa los datos de los anteriores.

Sin embargo como se mencionó anteriormente, para el desarrollo de la aplicación, por su enfoque al servidor únicamente, se ignorará la capa de Vista, y sólo se tendrán en cuenta la capa de Controlador y Modelo.

5.3.6 Programación Orientada a Objetos

“La programación orientada a objetos o POO es un paradigma de programación que está orientado a la utilización de los objetos en sus interacciones, para diseñar aplicaciones y programas informáticos, tratando siempre de incrustar la vida real en el desarrollo de los objetos, es decir, la programación orientado a objetos siempre trata de simular la vida real lo máximo posible, para tener una buena práctica de ejercicios de programación.” (JARAMILLO, CARDONA, HERNANDEZ, 2010).

Está basado en varias técnicas, incluyendo herencia, cohesión, abstracción, polimorfismo, acoplamiento y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe una gran variedad de lenguajes de programación que soportan la orientación a objetos.

“Los objetos son entidades que tienen un determinado estado, comportamiento (método) e identidad o también conocido en el mundo como: el objeto es la instanciación de una clase:

El estado está compuesto de datos o informaciones; serán uno o varios atributos a los que se habrán asignado unos valores concretos (datos).

70

El comportamiento está definido por los métodos o mensajes a los que sabe responder dicho objeto, es decir, qué operaciones se pueden realizar con él.” (JARAMILLO, CARDONA, HERNANDEZ, 2010).

Este paradigma es utilizado para asegurar un entendimiento de la problemática partiendo de los objetos existentes en la vida real y su relación con las necesidades que deben ser satisfechas por el sistema, y además debido a que la creación de las clases necesarias permitirá que se almacenen de manera ordenada los atributos en objetos representativos de una entidad, para posteriormente almacenarlos de manera segura en la base de datos.

5.3.7 Apache

Almacena principalmente documentos HTML (son documentos a modo de archivos con un formato especial para la visualización de páginas web en los navegadores de los clientes), archivos PHP, Javascript, imágenes, videos, texto, presentaciones, y en general todo tipo de información.

Apache es el encargado de tomar el código PHP e inicia el proceso de interpretación de cada uno de los comandos, que están especificados y de allí prepara el funcionamiento según lo que contenga el PHP.

5.3.8 Base de Datos MySQL

“MySQL, es un sistema para la administración de bases de datos relacionales (RDBMS) rápido y sólido. Las bases de datos permiten almacenar, buscar, ordenar y recuperar datos de forma eficiente. El servidor de MySQL controla el acceso a los datos para garantizar el uso simultáneo de varios usuarios, para proporcionar acceso a dichos datos y para asegurarse de que solo obtienen acceso a ellos los usuarios con autorización. Por lo tanto, MySQL es un servidor multiusuario y de subprocesamiento múltiple. Utiliza SQL (del inglés Structured Query Language, Lenguaje de Consulta Estructurado), que es el lenguaje estandar para la consulta de bases de datos utilizado en todo el mundo. MySQL lleva disponible desde 1996 pero su nacimiento se remonta a 1979. Ha obtenido el galardón Choice Award del Linux Journal Readers en varias ocasiones.” (VICENTE, 2014).

Las bases de datos más modernas utilizan SQL. MySQL resulta más sencilla de configurar que otros productos similares, “además se puede utilizar en una gran cantidad de sistemas Unix diferentes, así como bajo Microsoft Windows.

71

5.3.9 phpMyAdmin

phpMyAdmin es una herramienta de software libre escrito en PHP , la intención de manejar la administración de MySQL a través de Internet.phpMyAdmin es compatible con una amplia gama de operaciones en MySQL, MariaDB y llovizna. Utilizado con frecuencia operaciones (gestión de bases de datos, tablas, columnas, relaciones, índices, usuarios, permisos, etc.) se puede realizar a través de la interfaz de usuario, mientras que usted todavía tiene la capacidad de ejecutar directamente cualquier sentencia SQL.

La herramienta viene con una amplia gama de documentación y los usuarios están invitados a actualizar nuestras páginas wiki para compartir ideas y tutoriales para diversas operaciones.

En el proyecto este lenguaje es utilizado para la creación de la aplicación del servidor para la administración básica de la base de datos MySQL, como por ejemplo la inserción de los datos iniciales del sistema para su correcto funcionamiento, más adelante se detallara la configuración necesaria para el sistema.

5.4 DESARROLLO DE SOFTWARE PARA ESTRUCTURA ARDUINO

Al tener la herramienta Arduino Software y los drivers correctamente instalados cómo fue indicado en la preparación del entorno, se procede a realizar un acercamiento al Lenguaje de Programación Arduino y estructurar la lógica de las funciones necesarias para creación de la solución con respecto al diseño planteado.

La estructura lógica del software es la siguiente:

5.4.1 Importación de Librerías y Declaraciones Globales Se importan las librerías necesarias para el funcionamiento del módulo GPRS vía Software Serial, asignando los pines 10 y 11 la comunicación del Arduino Mega 2560 hacia los pines 7 y 8 del módulo GSM/GPRS SeeedStudio v2, se importan igualmente las librerías suministradas por el proyecto encargado del sensado, para obtener las señales de los sensores que se conectarán a la estación Maestra, y se declaran las variables globales necesarias como el identificador de la estación, el intervalo de sensado, asignación de pines de sensores, entre otras. La configuración de la comunicación vía wifi entre las estaciones es suministrada por el proyecto encargado del sensado (remitirse a éste para consultar la configuración de las antenas Xbee), y no necesitan de la importación de librerías ya se utilizan directamente el puerto serial.

72

5.4.2 Configuración inicial de puertos Aquí se hace referencia al método setup() que es comúnmente utilizado en los proyectos Arduino para ejecutar las configuraciones iniciales como por ejemplo la asignación de frecuencias para los puertos seriales, o inicialización de variables globales, en el proyecto se asigna la frecuencia ‘19200’ al serial encargado de la comunicación con el módulo GPRS ya que ésta es la frecuencia recomendada para dicho dispositivo, y para conservar la integridad de frecuencias, se asigna la misma para el puerto Serial para la comunicación wifi. Finalmente Se ejecutan unos retardos necesarios para que los puertos tengan un tiempo prudente para configurarse.

5.4.3 Definición de funciones Para el proceso de sensado, comunicación wifi y envío de datos vía GPRS, se plantearon las siguientes funciones ordenadas de lo específico a lo general para concebir más fácilmente la relación entre ellas:

Tabla 24. Descripción de Funciones Construidas

Función Retorno Descripción

tomarDatos Esclavo()

String Debido a que la recepción de datos del enlace Wifi con las estaciones de medición esclavas se realiza vía Serial estándar, aquí se procesan los datos recibidos vía Serial y por medio de un algoritmo que analiza los caracteres recibidos y la aplicación de un formato a la cadena en donde se identifica el inicio de la transmisión y finalización de la transmisión con un carácter para obtener sólo la información útil y conservar la integridad de la información, finalmente la cadena útil obtenida es retornada.

tomarDatos Sensores()

String Ejecuta las funciones (suministradas por el proyecto encargado del sensado) y lecturas de los pines asignados a cada sensor conectado a la estación Maestra para construir la cadena de sensado incluyendo el identificador del sensor, la propiedad físico-química relacionada y el valor obtenido para cada medición realizada, finalmente concatena y retorna todas las mediciones en un formato determinado.

tomarDatos() String Hace uso de los métodos tomarDatosEsclavo() y tomarDatosSensores() gestionar la toma de datos de los sensores propios de la estación y de las

73

estaciones esclavas asignadas a la maestra. Inicialmente ejecuta el método tomarDatosSensores() para obtener sus datos propios, a continuación envía sucesivamente la orden a cada esclavo para que ejecutar la toma de mediciones y envíen sus datos, es allí cuando se usa el método tomarDatosEsclavo() para leer el puerto Serial relacionado con el enlace Wifi y así obtener los datos de cada esclavo, A medida de que se va recibiendo la información de cada estación se va concatenando todo en una cadena para finalmente retornar la misma.

encenderGPRS() Void Envía unos pulsos específicos (tomados de la documentación del módulo GSM/GPRS SeeedStudio v2) al pin 9 del módulo GPRS para encender el mismo.

apagarGPRS() Void Envía unos pulsos específicos (tomados de la documentación del módulo GSM/GPRS SeeedStudio v2) al pin 9 del módulo GPRS para apagar el mismo.

leerServidor() Void Realiza lectura del puerto serial enlazado con el módulo GPRS para obtener la respuesta del servidor después de haber enviado la información al mismo, se evalúa la información recibida y por medio de un algoritmo que obtiene la información útil recibida (La información útil se encuentra rodeada por los caracteres ‘{‘ y ‘}’), si efectivamente fue recibida la información útil (la cual corresponde al intervalo de sensado actualizado) significa que los datos enviados fueron insertados correctamente y almacena el nuevo intervalo en la variable global definida para esto, si no se ha recibido la información útil se gestionan los procesos para que se vuelva a intentar proceso de envío de la información, si después de 4 intentos no se ha obtenido respuesta, se descarta dicha información.

enviarAlServidor (String datos)

Void Este método gestiona la configuración del módulo GPRS/GSM SeeedStudio v2. Inicialmente se ejecuta el método encenderGPRS(), para proceder al envío de los comandos AT (via serial del GPRS) para la configuración de la red móvil en el dispositivo y poderse ligar al servicio GPRS del operador. Igualmente con la utilización de

74

comandos AT se inicia una conexión HTTP para que por medio de la URL correspondiente al controlador php (método GET) de inserción de datos se le envíe por parámetro la cadena en el formato determinado y se ejecute el método leerServidor() para procesar la respuesta recibida. Finalmente se procede a ejecutar el método apagarGPRS() y se comprueba a través de una variable global gestionada por leerServidor() si se debe a repetir el proceso ejecutado por enviarAlServidor() o no.


75

5.4.4 Estructuración de ciclo infinito En las prácticas comunes de la codificación para Arduino se hace uso del método loop() se ejecuta como un ciclo infinito en donde se definen las actividades y funciones que el dispositivo debe realizar haciendo uso de retardos para controlar el tiempo de intervalo en el que se debe ejecutar dicho ciclo. Para dar respuesta a los requerimientos y diseño planteado para la solución aquí se realiza inicialmente la ejecución del método tomarDatos() para enviárselo por parámetro al método enviarAlServidor() y posteriormente iniciar un delay (retardo) con el tiempo especificado en el sistema como “intervalo de sensado”.

5.4.5 Definición de formato estándar para cadena de transmisión Con el fin de optimizar el recurso buffer Serial en la tarjeta Arduino el cual permite el cual es algo limitado, optimizar el recurso de datos GPRS al enviar un parámetro más corto y con el propósito de que al enviar una cadena vía serial se reciba exactamente lo que se quería enviar, se desarrollaron unas sencillas estructuras de cadena para las siguientes situaciones:

Tabla 25. Estandarización de cadenas para transmisión.

Situación Estructura Ejemplo

Petición de medición y transmisión realizada desde la Estación Maestra a la Estación Esclava.

%Ready+ id_estacion_esclava +&

%Ready2&

Envío de información de sensado vía Serial (Enlaces WIFI)

%+ id_sensor1 +,+ id_propiedad1 +,+ valor1 +|+ id_sensor2 +,+ id_propiedad2 +,+ valor2 +|+ id_sensorN +,+ id_propiedadN +,+ valorN +&

%ST2,tem,27|SH2,hum,59.484|SL2,luz,72.266|SC2,cau,0.000&

Envío de información de sensado vía conexión HTTP (GPRS)

Id_estacion_maestra +:+ id_sensor1 +,+ id_propiedad1 +,+ valor1 +|+ id_sensor2 +,+ id_propiedad2 +,+ valor2 +|+ id_sensorN +,+ id_propiedadN +,+ valorN +

1:ST1,tem,26|SH1,hum,59.487|SL1,luz,68.359|SC1,cau,48.0|ST2,tem,27|SH2,hum,59.484|SL2,luz,72.266|SC2,cau,45.0

Envío de intervalo de sensado actualizado

{+ intervalo +} {10}

76

como respuesta GET en conexión HTTP.


Después de la realización de pruebas de transmisión Serial (WIFI) se consideró importante que todas las cadenas, posean un carácter inicial ‘$’ y un carácter final ‘&’ y para la recepción del intervalo vía Serial (GPRS) un carácter inicial ‘{‘ y un carácter final ‘}’ con el fin de lograr identificar la información útil en las transmisiones realizadas vía Serial así conservar la integridad de la información en este medio. Sin embargo para la información enviada por parámetro a través del GET php no se consideró necesario la aplicación método de identificación de información útil, ya que la información enviada y recibida siempre corresponde en su totalidad a información útil.

5.4.6 Comandos AT para comunicación con módulo GSM/GPRS Los comandos AT son instrucciones codificadas que conforman un lenguaje de comunicación entre el hombre y un terminal modem. Fueron desarrollados en 1977 por Dennis Hayes con el fin de brindar una interfaz de comunicación con un modem para así proporcionarle las instrucciones y configuraciones. Este es el lenguaje que nos permite comunicarnos con el módulo GSM/GPRS para asignarle las configuraciones necesarias de la red dependiendo del operador móvil utilizado, para ligarse al servicio GPRS del operador, y para iniciar la conexión HTTP con el método Get. A continuación se describen los comandos AT utilizados en el desarrollo.

Tabla 26. Comandos AT para transmisión GPRS

Comando Descripción

AT+CGATT? Ligarse al servicio GPRS

AT+SAPBR=3,1,”CONTYPE”,"GPRS”

Portador de configuración GPRS

AT+SAPBR=3,1,"APN","web.vmc.net.co"

Portado de configuración con APN (Nombre de punto de Acceso) del operador móvil a utilizar en este caso el operador es Virgin Mobile Colombia.

AT+SAPBR=1,1 Portador de finalización de configuración

AT+HTTPINIT Se inicia conexión HTTP

AT+HTTPPARA="URL","http://www.sitioweb.com/controller.php?parametro=1:ST2,tem,27|SH2,hum,59.4|SL2,luz,72.2|SC2,cau,48.0"

Se asigna la dirección URL a ejecutar en la conexión HTTP junto con los parámetros a enviar.

77

AT+HTTPACTION=0 Se asigna el valor 0 para indicar que la acción realizada en la conexión HTTP corresponde a un GET

AT+HTTPREAD Lee la respuesta del servidor permitiendo recibir la respuesta de la conexión y la información enviada como respuesta.

AT+HTTPTERM Se finaliza conexión HTTP


5.5 DESARROLLO DE SOFTWARE PARA SERVIDOR Después de tener instaladas has herramientas determinadas en la preparación del entorno en las que se incluye el servidor web Apache, el administrador de base de datos phpMyAdmin, la base de datos MySQL y el editor de texto se pocedió crear los directorios ‘models’ y ‘controllers’ para aplicar el Modelo Vista Controlador (como se dijo anteriormente obviando el componente de Vista ya que no aplica para esta aplicación), en el directorio ‘models’ se almacenan las clases ‘medicion’ y ‘estacion’ con los atributos y métodos especificados en el Diagrama de Clases referenciado previamente en el capítulo 2 ‘Diseño de la Solución’.

5.5.1 Especificación de métodos principales en clases En apoyo a los controladores, para poder generar las soluciones a las necesidades planteadas, se hace uso de los objetos generados a partir de las clases definidas para almacenar en sus atributos la información correspondiente y necesaria para la ejecución de cada proceso y sus métodos para gestionar además de los atributos de la clase, las acciones de inserción, consultas y actualizaciones a la base de datos, por lo que a continuación se detallan los métodos más importantes de cada clase y se describe el flujo principal de los mismos, , es decir que se obvian los métodos de tipo ‘poner’ y ‘tomar’ debido a que sus flujos son elementales.

Tabla 27. Descripción de métodos más importantes de la clase ‘medicion’

Clase: medicion

Método Retorno Descripción

insert() Boolean Inserta en la base de datos una nueva Medición a partir de la información almacenada en sus atributos de clase y retorna ‘true’ si la inserción fue realizada exitosamente y ‘false’ ocurrió lo contrario.

gestionarEstadoSensor Boolean Recibe el estado a ser actualizado en el

78

(estado: String) sensor que corresponde a la medición, se consulta el estado actual del sensor en la base de datos haciendo de uso del atributo ‘id_sensor’ almacenado en la clase medición, y si el estado actual del sensor es diferente al enviado por parámetro, se realiza una actualización de dicho dato en la base de datos, pero si el estado es igual, se descarta la actualización, finalmente se retorna true si la actualización fue realizada exitosamente o false si ocurrió lo contrario.

gestionarAlertas() Void Se realizan las comprobaciones necesarias para saber si una alerta excede el valor máximo, si está por debajo del valor mínimo, o si se ha normalizado después de haber ocurrido una alerta anteriormente, para insertar dicha medición en la tabla Alerta de la base de datos.

alertasEnviadas (propiedad: String, tipo: String)

Boolean Actualiza el atributo “enviada = 1” en la base de datos para las Alertas registradas que tengan el valor “enviada = 0”, y que correspondan con la propiedad y tipo recibidos por parámetro.


79

Tabla 28. Descripción de métodos más importantes de la clase ‘estacion’

Clase: estacion

Método Retorno Descripción

selectIntervalo (int id)

int Obtiene el intervalo de medición almacenado en la estación maestra con el identificador recibido por parámetro, para posteriormente retornarlo.

updateIntervalos (int nuevoIntervalo)

Boolean Se recibe el nuevo intervalo de medición a ser almacenado en la base de datos, y se ejecuta dicha actualización para los registros de todas las estaciones maestras. Finalmente se retorna ‘true’ si la actualización fue exitosa o ‘false’ si ocurrió lo contrario.

Fuente: Elaboración propia

5.5.2 Especificación de Controladores Para ejecutar todas las funciones, crear los objetos, alimentarlos y utilizar de manera congruente los métodos definidos en cada clase se realizó un controlador para cada una de los procesos que dan solución a los requerimientos planteados. A continuación se especifican los controladores y la descripción general de sus procesos.

Tabla 29. Descripción de Controladores

Controlador Descripción

actualizarIntervalo Ejecutado por. Aplicación web usuarios (administradores)

Obtiene por el método Get de php, el parámetro con el valor a almacenar. Crea un objeto de la clase estación, y ejecuta el método ‘updateIntervalos’ enviándole por parámetro el nuevo valor. Finalmente retorna ‘1’ si la actualización fue exitosa o un mensaje de error en caso de que ocurra.

consulta Ejecutado por. Aplicación web usuarios

Recibe por el método Get de php, el parámetro con una cadena que contenga la consulta SQL a realizar a la base de datos. Se evalua la cadena para asegurarse que es una sentencia SELECT, se ejecuta dicha consulta y se retorna la respuesta en formato json.

nuevaMedicion Ejecutado por.

Recibe por el método Get de php, el parámetro con la cadena enviada desde la Estación de medición que contiene el formato especificado, se realiza el

80

Estación Maestra procesamiento de dicha cadena para obtener los datos de cada medición y el identificador de la estación maestra que lo transmite, se realiza la validación de los valores de medición recibidos, y si es necesario se actualiza el estado de los sensores de donde proviene cada medición si es necesario (se inactiva el sensor cuando se reciba el valor ‘n’ en vez del valor numérico de una medición, ya que las estaciones se encuentran programadas, para cuando el sensado de un sensor sea erróneo se envíe ‘n’ para informar el error y se vuelve a activar cuando se reciba una medición válida de dicho sensor), se procede a la inserción en la base de datos, y si ésta es exitosa, se consulta el intervalo de medición almacenado en el registro de la Estación Maestra y se envía como respuesta dicho valor, si no ha sido exitosa se envía un mensaje de error.

traerIntervalo Ejecutado por. Aplicación web usuarios

Crea un objeto de la clase estación y ejecuta el método selectIntervalo(), y retorna el intervalo de sensado almacenado en la base de datos.

Fuente: Elaboración propia

5.6 MEDICIÓN DE CONSUMO DE DATOS

Con ayuda de la herramienta Fiddler Web Debugger, la cual nos permite captar el tráfico HTTP para poder revisar mediante la implementación de intercepción tipo man-in-the-middle. Se pudo evidenciar el tráfico (Bytes enviados y recibidos) al ejecutar el controlador que es utilizado por la Estación Maestra con el fin de enviar las mediciones a la base de datos y recibir actualización del intervalo de sensado. Se ejecutaron diferentes pruebas para observar un tráfico promedio obteniendo los siguientes resultados:

Tabla 30. Consumo de Datos Por Cantidad de Mediciones Enviadas

Mediciones Enviadas por petición

Bytes Enviados

Bytes Recibidos

Consumo Total (Bytes)

2 407 250 657

4 431 250 681

8 515 250 765

16 597 250 847

32 839 250 1089

48 1055 250 1305

81

Fuente: Elaboración propia. En la tabla se refleja el consumo de datos al enviar la petición HTTP GET al servidor con la cadena que contiene las mediciones, se evidencia, cómo al enviar una cadena más grande el consumo de Bytes enviado crece proporcionalmente, sin embargo, el sistema actual envía siempre 8 mediciones (4 de la estación maestra y 4 de la estación esclava) por lo que se toma un valor aproximado de Bytes consumidos por envío de 765. Con este dato podemos calcular el consumo mensual de datos que generaría la implementación del sistema teniendo en cuenta diferentes configuraciones de intervalo de medición.

Tabla 31. Consumo de Datos Estructura de 2 Estaciones

Frecuencia de Medición (min)

Mediciones Diarias

Consumo Diario (KB)

Mediciones Mensuales

Consumo Mensual (MB)

5 288 220.32 8640 6.6

10 144 110.16 4320 3.3

20 72 55.08 2160 1.65

30 48 36.72 1440 1.1

60 24 18.36 720 0.55

120 12 9.18 360 0.27

240 6 4.59 180 0.14

480 3 2.3 90 0.07


En la tabla se evidencia cómo el consumo de datos para este prototipo de 2 estaciones con 4 sensores cada una es considerablemente bajo, debido a que transmitiendo cada 5 minutos, las 24 horas del día se calcula un consumo de 6.6 MB. Sin embargo se considera de importancia calcular el consumo de datos cuando se vaya a instalar el sistema en terreno real con más estaciones. Se toma como ejemplo un sistema con 12 estaciones y 4 sensores conectadas a cada una, lo que significaría 48 mediciones por transmisión y un consumo de 1305 Bytes por transmisión.

Tabla 32. Consumo de Datos Estructura de 12 Estaciones

Frecuencia de Medición (min)

Mediciones Diarias

Consumo Diario (KB)

Mediciones Mensuales

Consumo Mensual (MB)

5 288 375.84 8640 11,28

10 144 187.92 4320 5.64

82

20 72 93.96 2160 2.82

30 48 62.64 1440 1.88

60 24 31.32 720 0.94

120 12 15.66 360 0.47

240 6 7.83 180 0.23

480 3 3.92 90 0.12


Se evidencia como el consumo no aumenta en proporciones muy grandes cuando aumenta la cantidad de información transmitida, ya que se evidencia un consumo tan solo duplicado al escalar a una estructura 6 veces más grande.

83

CONCLUSIONES

El desarrollo de este proyecto al estar enfocado en la transmisión y almacenamiento con enfoques de desarrollo de software en ambos componentes permitió la generación de un prototipo y sistema de almacenamiento aplicando la integración de la Ingeniería del Software con las Telecomunicaciones, teniendo en cuenta las buenas prácticas aprendidas en la Universidad Católica de Pereira para la aplicación de los procesos de Ingeniería.

Se logró realizar un levantamiento de información congruente con las necesidades planteadas para este proyecto, lo cual permitió la elección de tecnologías y protocolos más apropiados para el proyecto teniendo en cuenta su naturaleza, tamaño y posibilidad de escalar con el tiempo, logrando así una selección que permitió apoyar la generación del sistema de almacenamiento y transmisión desde sitios remotos de manera inalámbrica.

El diseño y construcción del sistema de almacenamiento permite una gestión congruente con la realidad de la problemática, identificando las entidades necesarias, los tipos de datos, y las relaciones entre las entidades con el fin de optimizar el almacenamiento y minimizar la redundancia, sin embargo cabe resaltar que el diseño inicialmente planteado cambió considerablemente al enfrentarse con la realidad de la problemática y poder tener en cuenta situaciones que no se había considerado antes, por lo que hubo una retroalimentación constante entre el proceso de desarrollo del prototipo y la estructura de almacenamiento.

El diseño e implementación del sistema de transmisión fue el mayor reto de todos debido a el desconocimiento de la tecnología y los diferentes conceptos, lenguajes, estructuras y teorías que rodeaban a la misma, sin embargo pudo llevarse a cabo exitosamente lo propuesto para el sistema de trasmisión y la integración con el sistema de almacenamiento se logró satisfactoriamente, después de ejecutar las diferentes pruebas en cada módulo y en la integración de ambos módulos.

La realización de este proyecto está relacionada directamente con el desarrollo de otros dos proyectos, uno encargado de la generación del sistema autónomo de medición, y otro del desarrollo del sistema de información web en el que se presenta la información al usuario, por lo que fue necesario una constante comunicación entre los tres proyectos, y al existir una buena estructuración por parte de ambos proyectos, y a pesar de que se presentaron dificultades para obtener los equipos necesarios para la construcción del prototipo la integración de los resultados finales fluyó de una manera adecuada permitiendo así generar un proyecto modular congruente.

84

RECOMENDACIONES

Aunque el prototipo logrado tiene algunas limitantes debido al alcance de los enlaces wifi, y la ausencia de algunos sensores necesarios más acordes para el sensado en fuentes hídricas, se obtuvo una muy buena base para permitir el escalamiento a un sistema más robusto, sin embargo aún deben tenerse diferentes consideraciones para la instalación del prototipo en un terreno real como un diseño apropiado para la protección y gestión de los sensores, por lo que aún quedan retos interesantes para que el proyecto pueda cumplir con todas las metas y ambiciones propuestas, por lo que se recomiendo una continuo esfuerzo por cumplirlas y que el proyecto pueda avanzar hacia unos objetivos de mayor envergadura.

Las fuentes generadas a partir del desarrollo están en su totalidad comentadas, para ofrecer un fácil entendimiento de los procesos planteados como apoyo a las descripciones ya realizadas en el Capítulo 5 de este proyecto por lo que se recomienda familiarizarse con las funciones y la lógica descrita al momento de ser necesaria su actualización.

La adición de sensores o estaciones nuevas implica la generación de nuevos registros en la base de datos para un correcto funcionamiento, por lo que se recomienda tener presente la estructura y tipos de datos planteados en el proyecto.

Todas las especificaciones del sistema que se encuentran contenidas en este proyecto son un apoyo vital para el continuo desarrollo del proyecto, y se recomienda tener en cuenta las diferentes estructuras lógicas y de hardware planteadas para poder agregar las características necesarias al momento de generar nuevas estaciones, o integrar nuevos sensores al sistema.

85

REFERENCIAS

ARDUINO, Language Reference Arduino. Recuperado en Diciembre 15 del 2014.

Disponible en http://arduino.cc/en/pmwiki.php?n=Reference/HomePage BLUEHACK. Comandos AT, Introducción y notación. Recuperado en Enero 2 del

2014. Disponible en http://bluehack.elhacker.net/proyectos/comandosat/comandosat.html

DataRadio - MavDISK. An introduction to telemetry. Minnesota. Recuperado en

noviembre 20 de 2013. Disponible en http://mavdisk.mnsu.edu/alleng/communications/DataRadio/p_telemetry.pdf

ECHARRI, Luis. Ciencias de la Tierra y del Medio Ambiente (libro electrónico). FOROUZAN, Behrouz. Transmisión de Datos y Redes de Comunicaciones. Ed.

McGraw-Hill. España, 2006. HERNÁNDEZ. Marco. Tesis: Instrumentación de un sistema de monitoreo y

transmisión satelital de la precipitación y el nivel del río La Antigua. Universidad Veracruzana. Julio, 2011.

Instituto Nicaragüense de Estudios Territoriales y Agencia Suiza para el Desarrollo

y la Cooperación. Inundaciones Fluviales: Mapas de Amenazas. Managua: Agosto 2005. Recuperado en Octubre 20 del 2013. Disponible en: http://web-geofisica.ineter.gob.ni/proyectos/metalarn/inundaciones.pdf

JARAMILLO, Sonia. CARDONA, Sergio. HERNANDEZ, Leonardo, POO Ediciones

Elizcom, 2010. MIJOVIć, Svetomir. PALMAR, Bojan. Water quality monitoring automation of rivers

in Serbia. Working and Living Environmental Protection Vol. 9, No. 1, 2012. Monitoreo que realiza el Servicio Hidrológico Nacional (SNET) - El Salvador.

Recuperado en octubre 11 de 2013. Disponible en: http://www.snet.gob.sv/Hidrologia/monitoreo.htm

PARÉ, Rafael. CASILLAS, Luis. COSTAL, Dolors. GIBERT, Marc. ESCOFET,

Carme. PÉREZ, Oscar. Software Libre: Bases de Datos. Universidad Abierta de Cataluña. 2005.

ROGERS, Gary. EDWUARDS. Jhon. An Introduction to Wireless Technology.

Prentice Hall. New Jersey. 2006.

http://arduino.cc/en/pmwiki.php?n=Reference/HomePage

http://bluehack.elhacker.net/proyectos/comandosat/comandosat.html

http://web-geofisica.ineter.gob.ni/proyectos/metalarn/inundaciones.pdf

http://www.snet.gob.sv/Hidrologia/monitoreo.htm

86

SCHVARTZMAN, D., SAAVEDRA, J. J., MOLINA, J. A., COHENCA, D., & BARIOS, F. P. (2012). SIitema de comunicacion y transmisión de datos desde estaciones meteorológicas. Revista Iberoamericana de Ingeniería Industrial, 261-278.

SEEEDSTUDIO, GPRS Shield v2 Documentation. Recuperado en Diciembre 18

del 2014. Disponible en http://www.seeedstudio.com/wiki/GPRS_Shield_V2.0

TISAL, Joachim. La Red GSM. Editorial Paraninfo, Madrid. U.S. Department of the Interior y U.S. Geological Survey. Information Sheet:

Streamgages - Measuring the Pulse of our Nation's Rivers. Abril, 2001. VICENTE, Introducción al desarrollo web con PHP y MySQL. Ideyou. Recuperado

en septiembre 18 del 2014. Disponible en http://www.ideyou.com/introduccion-al-desarrollo-web-con-php-y-mysql/2834/

WGAJDOŠ, Viliam. NOVÁK, Petr. Wireless river wáter lever measuring system

(Technické univerzity Ostrava) Revista Gama de Maquinaria (řada strojní): Articulo #1499 - Número 1, 2006, Volumen 52.

http://www.ideyou.com/introduccion-al-desarrollo-web-con-php-y-mysql/2834/

http://www.ideyou.com/introduccion-al-desarrollo-web-con-php-y-mysql/2834/

87

ANEXOS

Anexo A. Reporte de pruebas

Prueba No: 1

Objetivo Probar Arduino Mega 2560 con un código básico de lectura de puerto serial.

Tipo Hardware/Software

Procedimiento Con el Arduino Software y el driver correctamente instalado en el equipo de cómputo se procede a cargar un código básico de lectura de puerto serial

Resultado Esperado

Lectura de datos enviados por el Monitor Serial de Arduino Software.

Resultado Obtenido Los datos enviados via Monitor Serial se visualizan correctamente, la tarjeta Arduino Mega 2560 funciona correctamente.

Prueba No: 2

Objetivo Enviar información al servidor de Ubidots.com haciendo uso de sus códigos de ejemplo para comprobar el correcto funcionamiento del módulo GPRS junto a Arduino.


Procedimiento

Proceder con la inserción en forma de apilamiento del módulo GPRS (con la simcard insertada) encima del Arduino Mega 2560 en los pines correspondientes y proceder a encender el módulo GPRS. Se carga el código ejemplo brindado por Ubidots.com y se inicia Monitor Serial para visualizar el proceso.

Resultado Esperado

La inserción del dato enviado al servidor de Ubidots y la visualización del proceso.

Resultado Obtenido Se comprueba que efectiva el dato ha sido enviado correctamente al servidor, sin embargo no se visualiza el proceso y respuesta del servidor en el Monitor Serial.

Prueba No: 3

Objetivo Probar inserción con controller ‘nuevaMedicion’

88

Tipo Software

Procedimiento A través del navegador web se ejecuta el controller nuevaMedicion.php envíandole un valor por parámetro para evidenciar la inseción en la base de datos, se ejectua nuevaMedicion.php?dato=25.

Resultado Esperado

Inserción exitosa del dato en la base de datos

Resultado Obtenido El query no procesa

Prueba No: 4

Objetivo Probar inserción con controller ‘nuevaMedicion’

Tipo Software

Procedimiento Se ejecuta nuevamente la prueba con el procedimiento de la prueba 3, después de arreglar un error encontrado en el query de inserción.

Resultado Esperado

Inserción exitosa del dato en la base de datos

Resultado Obtenido La inserción ha sido exitosa.

Prueba No: 5

Objetivo Probar inserción con controller ‘traerIntervalo’

Tipo Software

Procedimiento Se ejecuta el controller traerIntervalo desde el navegador y se obtiene la respuesta.

Resultado Esperado

Visualizar el valor corresponiente al intervalo de sensado almacenado en el servidor.

Resultado Obtenido No se obtiene respuesta.

Prueba No: 6

Objetivo Probar inserción con controller ‘traerIntervalo’

Tipo Software

Procedimiento Se ejecuta el mismo proceso que en la prueba 5. Después

89

de haber encontrado un error en la declaración de la clase estación (utilizada para realizar la consulta).

Resultado Esperado

Visualizar el valor corresponiente al intervalo de sensado almacenado en el servidor.

Resultado Obtenido Efectivamente el controller responde con el valor ‘10’ valor por defecto almacenado como intervalo de sensado.

Prueba No: 7

Objetivo Probar inserción con controller ‘consulta’

Tipo Software

Procedimiento Se ejecuta el controller consulta envíandole por parámetro una cadena correspondiente a una consulta SQL para ser ejecutada en la base de datos y obtener la respuesta .

Resultado Esperado

Visualizar la respuesta de la consulta en formato json.

Resultado Obtenido Se obtiene correctamente la respuesta.

Prueba No: 8

Objetivo Probar nueva restricción en controller ‘consulta’

Tipo Software

Procedimiento Para dar un poco de seguridad en este controller se agrega un condicional en donde sólo se ejecuta la sentencia SQL cual ésta empiece por SELECT o select o Select, con el fin de evitar que se ejecute cualquier sentencia en el servidor como un insert, update o delete. Se prueba intentando enviar una sentencia SQL Insert.

Resultado Esperado

Visualizar mensaje “Acción incorrecta”.

Resultado Obtenido Efectivamente se visualiza el mensaje “Accion incorrecta” lo que significa que el condicional creado funciona y sólo se puede utilizar este controlador para ejecutar consultas.

90

Prueba No: 9

Objetivo Ejecutar el controller ‘consulta’ desde la aplicación web usuarios

Tipo Software

Procedimiento El encargado del desarrollo de la aplicación web usuarios ejecuta la consulta desde la aplicación web.

Resultado Esperado

Cargar datos correctamente en la aplicación.

Resultado Obtenido Se evidencian problemáticas cuando se obtiene una cadena que contenga un carácter especial como acentos.

Prueba No: 10

Objetivo Ejecutar el controller ‘consulta’ desde la aplicación web usuarios después de arreglo para caracteres especiales.

Tipo Software

Procedimiento Se agregó una línea al ejecutar los querys en la base de datos desde Php para dar formato utf8 y permitir retornar resultados con caracteres especiales. Se repite el proceso de la prueba 9.

Resultado Esperado

Visualizar correctamente los datos con caracteres especiales.

Resultado Obtenido Efectivamente ya no existe la problemática con caracteres especiales.

Prueba No: 11

Objetivo Probar controlador ‘actualizarIntervalo’

Tipo Software

Procedimiento Se ejecuta el controlador actualizarIntervalo envíandole por parámetro el número 15 para que este sea insertado en el campo correspondiente para intervalo de sensado.

Resultado Esperado

Visualizar en pantalla el número ‘1’ lo que significa que la actualización fue exitosa

91

Resultado Obtenido Se visualiza el número 1, y se verifica en la base de datos. El dato ha sido actualizado.

Prueba No: 12

Objetivo Probar código básico para el envío de comandos AT via serial al módulo GPRS


Procedimiento Se utiliza el código suministrado por la documentación del módulo de SeeedStudio para el envío y prueba de comandos AT para encontrar la configuración necesaria para ejecutar el HTTP Request necesario para enviar los datos desde la Estación Maestra al servidor.

Resultado Esperado

Enviar y recibir respuesta de los comandos AT principales.

Resultado Obtenido No se obtiene respuesta de SIM900

Prueba No: 13

Objetivo Probar código básico para el envío de comandos AT via serial al módulo GPRS


Procedimiento Al no obtener respuesta con el código suminsitrado por la documentación del dispositivo, se encuentran diversos ejemplos que permiten ejecutar los comandos AT desde el Arduino al SIM900, y se prueban todos con diferentes adaptaciones.

Resultado Esperado

Obtener respuesta del Sim900 con alguno de los ejemplos probados

Resultado Obtenido No se obtiene respuesta de SIM900

Prueba No: 14

Objetivo Probar nueva configuración hardware de jumpers entre pines de comunicación

92


Procedimiento Al no obtener respuesta con ninguno de los códigos probados para obtener respuesta del módulo GPRS se averiguó más a fondo sobre los pines utilizados por SIM900 y si eran completamente compatibles con el Arduino Mega, y se encontró que los pines que se usan por defecto en la conexión por apilamiento de estos dos dispositivos puede ser inestable e incompatible, lo cual fue una sorpresa porque ya se había enviado información al servidor de Ubidots. Por lo que se encontró una recomendación de conectar jumpers de los pines utilizados para SoftwareSerial a los pines 10 y 11 que eran más estables, se probó nuevamente el código básico suministrado por la documentación del dispositivo SIM900.

Resultado Esperado

Obtener respuesta del Sim900 con alguno de los ejemplos probados

Resultado Obtenido Finalmente se obtuvo respuesta al enviar los códigos AT al SIM900.

Prueba No: 15

Objetivo Probar configuración para ejecutar el GET a través de conexión TCP


Procedimiento Se logró adaptar el código de Ubidots que utilizaba el método POST para enviar los datos al servidor, pero esta vez para enviarlos al servidor propio con el método GET, se realizaron pruebas de envío de información.

Resultado Esperado

Lograr la inserción de datos enviados desde la estación Maestra al servidor propio.

Resultado Obtenido Se logró exitosamente la inserción de los datos enviados al servidor propio.

Prueba No: 16

Objetivo Probar la obtención de respuesta a través de la ejecución

93

del GET a través de conexión TCP


Procedimiento Con el fin de asegurar una comunicación en ambos sentidos se envía una cadena de respuesta desde el servidor a través del método GET para confirmar que la inserción de datos fue exitosa, se prueba la recepción de dicho mensaje en SIM900

Resultado Esperado

Lograr la recepción del mensaje de confirmación

Resultado Obtenido No se obtiene respuesta desde el servidor, pero los datos si están siendo insertados.

Prueba No: 17

Objetivo Probar la obtención de respuesta a través de la ejecución del GET a través de conexión TCP, después de ajustes al código


Procedimiento Se repitió el proceso de la prueba 14, con diferentes configuraciones de los comandos AT, y ajustes en el código Arduino para obtener la respuesta a través de la conexión TCP realizada para insertar en el servidor.

Resultado Esperado


Resultado Obtenido Aún después de diversos ajustes no se obtiene respuesta desde el servidor, pero los datos si están siendo insertados.

Prueba No: 18

Objetivo Probar una nueva configuración para la ejecución del GET que no involucra conexión TCP, sino una conexión directa HTTP.


Procedimiento Se cambia de configuración para el envío de datos al servidor, esta vez sin utilizar la conexión TCP, sino que se

94

inicia una conexión HTTP, para verificar si de esta manera si es posible recibir el mensaje de confirmación de inserción

Resultado Esperado


Resultado Obtenido Se logra insertar los datos a través de la conexión HTTP y finalmente se recibe la confirmación.

Prueba No: 19

Objetivo Integrar el envío de datos con el sensado en la misma estación


Procedimiento Se integran los códigos Arduino para el envío de datos al servidor propio y la obtención de los datos de los sensores instalados en la misma estación, con el fin de lograr sensar y enviar dicho datos al servidor. (La configuración de sensores y código para la obtención de datos es suministrada por el encargado del proyecto encargado con el sensado)

Resultado Esperado

Insertar en la Base de Datos la información sensada

Resultado Obtenido Se logra exitosamente la integración del sensado y transmisión via GPRS.

Prueba No: 20

Objetivo Integrar la transmisión GPRS con el enlace Wifi


Procedimiento Se integran los códigos Arduino para el envío de datos al servidor propio y la obtención de datos via wifi de la estación esclava (El código de obtención de datos via serial wifi es suministrado por el encargado del proyecto relacionado con los módulos de sensado y estaciones esclavas)

Resultado Insertar en la Base de Datos la información sensada en la

95

Esperado estación esclava y transmitida via wifi

Resultado Obtenido Se logra la obtención de los datos via wifi sin embargo éstos llegan incompletos o repetidos y por el mismo motivo la inserción no es exitosa.

Prueba No: 21

Objetivo Integrar la transmisión GPRS con el enlace Wifi, después de arreglos en la recepción de datos via wifi.


Procedimiento Se implementa un estándar en la cadena enviada via wifi, para limita la información útil con un carácter inicial y un carácter final, y así recibir la información congruente para ser enviada al servidor.

Resultado Esperado

Insertar en la Base de Datos la información sensada en la estación esclava y transmitida via wifi

Resultado Obtenido Se logra obtener la información congruente y completa y la inserción en la base de datos es exitosa.

Prueba No: 22

Objetivo Integrar transmisión GPRS, enlace Wifi y sensado de variables en la estación Maestra


Procedimiento Se integran todos los algoritmos necesarios para ejecutar el sensado de variables en la estación maestra, posteriormente recibir las variables sensadas en la estación esclava, concatenar todas las mediciones y enviarlas vía GPRS al servidor, para recibir la respuesta de confirmación y almacenar el intervalo de sensado actualizado.

Resultado Esperado

Insertar en la Base de Datos la información sensada en la estación esclava y transmitida via wifi, y la obtenida en los sensores propios de la estación maestra

Resultado Obtenido Se logra la inserción correctamente de todos los datos obtenidos en la estación esclava y maestra.

Documents

SISTEMA DE ALMACENAMIENTO Y TRANSMISIÓN DE DATOS …