Control de polución en Smart Cities mediante aplicaciones en FIWARE.pdf

Proyecto Fin de CarreraIngeniera de Telecomunicacin

Formato de Publicacin de la Escuela TcnicaSuperior de Ingeniera

Autor: F. Javier Payn Somet

Tutor: Juan Jos Murillo Fuentes

Dep. Teora de la Seal y ComunicacionesEscuela Tcnica Superior de Ingeniera

Universidad de Sevilla

Sevilla, 2013


Control de polucin en Smart Citiesmediante aplicaciones en FIWARE

Autor: Miguel ngel Cao RojanoTutor: Jos Ramn Cerquides Bueno


Universidad de Sevilla

Sevilla, 2015


Control de polucin en Smart Citiesmediante aplicaciones en FIWARE

Autor:

Miguel ngel Cao Rojano

Tutor:

Jos Ramn Cerquides BuenoProfesor Titular


Universidad de SevillaSevilla, 2015

Proyecto Fin de Carrera: Control de polucin en Smart Citiesmediante aplicaciones en FIWARE

Autor: Miguel ngel Cao RojanoTutor: Jos Ramn Cerquides Bueno

El tribunal nombrado para juzgar el trabajo arriba indicado, compuesto por los siguientes profesores:

Presidente:

Vocal/es:

Secretario:

acuerdan otorgarle la calificacin de:

El Secretario del Tribunal

Fecha:

Agradecimientos

Nunca pens que llegara a escribir estas lneas, pues siempre he sido de creer poco en mi mismo. Encierta ocasin mi hermano pequeo, muy ilusionado, le coment a alguien que su hermano mayor eramuy inteligente y sera ingeniero. Tras los grandes batacazos y masacres acadmicas vividas en primer curso,pens en pedirle que cambiase su visin de la realidad, pero defraudar a las personas que quiero no entra enmis planes, as que continu luchando. Por l.

Esta etapa acadmica est cargada de personas, experiencias y enseanzas, pero lo que realmente ladefine, desde el primer abrazo hasta el ltimo, es el sacrificio. S que mis abuelos sabrn, dondequiera que es-tn, que en esta batalla ellos tambin han sido mis estandartes. Por ellos, por lo que encontr y por lo que perd.

Este apartado no estara completo si no dedicara unas palabras a los dos mejores ingenieros que conozco:mis padres. La persona que soy, resultado de un proyecto de vida que arranc 23 aos atrs, se desarrollsiguiendo fases similares a un proyecto de ingeniera; diseo, anlisis y construccin educacional, y seemplearon herramientas tan rudimentarias (y sin embargo tan eficaces) como el esfuerzo, la entrega, el carioo el tesn. Mis aliados, escudo y espada, y los dos mejores seres humanos que jams conocer.

Dicen que el sufrimiento o el sacrificio se hace ms llevadero cuando es compartido, tambin es culpa demis compaeros que hoy est aqu. Gracias por confiar en m para ser vuestra voz durante aquel tiempo.

A Telefnica I+D, por el soporte y la atencin prestada. A la empresa malaguea TOPdigital, por la cesinde los equipos y su gran acogida en el inicio de mi vida profesional.

Por ltimo, y no por ello menos importante, agradecer a Jos Ramn Cerquides su inestimable apoyo,consejo y profesionalidad. Con su admirable don para la enseanza, desde la distancia he vuelto a sentir lamisma devocin hacia este proyecto que durante aos me demostr en su docencia. Sin duda, uno de losmejores recursos de que dispone esta Escuela.

I

Resumen

Las ciudades se han convertido en una pieza fundamental del desarrollo socioeconmico al concentrarsepoblacin y actividad econmica en los ncleos urbanos. Se prevee que ms del 70% de la poblacinmundial vivir en las ciudades hacia el ao 2050. Este incremento en la concentracin de la poblacin trasladaa las ciudades los paradigmas de sostenibilidad, eficiencia y progreso de la sociedad, propugnando un cambiode modelo bajo el que se enmarca el concepto de Smart City. Este trmino aglutina de forma integrada lasiniciativas y estrategias orientadas a mejorar la calidad de vida, la sostenibilidad y la gestin eficiente de losservicios, innovando en materiales, recursos y modelos usando la tecnologa.

Este proyecto presenta una solucin conceptual en el mbito de la sostenibilidad medioambiental. Medianteun despliegue de una red de sensores y una serie de aplicaciones desarrolladas sobre la plataforma europeaFIWARE, las administraciones pblicas y organismos interesados podrn obtener una caracterizacin de laconcentracin de diferentes tipos de gases que afectan a la polucin atmosfrica. Esta monitorizacin podraconstituir el punto de partida para tomar decisiones en pos de mejorar la calidad del aire en la ciudad.

III

Abstract

Cities have become a cornerstone in socioeconomic development due to the increasing concentration ofpeople in urban areas. More than 70% of people will live in cities in 2050. This increase leads changesin sustainability, efficiency and social progress contextualised under the concept Smart City. This conceptgathers initiatives and strategies focused on improving citizens quality of life, sustainability and efficientmanagement of resources, innovating in materials and models with technology as a tool.

This project presents a conceptual solution in the area of environmental sustainability through a deploymentof a pollution sensors network. These sensors provide readings from different typologies in order to monitorvalues of atmospheric gases. Monitoring, management and alerts are performed using FIWARE, an europeanplatform aimed to deliver cloud services.

V

ndice

Resumen IIIAbstract VIntroduccin 1

1. Fi-Ware 31.1. Contexto actual 3

1.1.1. Las perspectivas del mercado 31.1.2. Fi-Ware como parte del programa FI-PPP 41.1.3. Objetivos del proyecto 41.1.4. reas tcnicas definidas 51.1.5. Fi-Ware Testbed y Fi-Lab 5

1.2. Arquitectura 61.2.1. Arquitectura general de referencia 61.2.2. Especificaciones NGSI en Fi-Ware 61.2.3. Arquitectura en Data/Context Management 81.2.4. Dependencias e interaccin entre GEs 91.2.5. Orion Context Broker 10

2. Eleccin de dispositivos 112.1. Restricciones generales 112.2. Factores involucrados 12

2.2.1. Proteccin ante agentes externos 122.2.2. Comunicacin 13

Protocolos de comunicacin inalmbrica 13Elementos de una red de sensores 14El protocolo ZigBee 15El protocolo Bluetooth Low Energy 16Comparativa final y tecnologa escogida 16

2.2.3. Electrnica interna 17Hardware de fabricante 17Electrnica open source: Arduino 19

2.3. Eleccin final: Waspmote 212.3.1. Core: especificaciones tcnicas 212.3.2. Gas Sensor Board 222.3.3. Libelium Smart Environment 23

2.4. Eleccin del gateway 25

3. Desarrollo del software para dispositivos de la red 273.1. Primeros pasos con Waspmote Smart Environment 27

3.1.1. IDE 273.1.2. Lenguaje de programacin 283.1.3. Calibracin y puesta a punto de los sensores de polucin 29

VII

VIII ndice

Consideraciones generales 29Aspectos clave 30

3.2. Nodos sensores 333.2.1. Comportamiento bsico del sistema 333.2.2. Caractersticas destacables de la implementacin 33

3.3. Gateways 333.3.1. Comportamiento bsico del sistema 33

3.4. Conexin con Fi-Ware y almacenamiento en BBDD 343.4.1. Comportamiento del software 343.4.2. Lenguajes posibles para la implementacin 343.4.3. Interaccin con Orion Context Broker 34

Creando y consultando entidades 35Montando el payload para insercin de dispositivos de la red 37

3.4.4. Insercin de medidas en una base de datos MySQL 38

4. Desarrollo de aplicaciones en Fi-Ware 414.1. Apartados de Fi-Lab 41

4.1.1. Cloud 41Desplegando una instancia propia de Orion Context Broker 41

4.1.2. Mashup 43Creando aplicaciones masivas: wiring 44Creando widgets y operadores 44

4.1.3. Store 454.1.4. Account 454.1.5. Data 46

4.2. Aplicaciones desarrolladas 474.2.1. Mapa 474.2.2. Histrico de lecturas 484.2.3. Inspector de sensores 494.2.4. Alertas y notificaciones 49

Conclusiones 53

Apndice A.Datasheets 55A.1. Algunos sensores de inters: ozono (O3). 56A.2. Algunos sensores de inters: dixido de nitrgeno (NO2). 59A.3. Waspmote 62A.4. XBee modules 65A.5. Modulo GSM/GPRS Waspmote: SIM900 66A.6. Arduino GSM Shield: Quectel M10 68

Apndice B.Cdigo fuente de inters 71

ndice de Figuras 73ndice de Tablas 75Bibliografa 77

Introduccin

Cada da son ms las administraciones y organismos pblicos que se suben al tren Smart City. Si bienno est demasiado claro actualmente qu necesita una ciudad para convertirse en Smart, la pretensinactual es la de mejorar la calidad de vida de los ciudadanos y obtener un mayor control sobre el impactoque ste tiene sobre su hbitat. Con la tecnologa existente, se abre un enorme abanico de posibilidades paragestionar de manera eficiente los recursos de la ciudad. Si bien los conceptos que aparecen resultan novedosos,lo que se persigue no es ms que una evolucin de la ciudad actual hacia su versin parametrizada, tipificaday gestionada por el organismo dedicado al efecto, que tomar decisiones en cuanto a eficiencia y sostenibilidad.

El presente proyecto trata de abordar una de las posibles verticales en que podra dividirse el trminoSmart City, en este caso en el mbito de la sostenibilidad medioambiental. Monitorizar la calidad del airey las concentraciones de un cierto tipo de gas en una zona de la ciudad podra tenerse en cuenta para re-estructurar el trfico o colocar instrumentos para mejorar la calidad del aire. En general, emprender algntipo de iniciativa para mejorar la sostenibilidad de la ciudad. Esta solucin abarca tanto la eleccin de losdispositivos adecuados para caracterizar concentraciones y el modelo de red a establecer como el desarrollode aplicaciones para monitorizacin sobre la plataforma europea Fi-Ware.

Actualmente no se tiene constancia de proyectos similares por lo que, si bien algunas ciudades ya trabajancon este tipo de dispositivos, resulta innovadora la forma en que se ofrece la informacin y la administracinde los sistemas. La plataforma Fi-Ware an se encuentra en estado beta y, si bien existen desarrollos aislados yno demasiado concluyentes, lo cierto es que la infraestructura es mnima, por lo que los desarrollos realizadosdurante este proyecto pueden constituir la base de otros venideros. La principal ventaja que aporta Fi-Ware,en detrimento de plataformas cloud como Amazon Web Services o servicios de Google, es el carcteropen-source de los componentes, el almacenamiento gratuito y la financiacin que se est ofreciendo desdeEuropa, a travs de una red de aceleradoras, para proyectos desarrollados sobre Fi-Ware. Existen plataformaspuramente dedicadas a Internet of Things como Xively, aunque el control y las capacidades que ofrecen sonlimitadas.

Este documento se ha estructurado siguiendo un orden lgico, tratando de aportar conocimiento sobre loque se va a discutir de manera clara, concisa y coherente. Si bien existen infinitas soluciones para implementarel modelo que tenemos en mente, esta solucin se argumenta siguiendo mximas como la minimizacin delcoste de implementacin y la construccin de aplicaciones genricas que puedan ser parte de otras verticales.La estructura en captulos queda reflejada de la siguiente forma:

Captulo 1: Fi-Ware. Se aporta una visin general del proyecto Fi-Ware, abordando el alcance y lasituacin actual. La arquitectura de la plataforma final aparece expuesta aqu y nos detendremos enaquellos componentes que resulten de mayor utilidad a nuestra pretensin.

Captulo 2: Eleccin de dispositivos. Se analizarn las diferentes soluciones del mercado actual,restringiendo la eleccin a especificaciones propias y factores externos.

Captulo 3: Desarrollo del software para dispositivos de la red. Se expone el comportamiento quese espera de los dispositivos a nivel software, tratando la forma en que estos quedan conectados con laplataforma.

1

2 Introduccin

Captulo 4: Desarrollo de aplicaciones en Fi-Ware. Si bien a nivel documental es el de menorextensin, es sin duda el grueso del proyecto. Se presenta la tecnologa en que se programan lasaplicaciones, lo que se pretende conseguir y el resultado final.

Tras esta documentacin se aportan algunas conclusiones y lneas futuras de investigacin a las que podrandar pie este proyecto.

1 Fi-Ware

1.1 Contexto actual

En los ltimos aos, se han podido reconocer ciertas tendencias en el panorama de las TIC que apuntan alcomienzo de una nueva evolucin de Internet. La primera de ellas se identifica en la continua industrializacinde las tecnologas de la informacin en forma de plataformas de cloud computing y de prestacin de serviciosabiertos. Se espera que la naturaleza, hasta ahora bajo demanda y con un cierto coste de estos modelos,cambie la manera en que se proveen las infraestructuras de IT para ser vendidas como un servicio. Por otrolado, la instauracin de nuevas tecnologas de comunicacin inalmbrica como LTE, o la desaparicin de lasredes de cobre en detrimento de las redes FTTH, posibilitar un mayor ancho de banda y capacidad de red,lo cual constituye una excelente va para crear aplicaciones que hagan uso de estas redes y que hasta ahorapodra haber resultado tecnolgicamente inviable construir.

En esta lnea, podra unirse adems la virtualizacin de redes de operadores clsicos y el auge en que seencuentra el llamado Internet de las Cosas (Internet of Things): la visin de conectar dispositivos y sensoresa Internet para ofrecer informacin valiosa acerca del contexto en que se encuentren. El almacenamiento deesta informacin podra dar pie a un posterior anlisis y procesamiento para ofrecer nuevas aplicaciones yservicios de automatizacin de procesos o control en diferentes mbitos.

Las tendencias mencionadas constituyen el caldo de cultivo para lo que se conoce como el Internet delFuturo (Future Internet).

1.1.1 Las perspectivas del mercado

El Internet del Futuro traer consigo el potencial necesario para abrir nuevas vas de negocio y aplicacionesemergentes en materia de salud, telecomunicaciones, e-commerce o e-government. En este sentido, losprincipales actores en este ecosistema poseen algunas demandas clave para que esta nueva tecnologa cumplasus expectativas:

El cliente final pretende consumir las aplicaciones de manera sencilla, estando presentes en su vidacotidiana aportando algn tipo de valor. Asimismo, pretende que se mejoren los medios de comunica-cin, no solo en cuanto a eficiencia o velocidad, sino tambin a nivel de seguridad y privacidad en lared. A esto subyacen problemas como la gestin de datos cada vez mayores y el acceso en cualquiermomento, lugar y dispositivo. Estas nuevas capacidades podran transformar adems las ciudades y laforma en que sus ciudadanos conviven en ellas, convirtindose Internet en una herramienta social ms.

Las empresas y organizaciones buscan estar cerca de sus clientes para ofrecerles un mejor servicio. Porello, obtener informacin acerca de cmo se comportan e interactan en la red podra llevar a ofrecerun servicio ms personalizado y, por tanto, ms eficaz. Esta interaccin podra ser til en alguna delas fases del ciclo de vida de los productos. Los requisitos adicionales que se le exigen al Internet delfuturo en materia de servicios de negocios tienen que ver con la escalabilidad, disponibilidad global yel cumplimiento de los requisitos de los clientes. Una plataforma apropiada contribuira a satisfacerestas demandas.

3

4 Captulo 1. Fi-Ware

Los desarrolladores, integradores y proveedores sern los encargados de crear estas aplicacionesinteligentes que cubrirn las necesidades del usuario. Desde las perspectiva de estos desarrolladores,las aplicaciones y servicios deben: estar basadas en estndares y lenguajes conocidos; disponer deAPIs abiertas y frameworks que faciliten un desarrollo potente y flexible, sin atarse a un determinadodistribuidor; facilitar medios para administracin y distribuir la utilidad a mltiples usuarios.

1.1.2 Fi-Ware como parte del programa FI-PPP

El proyecto Fi-Ware consiste en el diseo y desarrollo de una plataforma (Core Platform) para el Internet delFuturo. Est enmarcado en el programa FI-PPP 1 (European Future Internet Public Private Partnership),cuyo objetivo es mejorar la competitividad de Europa en estas tecnologas y apoyar nuevas aplicaciones yservicios emergentes. Un acercamiento a este programa se encuentra en la imagen, donde se muestra cmodiferentes socios del proyecto colaboran para generar nuevos requerimientos para el proyecto, necesariospara poder desplegar su tecnologa u ofrecer su servicio a travs de Fi-Ware. Esta plataforma debera tratar decumplir en la medida de lo posible estos requerimientos.

Figura 1.1 El programa FI-PPP.

1.1.3 Objetivos del proyecto

El principal, y por el cual Fi-Ware hoy en da es una realidad, es la creacin de la plataforma mencionada parael Internet del Futuro. Mediante esta plataforma se pretende incrementar la competitividad de la economaeuropea basada en las TIC a travs de la introduccin de una infraestructura para la creacin y entrega deservicios digitales, contando con una alta calidad de servicio y garantas de seguridad. Esto es, proporcionaruna base slida sobre la que construir un ecosistema sostenible para los proveedores de servicios innovadoresy los consumidores finales, los cuales participarn activamente en el contenido, la creacin y la consumicindel servicio.

La plataforma, a la que denominaremos Fi-Ware Platform, o simplemente Fi-Ware, es abierta y libre deroyalties y est basada en Generic Enablers oGEs que estn presentes en mltiples de reas de uso y ofrecenfunciones reutilizables. Un GE es un conjunto de funciones de la plataforma, de propsito general y que seencuentran disponibles a travs de APIs. Por tanto, uno de los objetivos principales del proyecto Fi-Wareser identificar y especificar estos GEs, junto con desarrollar implementaciones de ellos. Cualquiera de estasimplementaciones comprende un conjunto de componentes y ofrece una serie de funcionalidades que puedenser utilizadas, combinadas y personalizadas para un rea concreta.

1 Puede encontrarse ms informacin en http://www.fi-ppp.eu/

1.1 Contexto actual 5

1.1.4 reas tcnicas definidas

La plataforma Fi-Ware, por tanto, est basada en GEs enmarcados en alguno de las siguientes reas o captulostcnicos:

Cloud hosting. Capa que provee almacenamiento, computacin y recursos de red, y sobre la que losservicios pueden ser administrados y servidos.

Anlisis y administracin de datos de contexto. Capacidad para procesar, analizar y acceder al bigdata que podr constituir informacin valiosa a consumir por las aplicaciones.

Ecosistema de aplicaciones y servicios. Infraestructura para crear, administrar y consumir nuevosservicios a lo largo de su ciclo de vida.

Interfaz para redes y dispositivos (I2ND). Define un espacio que facilite el proporcionar habilitadoresgenricos para conseguir una infraestructura de red abierta y estandarizada.

Habilitadores para Internet of Things. Constitucin del puente entre los dispositivos conectados yla plataforma.

Seguridad. Mecanismos que aseguran que la entrega y el uso de los servicios cumplan las especifica-ciones en materia de seguridad.

Para ilustrar el concepto de GE podemos nombrar algunos que fueron identificados inicialmente comovinculados al captulo de anlisis y administracin de datos de contexto: algn tipo de GE que permitala recopilacin y almacenamiento de datos masivos que provienen de diferentes fuentes. Este GE puedeestar basado, a su vez, en una serie de ellos. La naturaleza abierta de estos GEs permite reemplazar unaimplementacin concreta en Fi-Ware dentro de una instancia particular desplegada para amoldarse a laaplicacin concreta.

Figura 1.2 Uso de GEs en instancias Fi-Ware.

1.1.5 Fi-Ware Testbed y Fi-Lab

El proyecto Fi-Ware despleg, inicialmente, una instancia susceptible de ser utilizada por los socios menciona-dos en el programa FI-PPP. La llamada Fi-Ware Testbed se utiliz para probar y ejecutar nuevas aplicacionesde Internet basadas en GEs de Fi-Ware. Un banco de pruebas funcional que se acercara a la idea inicialmentepropuesta.

Adems de este banco de pruebas, posteriormente se despliega una instancia para creacin de aplicacionesde naturaleza abierta para estimular el conocimiento de los proveedores y desarrolladores sobre la plataforma,de manera que estos se sintiesen atrados a participar y construir una comunidad de usuarios. A este nuevobanco de pruebas se le denomina Fi-Lab.


1.2 Arquitectura

1.2.1 Arquitectura general de referencia

En el captulo anterior introducamos las principales reas tcnicas en las que se enmarcan los GEs deFi-Ware. La arquitectura de referencia est ligada a cada una de estas reas de aplicacin por lo que, si bienintroduciremos una visin de la arquitectura general, no profundizaremos en cada una para no extenderinnecesariamente el alcance de este documento. El siguiente diagrama muestra la mayora de los componentes(GEs) y actores implicados en la plataforma, as como las reas a las que pertenecen.

Figura 1.3 Visin general de la arquitectura de Fi-Ware.

En el catlogo actual de Fi-Ware2 podemos encontrar implementaciones de los GEs disponibles parainstanciar, por ejemplo, en Fi-Lab, adems de la documentacin necesaria para su uso. Es este el momentoadecuado, teniendo en cuenta la naturaleza del presente proyecto, para presentar y ahondar en aquellosGEs que nos sern de mayor utilidad. Centraremos nuestra atencin en los que provean funcionalidadesen el mbito de Internet of Things. En este sentido, los GEs enmarcados en el captulo de Data/ContextManagement facilitan el desarrollo de aplicaciones que requieren recopilar y procesar grandes cantidades deinformacin en tiempo real procedentes de los usuarios finales.

1.2.2 Especificaciones NGSI en Fi-Ware

NGSI es un estndar para administracin de contexto definido por el OMA (Open Mobile Alliance). Esteestndar define dos interfaces: para intercambio de informacin sobre entidades y sus atributos (OMANGSI-10) y para disponibilidad de la informacin de estas entidades (OMA NGSI-9). En esta ltima lo quese intercambia es informacin acerca del proveedor de la informacin de la entidad, no de sta como tal.

2 http:// catalogue.fi-ware.org/ enablers

1.2 Arquitectura 7

Figura 1.4 Recursos de NGSI.

En Fi-Ware se realizan implementaciones propias del estndar NGSI: APIs RESTful va HTTP cuyopropsito es intercambiar informacin de contexto. Las diferencias con el estndar son mnimas, por loque las trataremos como meras implementaciones de ste. Los tres principales tipos de interacciones conestas APIs son: consultas, suscripciones y actualizaciones del contexto (invocadas por los proveedores deinformacin).

En el ejemplo que se presenta a continuacin, tienen lugar dos tipos de interacciones NGSI: updateContexty queryContext. En este caso, se presenta una aplicacin que recoge a tiempo real la velocidad instantneade un vehculo y la muestra a travs de una aplicacin mvil. El Context Broker, del que hablaremos msadelante, resulta ser el intermediario entre el Context Producer (velocmetro) y el Context Consumer (mvil).

Figura 1.5 Ejemplo de uso: velocmetro a tiempo real en app mvil.

En Fi-Ware, estas operaciones NGSI son invocadas a travs de un mtodo POST de HTTP, por lo que loselementos finales (Context Producer y Context Consumer) deben poseer conexin a Internet para ejecutarestas llamadas, o existir otro sistema que las realice por ellos. Resultar de aplicacin esta operativa en el


presente proyecto, por lo que en captulos posteriores tendremos oportunidad de comprobar cmo se comportacon mayor profundidad.

1.2.3 Arquitectura en Data/Context Management

Los GEs pertenecientes a esta parte de la arquitectura de Fi-Ware permiten:

Generar, notificar, suscribirse o consultar cierta informacin de contexto proveniente de diferentesfuentes. Un ejemplo de informacin de contexto lo constituyen las lecturas peridicas de temperaturade un sensor emplazado en un lugar particular.

Actuar sobre el contexto en base a informacin recogida que pueda disparar un cierto evento.

Procesar metadatos que utilicen una semntica estandarizada referidos a una cierta informacincontextual.

Tratar grandes cantidades de informacin de manera agregada utilizando tcnicas de Big Data Map &Reduce, con el objetivo de generar nuevo conocimiento.

A continuacin se muestran los principales GEs en el captulo de Data/Context Management.

Figura 1.6 Visin general de la arquitectura del Data/Context Management.

Un concepto clave en esta arquitectura es la definicin de la estructura de los datos del contexto. Estadefinicin est basada en el estndar NGSI anteriormente mencionado por lo que, si bien se aportan algunasnociones de los conceptos, podra encontrarse mayor informacin en el propio estndar.

Un data element es un paquete de informacin que es producida o recogida y que puede ser relevanteanalizar para obtener un nuevo conocimiento. Consiste en una secuencia de una o ms tripletas referidas a diferentes atributos de este elemento. Puede existir adems metadata ligado a alguno deestos atributos. Los data element podran poseer un identificador para hacer ms sencilla su inclusin en unalmacn (tpicamente una base de datos). Este identificador no se considera parte de la estructura.

1.2 Arquitectura 9

Figura 1.7 Estructura de un data element.

Por otro lado, en Fi-Ware se define el contexto y los elementos del contexto (context elements), quevienen a extender el concepto de data elements asociandole un EntityId y un EntityType que identificanunvocamente la entidad (que en realidad podra referirse, a su vez, a un grupo de entidades).

Figura 1.8 Estructura de un context element.

Los eventos se definen como acontecimientos en un contexto particular. Estos eventos disparan algn tipode accin particular que deba llevarse a cabo.

Un ejemplo clarificador acerca de estas definiciones lo constituye un cierto dispositivo que, peridicamente,provea lecturas de algn parmetro medible en una habitacin como, por ejemplo, temperatura y humedadrelativa. En este dominio, el elemento de contexto sera el sensor y el contexto el lugar y las condicionesambientales en que se encuentra. Podra considerarse como evento un cambio en alguno de los parmetrosmedibles, desencadenando ste, por ejemplo, una orden para reducir o aumentar la temperatura de unclimatizador presente en el habitculo.

1.2.4 Dependencias e interaccin entre GEs

Si bien los GEs siguientes se presentan enmarcados dentro del rea de Data/Context Management, lo ciertoes que son completamente modulares y pueden encontrarse en otras reas de Fi-Ware. Todos estn basadosen APIs NGSI y, como puede observarse, el ncleo de esta arquitectura (fuente y sumidero de diferentessolicitudes NGSI de los GEs) es el Context Broker.

El principio fundamental en el que se basa este Context Broker es conseguir desacoplar a los productoresde los consumidores de informacin de contexto. De esta forma, los productores podrn publicar informacinde contexto a placer y los consumidores hacer uso de ella cuando les interese. Este Context broker debe sercapaz, por tanto, de almacenar la informacin de contexto de manera que pueda ser consumida en cualquiermomento.


Figura 1.9 Integracin NGSI para Data/Context Management.

1.2.5 Orion Context Broker

Orion Context Broker, en adelante OCB, es una implementacin en Fi-Ware del Context Broker mencionadocon persistencia de datos de contexto en una base de datos MongoDB. Viene a cubrir dos roles principales enla declaracin de GEs de Fi-Ware: Publish/Suscribe Context Broker GE y Configuration Management GE,siguiendo y construyendo una implementacin propia del estndar OMA NGSI 9/10.

Figura 1.10 Interacciones tpicas a travs del Context Broker.

Mediante esta implementacin del Context Broker se pueden realizar diversas operaciones de contexto,tales como registrar lecturas de humedad relativa en un rea de una ciudad, obtener notificaciones cuandoesta humedad se ve modificada o guardar dicha informacin para un anlisis posterior. En el caso que nosocupa, OCB es el componente que nos facilitar ofrecer la informacin de los sensores a las aplicaciones,constituyendo el intermediario entre el back-end y el front-end que desplegaremos en Fi-Lab.

2 Eleccin de dispositivos

2.1 Restricciones generales

Para la eleccin de los dispositivos necesarios se ha de tener muy en cuenta el emplazamiento final en el quese desplegarn. El objetivo principal es instalar sensrica para control de polucin en una ciudad por lo que, sibien constituyen un pilar fundamental las caractersticas tcnicas y de implementacin que impongamos, estopodra quedar relegado a un segundo plano en el momento en que la vida til y autonoma del dispositivo puedaverse reducida, teniendo en cuenta las posibles condiciones meteorolgicas a las que estar expuesto el equipo.

Si bien a lo largo de este apartado podrn aparecer nuevas condiciones a exigir para equilibrar la balanza encuanto a especificaciones satisfechas/precio, definiremos algunas bsicas que fijarn un rango de dispositivos,de manera que podamos estrechar el cerco y realicemos una eleccin mucho ms precisa y adecuada.

Los dispositivos se desplegarn en un emplazamiento exterior, tipo urbano. Esto obliga a que debanestar protegidos ante los diferentes agentes meteorolgicos, tpicamente lluvia, temperaturas extremaso cualquier otro que pudiese afectar al correcto funcionamiento de la electrnica interna. Constituyeesta la principal restriccin de diseo.

Un bajo coste permitira desplegar un mayor nmero de dispositivos. Si existe un gran nmero denodos en las zonas donde se despliegan podra realizarse una traza mucho ms precisa del nivel depolucin presente.

Los sensores deben funcionar sin necesidad de estar conectados a una fuente de alimentacin, porlo que el consumo debe ser bajo para alargar la vida til de las bateras. Como aadido a este caso,podran colocarse pequeos paneles solares para aportar energa adicional si necesitsemos un granaporte.

Conectividad a Internet para monitorizacin y envo de lecturas peridicamente. De esta forma podre-mos aprovechar este data mining con efecto de analizar y extraer informacin til.

Trataremos entonces de aportar las soluciones presentes en el mercado que puedan ajustarse lo mximoposible a las restricciones impuestas.

11

12 Captulo 2. Eleccin de dispositivos

2.2 Factores involucrados

2.2.1 Proteccin ante agentes externos

Una de las caractersticas que define el mbito de utilizacin de un cierto equipo electrnico hoy en da,es su grado de proteccin IP. Este grado de proteccin IP especifica un sistema de clasificacin de loscontenedores que protegen la electrnica interna (estndar ANSI/IEC 60529-2004), referenciado por dosletras y dos dgitos (IPxx). IP hace referencia a International Protection y los dgitos clasifican el nivel deproteccin ante entrada de objetos slidos y ante entrada de agua, definindose un rango de 1 a 6 para elprimero y 1 a 8 para el segundo. Para obtener esta certificacin se deben cumplir las condiciones recogidasen las siguientes tablas:

Tabla 2.1 Grado de proteccin IP: primer dgito.

Dgito Tamao del objeto entrante Proteccin ante0 - No protegido1

2.2 Factores involucrados 13

Tabla 2.2 Grado de proteccin IP: segundo dgito.

Dgito Proteccin ante Lugar de prueba Resultados1 Goteo de agua Emplazamiento similar al de

despliegue.No debe entrar el agua cuando se la deja caer, desde200 mm de altura respecto del equipo, durante 10minutos (a razn de 3-5 mm3 por minuto)

2 Goteo de agua Emplazamiento similar al dedespliegue.

Idntica a la anterior, realizada cuatro veces desdediferentes ngulos

3 Agua en spray Emplazamiento similar al dedespliegue.

No debe entrar el agua nebulizada en un ngulo dehasta 60 a derecha e izquierda de la vertical a unpromedio de 11 litros por minuto y a una presinde 80-100kN/m2 durante un tiempo no menor a 5minutos.

4 Chorros de agua Emplazamiento similar al dedespliegue.

No debe entrar el agua arrojada a chorro (desdecualquier ngulo) por medio de una boquilla de6,3 mm de dimetro, a un promedio de 12,5 litrospor minuto y a una presin de 30kN/m2 duranteun tiempo que no sea menor a 3 minutos y a unadistancia no menor de 3 metros.

5 Chorros de agua. Emplazamiento similar al dedespliegue.

No debe entrar el agua arrojada a chorros (desdecualquier ngulo) por medio de una boquilla de12,5 mm de dimetro, a un promedio de 100 litrospor minuto y a una presin de 100kN/m2 duranteal menos de 3 minutos y a una distancia no menora 3 metros.

6 Chorrosmuy potentesde agua.

Emplazamiento similar al dedespliegue.

Condiciones similares pero ms exigentes que lasanteriores.

7 Inmersin completaen agua.

El objeto debe soportar sinfiltracin la inmersin com-pleta a 1 metro durante 30 mi-nutos.

No debe entrar agua.

8 Inmersin completa ycontinua en agua.

Inmersin completa en agua:condiciones ms severas.

No debe entrar agua.

Segn esta especificacin, exigir una restriccin IP55 o IP56 sera suficiente para nuestro equipo.

2.2.2 Comunicacin

Los sensores se dispondrn a lo largo de la ciudad en emplazamientos sin determinar a priori. Las redesde sensores se caracterizan por tener un gran nmero de nodos, que pueden estar ms o menos alejadosentre s, y no requerir, en principio, de una comunicacin punto a punto entre nodos finales. Esto nos llevaa no considerar como opcin una red de sensores cableada, la cual encarecera el despliegue y dificultarainstalaciones puntuales de nuevos dispositivos. Optaremos por protocolos de comunicacin inalmbrica parael intercambio de informacin entre equipos de la red. Aparecen entonces diferentes opciones para redes desensores, entre las que destacamos: Bluetooth, ZigBee, WiFi y tecnologas de redes mviles.

Protocolos de comunicacin inalmbrica

No debemos perder de vista las restricciones impuestas para los elementos finales (sensores). Quiz una delas ms importantes sea la que tiene que ver con el consumo y la vida til de los dispositivos. Esta restriccincondiciona en gran medida la eleccin de uno u otro protocolo. A continuacin podemos encontrar unacomparativa de los protocolos mencionados que nos facilitar la tarea de elegir entre las diferentes opciones.


Tabla 2.3 Comparativa de protocolos para comunicaciones inalmbricas.

Protocolo Ventajas Inconvenientes

Bluetooth(IEEE

802.15.1)

Adecuado para aplicaciones querequieran un bajo consumo.

Alta tasa de transmisin compara-da con ZigBee (hasta 3Mbps).

Alcance reducido (1-30 metros).Segn potencia de transmisin.

ZigBee (IEEE802.15.4)

Ideal para aplicaciones de muybajo consumo (30mA en transmi-sin y apenas algunos A en repo-so), mucho menor que Bluetooth.

Mayor nmero de nodos por su-bred (255) que Bluetooth (8).

Topologas en malla: mejora de larobustez de la red.

Tasas de transmisin muy bajas(hasta 250kbps).

WiFi (IEEE802.11b)

Muy altas tasas de transmisin(hasta 300Mbps en sus ltimasversiones).

Gran nmero de protocolos de ci-frado asociados, lo cual se traduceen mayor seguridad y fiabilidad.

Alto consumo: reduccin de la vi-da til de las bateras.

Red mvil(3G, GPRS,GSM...)

Altas tasas de transmisin: velo-cidad depende de la tecnologa dered presente.

La estructura interna de la red estransparente al usuario.

Consumo muy elevado motivadopor las altas potencias de transmi-sin.

Los dispositivos finales proveern lecturas de los sensores y enviarn los paquetes de datos sobre sealesde radio utilizando alguno de estos protocolos. Se estima que estos paquetes de datos posean un peso ligero,como mximo de unos pocos cientos de bytes, por lo que no necesitamos una alta tasa de transmisin.

Elementos de una red de sensores

Sensores. Presentes en los nodos para tomar informacin del medio y convertirla en una seal entendiblepor un sistema de procesamiento.

Nodos o Motas. Dispositivo electrnico compuesto por un mdulo de comunicaciones, sistema deaporte de energa, sensores y sistemas para procesamiento de informacin.

Gateway. Elemento electrnico que sirve de pasarela entre la red de sensores y una red de datosTCP/IP.

Servidor de almacenamiento/equipo Cloud. Elemento electrnico que sirve de pasarela entre la redde sensores y una red de datos TCP/IP.


Figura 2.1 Elementos principales en una red de sensores.

El protocolo ZigBee

Zigbee es un protocolo basado en el estndar IEEE 802.15.4 para aplicaciones que requieran un bajo consumo,no muy alta tasa de datos y comunicaciones seguras. Opera en las bandas libres de 868 MHz (Europa),915 MHz (EEUU) y 2.4 GHz, sin embargo es esta ltima la libre en todo el mundo, por lo que se suelenemplear, en mayor medida, dispositivos ZigBee que levanten seal en esta radio. Fue desarrollado por laZigBee Alliance hacia el ao 2002, una organizacin sin nimo de lucro formada por diferentes empresas. Sepretenda desarrollar un protocolo de comunicacin que permitiese conseguir un muy bajo consumo, condispositivos baratos, con un corto alcance (entre 10 y 100m) y que requiriese poca electrnica para construirun nodo. La aplicacin tpica para este protocolo la encontramos en proyectos de sensores y actuadores paradomtica.

Se pueden definir tres tipos distintos de dispositivos ZigBee segn su rol en la red:

Coordinador ZigBee (PANCoordinator). Al menos uno por red. Se encarga de configurar los parmetrosde red y de gestin de red. En conjuncin con los routers, trazar los caminos que deben seguir losdispositivos finales para interconectarse.

Router ZigBee (Full Function Device). Conecta los diferentes clusters de la red, pudiendo actuaradems como gateways hacia otras redes.

Dispositivo final (Reduced Function Device). Funcionalidad completamente reducida para optimizar elconsumo. No intervienen en la gestin de la red ni se comunican con otro dispositivo que no sea sunodo inmediatamente superior en escala, en este caso un router.

Es posible, asimismo, disear la red en base a topologas tpicas como en estrella o rbol, pero la que resultasin duda ms interesante para este protocolo (y aventaja en cuanto a otros) es la topologa en malla. Bajo estatopologa, si se experimenta una comunicacin en alguno de los nodos, existe siempre una alternativa y no seexperimentara una cada del servicio.


Figura 2.2 Topologas posibles en una red ZigBee.

El protocolo Bluetooth Low Energy

Tambin conocido como BLE o Bluetooth Smart, esta nueva tecnologa para redes WPAN viene a mejorarel conocido estndar Bluetooth tratando de conseguir un menor consumo y hacer frente, as, a protocolosultra bajo consumo como ZigBee. Lo cierto es que en este sentido, lo consigue, siendo capaz de conseguiruna vida til de batera de varios aos, al igual que ZigBee. Consigue hasta cuatro veces mayor tasa detransmisin de bits ( 1Mbps) aunque viendo reducida su cobertura (entre 5 y 10 metros). Requiere mselectrnica para la construccin de un nodo, lo que hace que los mdulos que implementan esta tecnologaposean un coste mayor. Las topologas admitidas para este protocolo son estrella y rbol, por ser un protocolode comunicacin punto a punto. A continuacin pueden apreciarse las modificaciones en las capas de unaversin de la tecnologa a otra.

Figura 2.3 Comparativa de la pila de capas en Bluetooth y BLE.

Comparativa final y tecnologa escogida

Si bien BLE consigue tasas de transmisin ms altas que ZigBee, lo cierto es que para nuestra aplicacinno requerimos de un gran bitrate. En cuanto al consumo, sobre el papel y teniendo en cuenta nicamentenodos finales (los que podrn ir al reposo tras su operacin), estn bastante parejos, pero existe un parmetroms a tener en cuenta: el tiempo que tarda un nodo final en volver del reposo. En ZigBee este tiempo es deaproximadamente 15s, mientras que en BLE es de 3s. Esto implica un menor tiempo de actividad para un


dispositivo ZigBee.

BLE es una muy interesante tecnologa que bien podra servir a nuestro cometido, pero el menor coste delos mdulos ZigBee, la posibilidad de disear la red con topologa en malla para evitar nodos inaccesibles yel mayor alcance de cobertura hacen que el protocolo para comunicacin inalmbrica de los dispositivos dela red sea ZigBee.

2.2.3 Electrnica interna

Existen diferentes alternativas en el mercado para dar solucin a lo que pretendemos. Por un lado podemosoptar por adquirir dispositivos Plug & Play de fabricante, electrnica open hardware o, por otro lado, diseary desarrollar nuestro propio dispositivo. Se plantean por tanto tres opciones perfectamente vlidas quedeberemos caracterizar para ofrecer una solucin acertada, teniendo en cuenta tanto el alcance del proyectocomo la satisfaccin de las diferentes condiciones impuestas.

Lo que pretendemos es caracterizar concentraciones de gases en zonas urbanas y que estas puedan sermonitorizadas a travs de Fi-Ware. La opcin de disear y construir un dispositivo propio aumentara elalcance del proyecto de manera considerable y no podramos detenernos en lo verdaderamente interesante,que es la utilizacin de esta plataforma para proyectos de Smart City, por lo que queda descartada estaimplementacin. A continuacin estudiaremos la viabilidad de cada una de las soluciones restantes.

Hardware de fabricante

Esta tecnologa es an emergente y no existen demasiadas soluciones en el mercado, pero empiezan a aparecerdiseos e integraciones que son ofrecidos como un producto final. Veamos cules son los tres productos msinteresantes para nuestro cometido.

Telefnica Thinking Things

Telefnica se sube al carro del Internet of Things lanzando una plataforma de hardware modular bajoesta denominacin. Se trata de poder construir un dispositivo final en base a diferentes mdulos, al estilode la plataforma Arduino (y con su apoyo). Adems ofrecen conectividad global de los dispositivos ymonitorizacin a travs de una plataforma propia. Posee un precio aproximado de 90 euros con conectividadglobal gratis durante seis meses.

Figura 2.4 Telefnica Thinking Things.

Este hardware es demasiado novedoso y actualmente el kit ambiental ms parecido a lo que se pretendedesplegar es el compuesto por sensores de ruido, luminosidad, temperatura y humedad. Esto es, los parmetrosms tpicos medibles en un determinado contexto en la ciudad. No aplica por tanto al caso en que nos encon-tramos por lo que, si bien podra ser una interesante opcin en el futuro, tendremos que sopesar otras opciones.

Smart Citizen

Smart Citizen es una placa de electrnica basada en Arduino cuyo principal objetivo es poder otorgarmedidas de diferentes parmetros medibles en la ciudad, tal y como pretendemos. Su precio aproximado, sinincluir la conectividad es de 175 euros. Si bien mediante esta placa se pueden obtener lecturas de gases comoel CO y NO2 y posee un mdulo de comunicacin M2M, la problemtica reside en el mismo lugar que paraThinking Things: actualmente no existen shields acoplables para incluir un mayor nmero de sensores. Estalimitacin no hace viable su utilizacin.


Figura 2.5 Smart Citizen Board.

Libelium Waspmote

Si alguna empresa se ha posicionado de manera importante en el sector, esa es la espaola Libelium. Sumodelo de placa Waspmote es el ncleo de la que probablemente sea la oferta ms completa que existe encuanto a shields para sensrica, comunicaciones y otras aplicaciones. Estas placas tambin estn basadas enArduino, completndose el producto con libreras e IDEs propios para facilitar el manejo de estas shields.Este ncleo Waspmote, junto con un mdulo de comunicacin, cuesta 155 euros.

Figura 2.6 Libelium Waspmote.

En nuestro caso, buscamos una shield que contenga sensores para diferentes tipos de gases, lo cual esexactamente lo que la shield Gas Sensor Board nos ofrece a un precio aproximado de 120 euros.

Figura 2.7 Gas Sensor Board para Waspmote.


Electrnica open source: Arduino

En este momento nos planteamos construir los dispositivos utilizando la ms conocida plataforma de elec-trnica open source: Arduino. Las placas presentadas hasta ahora estn basadas en esta plataforma, tanto anivel hardware como software, por lo que no parece descabellado tratar de conseguir el mismo efecto quepretendemos construyendo a partir de esta base para tratar de ahorrar en costes. Existen diferentes boards yshields acoplables, cada una enfocada a una aplicacin diferente. Deberemos tratar de encontrar aquella quese ajuste a la nuestra, en este caso proveer lecturas de polucin.

En este momento no existen shields Arduino que resulten adecuadas para nuestra aplicacin, por lo quepodramos listar una serie de condiciones y elementos exigibles a esta placa para hacernos una idea de lo quenecesitamos:

Suficientes entradas/salidas para conectar diferentes tipos de sensores.

Shield para acoplar un mdulo XBee (se requiere al menos una UART).

Encapsulado externo con certificacin de al menos IP55.

Encapsulado externo con igual certificacin para cada sensor a conectar. Dejar los sensores dentro dela caja estanca provocara lecturas que no se corresponderan con la realidad.

Electrnica adicional para convertir voltajes/corientes adecundose a cada tipo de sensor en la placa.

Escalabilidad, para ofrecer diferentes soluciones con los sensores que se comercializan hoy en da.

Esto no son ms que restricciones generales impuestas ahora sobre este tipo de solucin. En la tiendavirtual de Arduino (http:// store.arduino.cc/ ) se puede encontrar la placa Arduino UNO, que es la placa degama ms baja que podra satisfacer nuestras necesidades a nivel de electrnica y se asemeja ms al ncleoWaspmote, aunque ste ltimo presente algunos elementos electrnicos ms. Recogemos algunas de suscaractersticas tcnicas ms relevantes:

Tabla 2.4 Arduino UNO: especificaciones tcnicas.

Microcontrolador ATmega328Voltaje operativo 5V

Voltaje de entrada recomendado 7-12VEntradas/Salidas digitales 14

Entradas/Salidas digitales PWM 6Entradas analgicas 6Memoria Flash 32 KB

Velocidad de reloj 16 MHzPrecio 25 euros

Figura 2.8 Placa Arduino Uno con shield para mdulo ZigBee.

Una shield para comunicacin y un mdulo ZigBee tendran un coste aproximado de 43 euros, lo que daraun coste total de unos 73 euros. Habra que aadir componentes de la Waspmote que la placa Arduino UNO


no posee como un acelermetro, mdulo SD o un RTC. La diferencia en precio final es de aproximadamente30 euros.

A esto, habra que aadir el sobrecoste que origina el encapsulado y las bateras, disear cierta electrnicapara amoldar la placa a cada tipo de sensor y desarrollar todo el software necesario para que todo quedase enperfecto funcionamiento. An as esta opcin seguira resultando ms barata.

Realizando una pequea estimacin del trabajo a realizar previo al uso de estas placas, parece que steextiende el alcance del proyecto en demasa, al igual que disear nuestra propia electrnica desde cero para laaplicacin. Teniendo en cuenta que en este proyecto nos encontramos ms enfocados en la solucin, es decir,en ofrecer una integracin en la plataforma de Fi-Ware, y no tanto en el diseo y construccin de este tipo dedispositivos, la opcin de Waspmote Plug & Sense Smart Environment parece la ms adecuada.

Figura 2.9 Libelium Smart Environment desplegada en una ciudad.

2.3 Eleccin final: Waspmote 21

2.3 Eleccin final: Waspmote

2.3.1 Core: especificaciones tcnicas

Lo realmente interesante de esta plataforma hardware es su capacidad para acoplar diferentes shields diseadas,especialmente, para proyectos Smart City. Hoy en da no existe ninguna otra solucin tan modular y escalabledirigida a este tipo de proyectos. Presentamos la ltima versin del core: Waspmote PRO (v1.2).

Figura 2.10 Waspmote v1.2: frontal.

Figura 2.11 Waspmote v1.2: trasera.

Esta ltima versin viene a mejorar la anterior con una mayor velocidad de procesamiento, sustitucinde jumpers por switches e inclusin de un puerto SPI entre muchas otras. En general, algunos cambiosestructurales para mejorar la eficiencia y el uso, aunque incompatibiliza el uso de algunas shields que podranresultar interesantes. Libelium contina ofreciendo soporte y unidades de la versin anterior por lo que, elegiruna u otra dependiendo de la shield a utilizar, queda a eleccin del usuario. Se presentan aqu algunas de lascaractersticas tcnicas de esta plataforma.


Tabla 2.5 Waspmote v1.2: especificaciones tcnicas.

Microcontrolador ATmega1281Voltaje operativo 5V

Voltaje de entrada recomendado 7-12VEntradas/Salidas digitales 8

Entradas/Salidas digitales PWM 1Entradas analgicas 7Memoria Flash 128 KB

Velocidad de reloj 14 MHzMdulo radio Bluetooth/WiFi/ZigBee

Precio 155 euros

2.3.2 Gas Sensor Board

Esta shield se dise con el objetivo de monitorizar parmetros ambientales, tales como la temperatura,humedad o presin atmosfrica, pero tambin concentraciones de gases conocidos cuyos valores en entornosurbanos se encuentran regulados y es interesante controlar. Particularmente, esta shield permite la inclusinde hasta 7 sensores de gas a la vez, regulando la alimentacin de cada uno y realizando un tratamiento dela seal obtenida para adecuarla a lo que se pretende. Esto se consigue a travs de una etapa amplificadorano inversora con una ganancia mxima de 101, regulable por software gracias a un potencimetro digitalconectado al bus I2C.

Figura 2.12 Shield Gas Sensor Board: detalle.

Los tipos de gases que pueden monitorizarse mediante una conexin directa a la placa son:

Monxido de carbono CO.

Dixido de carbono CO2.

Oxgeno O2.

Metano CH4.

Hidrgeno H2.

Amonaco NH3.

Isobutano C4H10.

Etanol CH3CH2OH.

2.3 Eleccin final: Waspmote 23

Tolueno C6H5CH3.

Sulfuro de hidrgeno H2S.

Dixido de nitrgeno NO2.

Ozono O3.

Compuestos orgnicos voltiles (VOCs).

Hidrocarburos.

Existen sockets dedicados a sensores que requieren un tratamiento especial a nivel elctrico, como es el casodel CO2 (socket 1A) o O3 (socket 2B). Existe una API desarrollada especialmente para trabajar con esta shield:WaspSensorGasv20. Ms adelante tendremos ocasin de usarla durante el desarrollo del software de las motas.

Resulta muy interesante este diseo modular, con posibilidad de acoplar diferentes tipos de sensores, yaque no se requiere electrnica adicional o redisear el sistema segn la carga que conectemos a la plataforma.

2.3.3 Libelium Smart Environment

La versin del core Waspmote junto con la shield Gas Sensor Board, y completada con una certificacin IP65,es la Waspmote Smart Environment. Esta plataforma provee 6 conectores diferentes internamente conectadosa los sockets de la placa Gas Sensor Board, de manera que puedan utilizarse diferentes sensores sin ms queajustar la conexin.

Figura 2.13 Detalle del modelo Smart Environment.

Se debe tener especial precaucin con la colocacin de los sensores, pues adaptar el sensor sobre un socketque provea una alimentacin o un tratamiento interno diferente podra daarlos. Libelium provee una tablade compatibilidad para los conectores de esta plataforma.


Figura 2.14 Compatibilidad socket-sensores..

Conserva las bondades tanto del core como de la shield: socket para conexin de panel solar, puerto USBpara programacin y todas las especificaciones tcnicas anteriormente comentadas.

2.4 Eleccin del gateway 25

2.4 Eleccin del gateway

Para tener una visin clara de qu se pretende conseguir a nivel de red, se presenta aqu un esquema sencillodel modelo.

ZigBee

3G/GPRS/GSM

3G/GPRS/

GSM

3G/G

PRS/

GSM

3G/GP

RS/

GSM

Navegador Web (HTTP GET)

Figura 2.15 Modelo de red.

Los routers XBee actuarn, adems, como gateways hacia Internet y encauzados estos hacia el servidorcentral, donde se encuentra la base de datos y el procesamiento necesario para la conexin a tiempo realcon Fi-Ware. Existe, pues, la necesidad de desarrollar equipos electrnicos con capacidad para albergar dosmdulos de comunicacin. Su funcin bsica ser conseguir las tramas de lecturas que llegan hacia ellospor la red ZigBee y lanzarlos hacia el servidor central. Existen diferentes alternativas para construir estode manera poco costosa en tiempo: utilizar ncleos Arduino o Waspmote. Anteriormente ya pudimos tenerun esbozo de la diferencia en coste entre los ncleos Waspmote y Arduino, y algunos de los componentesque encarecan el primer modelo. A continuacin se presenta un desglose de los equipos necesarios paraconstruir los routers/gateways segn cada plataforma.

Tabla 2.6 Presupuesto del gateway: modelo basado en Waspmote.

Componente Unidades Precio (euros/ud)Waspmote + GPRS 1 158

Xbee Zigbee Pro SMA 5dBi 1 22.9Expansion Radio Board 1 25

Batera recargable 2300 MAh 1 18SIM M2M 1 (segn tarifa)

TOTAL (sin IVA) 223.90 eurosTOTAL (21% IVA) 270.92 euros


Tabla 2.7 Presupuesto del gateway: modelo basado en Arduino.

Componente Unidades Precio (euros/ud)Arduino Uno 1 20

Xbee Shield Module 1 15Xbee Zigbee Pro SMA 5dBi 1 22.9

Arduino GSM Shield 1 69Batera recargable 2300 MAh 1 18

SIM M2M 1 (segn tarifa)TOTAL (sin IVA) 144.90 eurosTOTAL (21% IVA) 175.33 euros

El modelo basado en ncleo Waspmote resulta alrededor de un 35% ms caro. Debemos tener en cuentaque este ncleo incorpora otros componentes adicionales que no monta el ncleo Arduino y que conllevan unsobrecoste aproximado de 60 euros. Para el despliegue que pretendemos realizar, incorporar un acelermetro,conector para panel solar o mdulo para uSD no resulta necesario, por lo que el modelo basado en Arduinoresulta el ms conveniente econmicamente.

3 Desarrollo del software para dispositivos dela red

3.1 Primeros pasos con Waspmote Smart Environment

3.1.1 IDE

El IDE o Integrated Development Environment es un entorno de programacin compuesto por diferentesherramientas que ayudan a desarrollar determinadas aplicaciones. Se compone usualmente de un editorde cdigo, un compilador, un depurador y una interfaz grfica. El software desarrollado para cargar enplataformas Waspmote, tanto para placas de desarrollo como para las Plug & Sense, debe ser compilado ycargado a travs de la IDE de Waspmote, basada en la IDE de Arduino. El desarrollo de esta IDE no seraposible sin el carcter open-source de la plataforma Arduino. Esta IDE incorpora barra de herramientas,editor de cdigo, terminal de mensajes del compilador y monitor serie entre otras muchas.

Cualquier otra IDE que no fuese la de Waspmote podra volver inestable el dispositivo, por lo que ser estala que utilicemos en el proceso de desarrollo y carga de programas. Libelium proporciona versiones de estaIDE para los sistemas operativos ms comunes, as como las APIs para lectura de sensores y utilizacin delos mdulos de comunicacin de las diferentes boards.

Figura 3.1 Arduino IDE / Waspmote IDE.

27

28 Captulo 3. Desarrollo del software para dispositivos de la red

Los programas sern cargados en los nodos a travs del puerto USB que incorporan, como puede apreciarsea continuacin.

Figura 3.2 Carga de programas en Waspmote.

3.1.2 Lenguaje de programacin

La programacin de las Waspmote es idntica a la de las placas Arduino, por lo que hereda el lenguaje y todaslas caractersticas asociadas. El software escrito para Arduino se denomina sketch, est basado en C y C++ ylibreras estndar de este lenguaje (AVR Libc). Los sketches son convertidos a lenguaje mquina a travsde un compilador tipo gcc propio de los microprocesadores Atmel (AVR) que incorporan las placas. Estecdigo ya convertido, combinado con las libreras bsicas de Arduino, contiene el fichero binario que sercargado en la memoria de programa del chip en la placa. Los sketches se dividen en tres partes: estructura,constantes/variables y funciones.

La estructura principal de un sketch en Arduino se compone de dos funciones principales: setup() y loop().Setup() es la funcin llamada cuando comienza la ejecucin del sketch y contiene todas las inicializacionesde variables, inicio de mdulos de la placa mediante librera y seteo de pines como entrada/salida o encendi-do/apagado. Esta funcin slo se ejecuta una vez, despus de cada reseteo o encendido de la placa.

Loop() es, como su nombre indica, el bucle que se mantiene en ejecucin y provee un control activo de laplaca, provocando que esta responda ante cambios externos segn se programe.

Las estructuras de control, operadores lgicos, sintaxis, formatos de variables y funciones bsicas sonidnticas a las de C/C++, por lo que para mayor informacin de aqu en adelante acudiremos a la pgina dereferencia para programacin de Arduino 1. Aqu se ofrece un ejemplo de programacin tpica en Arduino,enviando el estado de un botn situado en el pin 3 y monitorizado a travs del puerto serie.

const int pin_Boton = 3;

void setup(){Serial.begin(9600);pinMode(pin_Boton, INPUT);

}

\\Si se pulsa el boton,\\se enviara estado por puerto serie

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

3.1 Primeros pasos con Waspmote Smart Environment 29

void loop(){if (digitalRead(pin_Boton) == HIGH)Serial.write(H);

elseSerial.write(L);

delay(1000);}

3.1.3 Calibracin y puesta a punto de los sensores de polucin

Consideraciones generales

En el interior de la Waspmote Plug & Sense Smart Environment se encuentra una board del estilo a la que sepuede ver a continuacin.

Tener una caracterizacin visual de ella facilitar el entendimiento de este apartado. Debe tenerse muyen cuenta que pueden existir diferencias significativas entre sensores de un mismo modelo, pues a nivelmacroscpico podran resultar iguales pero no as a nivel microscpico. Con el fin de construir una placa quepueda adaptarse por software al sensor que se coloque en ella, esta board incorpora resistencias de carga yetapas de amplificacin regulables. Mediante la librera disponible para la gas board podremos configurarestos parmetros electrnicos. Tampoco es la misma alimentacin para cada socket: 5V para cualquiera salvopara el socket 3B (1.8V) y para el socket 2B (2.5V).

Figura 3.3 Gas board presente en el interior del dispositivo.

La sensibilidad del sensor depender adems de las condiciones climticas del entorno al que se expongao si ha pasado por un largo periodo de inactividad. El clculo de la resistencia del sensor, desde la que puedeinferirse la concentracin del gas que se pretende medir, puede ser realizado a travs de la ecuacin:

Rs =Vc RLVout

RL

Siendo Rs la resistencia del sensor, Vc la tensin de alimentacin, Vout la tensin de salida medida y RL laresistencia de carga del socket.


Aspectos claveLos principales factores a tener en cuenta debern ser, por tanto, cmo configuramos las etapas de amplifica-cin y resistencias de carga, cul es el proceso de calibracin a seguir y cmo convertimos el valor de voltajeo resistencia del sensor a concentracin de gas.CalibracinUna calibracin precisa exige contar con un laboratorio en que reproducir diferentes condiciones en que sepuedan dar ciertas concentraciones del gas a medir. Los diferentes valores medidos se traduciran en unacurva de calibracin mediante una aproximacin matemtica (logartmica, por ejemplo). Se debe tener encuenta que las diferencias microscpicas para cada sensor dan lugar a infinitas curvas de calibracin. Parauna aplicacin que no exija una precisin extrema como la que estamos considerando, se puede acudir ala curva de calibracin que ofrece el fabricante para cada tipo de sensor, que no es ms que una media decomportamientos de sensores similares a nivel macro.

Figura 3.4 Ejemplo de curva de calibracin: sensor de humedad Sencera 808HSV5.

Ajuste de ganancia y resistencia de cargaLa ganancia y resistencia configurada para cada etapa depender de dos aspectos principales: el sensorconectado y las condiciones en que se vaya a situar el dispositivo para la aplicacin. Esta configuracindepender de lo fino que se quiera hilar para las lecturas. En una aplicacin como sta en que se pueda requerirproducciones en masa que hagan inviable calibrar un gran nmero de sensores y actuar en consecuencia,seguiremos las reglas generales propuestas por el fabricante.

Para la etapa de amplificacin la ganancia se fijar a 1, salvo para aplicaciones que requieran llevar elrango de medida del sensor al lmite. Existen dos excepciones a esta regla: para los sensores deCO2 y O2.Estos sensores requieren que el voltaje de salida sea amplificado para ajustarse al convertidor ADC de laWaspmote. En el caso del O2, deber amplificarse con un factor de 100 y de entre 7 y 10 para elCO2.

Para el caso de la resistencia de carga no es tan simple por lo comentado anteriormente. Se requerir unanlisis basado en prueba-error para conseguir el valor correcto de resistencia, comenzando con el valor inicialms bajo segn el datasheet del sensor y ajustndolo hasta conseguir el valor medio del rango del ADC (1.6V).

Asimismo, se recomienda calentar los sensores realizando lecturas continuas durante al menos 12 horas yno configurar valores de resistencia de carga inferiores a la mnima, ya que esto podra daar los sensores.

3.1 Primeros pasos con Waspmote Smart Environment 31

Unidades de medicin

Es importante caracterizar demanera precisa las unidades en que se proporcionan las lecturas para que ofrezcaninformacin relevante. Existen numerosos estudios realizados por la OMS y otras entidades certificadas queaportan el lmite de exposicin de vapores qumicos en el aire (TLV) mediante dos unidades principales:partes por milln y microgramos por metro cbico. La medida en partes por milln solo puede considerarse sila sustancia existe como gas o vapor a temperatura y presion normales (25 C y 1 atm). En estas condiciones,se relacionan de la forma:

TLVmg/m3 =PM(g)TLVppm

24.45

Siendo PM el peso molecular de una sustancia determinada en gramos y 24.45 el volumen en litros de unmol de gas cuando la temperatura es 25C y la presin 1 atm. Si consideramos diferentes condiciones delentorno, la conversin de mg/m3 a ppm no es tan inmediata:

V =RTP

TLVmg/m3 =PRTPM TLVppm

Con R la constante ideal de los gases ideales (0.082atmLK mol ), T la temperatura en grados Kelvin (273 +

T(C)) y P la presin en mm Hg.

Conversin a unidades tpicas

El valor de concentracin de los gases en ppb o ppm (dependiendo del sensor) puede obtenerse mediantelas curvas de calibracin del fabricante, ya que no se realiza en este caso una calibracin exhaustiva paracada sensor. Es necesario, an as calcular la resistencia inicial del sensor, cuyo rango se nos facilita en eldatasheet. Habr que tener en cuenta, adems, que factores ambientales como la temperatura o la humedadtambin pueden afectar a las lecturas. Se pueden encontrar dos tipos de grficas en los datasheets de lossensores segn el eje Y represente un ratio de resistencias o una diferencia de tensiones (paraCO2). Fijandoun valor de tensin de referencia y calculando la diferencia de este con el valor de tensin otorgado por elsensor podremos tener una caracterizacin de la concentracin del gas en un ambiente determinado.

Figura 3.5 Ejemplo de curva de calibracin:4EMF.


Figura 3.6 Ejemplo de curva de calibracin: Rs/Ro.

3.2 Nodos sensores 33

3.2 Nodos sensores

3.2.1 Comportamiento bsico del sistema

El software desarrollado para los dispositivos finales deber ser robusto y eficiente en cuanto al consumo,adems de cumplir con la funcionalidad que se pretende que tengan. Para ello, definimos algunas pautas:

El estado normal del dispositivo ser el de reposo. Para ello deberemos dormir al dispositivo tras laslecturas y despertarlo con la periodicidad que deseemos. En este caso apagaramos todos los mdulosno necesarios durante el reposo y volveramos a arrancarlos en cada lectura.

Una lectura adecuada de los sensores implica el calentamiento y la calibracin de estos para otorgarmedidas tan precisas como sea posible. Aparece aqu un compromiso tiempo de calentamiento -consumo final del dispositivo que tendremos que tener en cuenta.

Configuracin del mdulo de comunicacin (XBee) para enviar las tramas contenedoras de lecturas asu gateway/router ms prximo.

Sera interesante llevar control de posibles errores en formacin de paquetes, verificar conexin a la redZigBee, lecturas de sensores o posibles transmisiones errneas. Para monitorizar esto, inicializamosel puerto serie y habilitamos una variable booleana que defina si nos encontramos o no en mododepuracin.

Aadiremos alguna funcionalidad adicional para ganar robustez ante problemas que puedan surgir trasmuchos ciclos de actividad del microprocesador (desbordamiento de buffers...).

3.2.2 Caractersticas destacables de la implementacin

Los sensores de gas necesitan entre 1 y 10 minutos para estabilizar la lectura, segn el fabricante. Sibien debemos esperar un tiempo suficiente para el calentamiento de los sensores (el cual marcar aquelcuyo valor sea ms alto), tomaremos varias medidas y ponderaremos para obtener un valor medio. Lavida til de las bateras viene marcada en gran medida por el tiempo que pasa encendido el dispositivo,por lo que para aquellos dispositivos que incorporen sensores con tiempos de calentamiento altos habrque llegar a un compromiso en cuanto a la frecuencia de las lecturas, de manera que se puedan recargarlas bateras adecuadamente y que esto no afecte al correcto funcionamiento.

Para cada tipo de gas se requiere linealizar la curva de calibracin en torno a un punto de trabajoconocido. Por ejemplo, paraCO2 se linealiza en torno a 335 ppm, el valor medio sobre el que oscilanestas medidas en un ambiente urbano.

3.3 Gateways

3.3.1 Comportamiento bsico del sistema

Este dispositivo deber estar continuamente encendido esperando paquetes ZigBee procedentes de losnodos finales. Al incorporar un mdulo 3G/GPRS (red mvil) tendr picos de consumo en transmisin,y una batera tpica no ofrece suficiente carga para alimentar ambos mdulos, por lo que necesita estaralimentado continuamente. Pediremos que el procesado interno sea lo ms sencillo posible.

Configuracin del mdulo de comunicacin (XBee) para recibir las tramas contenedoras de lecturas.

Configuracin del mdulo 3G/GPRS para envo de lecturas al proxy.

Control del proceso a travs del puerto serie.


3.4 Conexin con Fi-Ware y almacenamiento en BBDD

3.4.1 Comportamiento del software

Recogida de las lecturas procedentes de los gateways.

Almacenamiento en base de datos.

Conexin con el punto de entrada a Fi-Ware, en este caso Orion Context Broker, para reflejar estamedida en tiempo real.

Aadir datos relevantes a la lectura, como la fecha y hora en que se mide, para que aparezca reflejadoen Fi-Ware.

3.4.2 Lenguajes posibles para la implementacin

Desde el gateway deberemos acceder a unamquina (PC) que acte como servidor web, ejecute las operacionesexigidas y se comunique con Fi-Ware. Este equipo de la red es comnmente conocido en informticacomo proxy. Aparecen diversos lenguajes (todos del lado servidor) en que se puede implementar estecomportamiento, entre los que destacamos:

ASP.NET o Active Server Pages. Es la tecnologa desarrollada por Microsoft para crear pginas webdinmicas. El lenguaje es similar a Visual Basic Script con algunas ventajas especficas en entornosweb. Est limitado a funcionar slo en Microsoft Windows a travs de un servidor tipo IIS.

PHP o Hypertext Pre-processor. Es un lenguaje de programacin para desarrollo web dinmico. Elcdigo es interpretado por un servidor web con mdulo intrprete PHP (Apache). Es multiplataforma ypermite conexin a diferentes tipos de bases de datos, tanto SQL (MySQL) como NoSQL (MongoDB).Es libre y est considerado uno de los lenguajes ms potentes y con mayor comunidad de usuarios.

JSP o Java Server Pages. Basado en Java, viene a ofrecer un comportamiento similar a los anteriores.Para desplegar webs escritas en JSP se requiere un servidor web compatible, como Apache Tomcat oJetty.

Por la versatilidad que ofrece, la abundante documentacin existente y aprovechando que ya conocemos algode PHP, ser este el lenguaje que utilizaremos para implementar el middleware.

3.4.3 Interaccin con Orion Context Broker

Como ya comentbamos en captulos anteriores, el Orion Context Broker es una implementacin de unservidor NGSI 9/10 para administracin de informacin de contexto. Se despliega sobre una mquina Linux,particularmente con distribucin Debian, y se ejecuta como un servicio "demonio". Queda accesible a travsde su API REST en el puerto 1026 de manera que podemos interactuar con l a travs de llamadas HTTPconociendo la IP de la mquina en la que se ejecuta y dirigindolas al puerto comentado.

3.4 Conexin con Fi-Ware y almacenamiento en BBDD 35

Figura 3.7 Orion Context Broker: interacciones..

Si bien REST (Representational State Transfer) originalmente se refera a un conjunto de principios dearquitectura software para sistemas en la red, actualmente se utiliza para describir cualquier tipo de interfazweb que utilice XML y HTTP, viniendo a mejorar arquitecturas similares para web services como SOAP.Hoy en da es muy usual encontrar APIs REST para desarrolladores en las webs de contenido de las grandesmarcas (Facebook, Amazon, Twitter...). Las operaciones que nos permite esta API, en el caso particular delOrion Context Broker son las NGSI 9/10 definidas en el estndar que posibilitan la creacin, actualizacin ysuscripcin a cambios en entidades del contexto:

updateContext

queryContext

subscribeContext

updateContextSubscription

unsubscribeContext

El payload de la llamada HTTP puede estar escrito en XML (Extensible Markup Language), un lenguajede marcas para intercambio de informacin, o JSON (JavaScript Object Notation), un formato ms ligero queel anterior con el mismo cometido.Creando y consultando entidades

Orion Context Broker se encontrar en permanente estado de escucha, e inicialmente la base de datos mon-goDB se encontrar vaca. Para que OCB maneje la informacin que llega acerca de un cierto dispositivode la red, deberemos instanciar la entidad correspondiente asignando parmetros iniciales, que ms tardesern actualizados por medio de suscripcin a esta entidad. Vamos a crear una entidad Habitacin1 de tipoHabitacin en la que se dispondran dos sensores: temperatura y humedad. Inicialmente estos parmetrostendran el valor que creysemos oportuno, hasta que se reciban actualizaciones por parte de los dispositivos.

Habitacion1

temperaturacentigrados23


presionmmHg720

APPEND

La directiva final < updateAction > puede hacer referencia a dos mtodos: APPEND y UPDATE. Lacreacin de un nuevo dispositivo se realiza mediante APPEND mientras que las posteriores actualizacionesse construirn mediante el mtodo UPDATE. En formato JSON resulta algo menos verboso en ocasiones, porlo que presentamos un ejemplo de esto mismo:

{"contextElements": [

{"type": "Habitacion","isPattern": "false","id": "Habitacion1","attributes": [{

"name": "temperatura","type": "centigrados","value": "20"

},{

"name": "presion","type": "mmHg","value": "720"

}]

}],"updateAction": "APPEND"

}

En este momento, Orion Context Broker crear la entidad en su base de datos interna, asignar los valoresa los parmetros y devolver una respuesta afirmativa si el parsing ha resultado correcto.

Habitacion1

temperaturacentigrados

presionmmHg

200OK


Montando el payload para insercin de dispositivos de la red

En nuestro caso, deberemos crear entidades de tipo SensorGas (o un nombre similar) y asignar un ID a cadauna para poder referenciarlas y actualizar la informacin. Proporcionaremos los parmetros:

Tabla 3.1 Parmetros a los que suscribir el Context Broker..

Parmetro Tipo InformacinCO2 Partes por milln Medicin del nivel de CO2 presente en una zona.NO2 Partes por milln Medicin del nivel de NO2 presente en una zona.O3 Partes por milln Medicin del nivel de O3 presente en una zona.

Latitud WGS84 Primera coordenada geogrfica (esttica).Longitud WGS84 Segunda coordenada geogrfica (esttica).Direccin Direccin postal Calle en la que se encuentra el dispositivo.

Fecha y hora ISO-8601 Visual de ltima lectura en Fi-Ware.

Parmetros como la longitud y la latitud pueden fijarse inicialmente y no modificarse a no ser que se asigneotra localizacin al dispositivo. Por otro lado, existen diferentes APIs vinculadas con mapas geogrficospara proveer una direccin postal a partir de coordenadas geogrficas. Teniendo en cuenta que utilizaremosGoogle Maps para el posicionamiento haremos uso de la API asociada a ste. Fecha y hora sern obtenidasdel servidor intermedio por no poseer RTC los dispositivos de la red. Mediante la funcin time() de PHPpuede conseguirse esto.

Lo que implementaremos en este punto, por tanto, ser el parseo de todos los datos vinculados a undispositivo sobre un payload del tipo al que hemos visto. Todo esto se procesar de manera automticacuando llegue una lectura de los sensores de un determinado dispositivo al servidor. La llamada HTTP haciael Orion Context Broker para crear una entidad del tipo SensorGas tendra una forma similar a la siguiente.

387243712

BAT%70

CO2ppm335

NO2ppm0.025

O3ppm0.025

latitudecoords


37.394742

longitudecoords5.983526

dateISO860120/11/2014 12:24:37

addressstreetCalle Maria Auxiliadora, 25 41003 Sevilla

APPEND

3.4.4 Insercin de medidas en una base de datos MySQL

MySQL es un sistema de gestin de bases de datos relacional, de cdigo abierto y muy extendido, que permitedesplegar de manera sencilla tablas de datos estructuradas en registros y campos. A travs de phpMyAdmin,una herramienta software libre escrita en PHP, podemos gestionar una base de datos de este tipo de maneragrfica, creando bases de datos, tablas o ejecutando rdenes SQL como si de una consola de comandos setratase.

Figura 3.8 Interfaz web phpMyAdmin.

Asimismo, el lenguaje PHP define una serie de APIs para gestin de bases de datos MySQL. Utilizaremosuna de estas APIs para conectar a una base de datos e insertar las lecturas de los sensores en una tabla.Posteriormente podremos utilizar este almacn de datos para mostrar un histrico de las lecturas desdeFi-Ware. A continuacin se muestra un pequeo ejemplo acerca de cmo se abrira una conexin con unabase de datos, recabando toda la informacin de una tabla o insertando nuevas filas de datos.


//Parametros de conexion a BD:$DATABASE = MeshliumDB;$TABLE = pfc;$IP = IP_BBDD;$USER = root;$PASS = pass;

// Conectar con el servidor de base de datos$conexion = mysql_connect ($IP, $USER, $PASS)or die ("No se puede conectar con el servidor");

// Seleccionar base de datosmysql_select_db ($DATABASE)or die ("No se puede seleccionar la base de datos");

// Realizar una consulta MySQL$query = SELECT FROM pfc;$result = mysql_query($query) or die(Consulta fallida: . mysql_error());

// Insertando una medida de los sensores$instruccion = "insert into pfc (ID, BAT, CO2, NO2, O3) VALUES (".$id_secret.",".$sensorValue[0].",".$sensorValue[2].",

".$sensorValue[3].",".$sensorValue[4].");";$consulta = mysql_query ($instruccion, $conexion) or die ("Fallo de insercion en BBDD");

Una vez hayamos implementado este web service ya tendremos lista la recepcin de tramas procedentes delos sensores. Las lecturas se desgranarn, insertando cada una en duplas parmetro-valor en la base de datosy posteriormente sern enviadas hacia Orion Context Broker para que queden disponibles en Fi-Ware.

4 Desarrollo de aplicaciones en Fi-Ware

4.1 Apartados de Fi-Lab

4.1.1 Cloud

Aqu se ofrecen GEs tiles para desplegar una infraestructura de almacenamiento en la nube (cloud hosting)sobre la que desarrollar y administrar las aplicaciones y servicios sobre Fi-Ware. Nuestra instancia de OrionContext Broker correr sobre una mquina que despleguemos corriendo el sistema operativo que deseemossegn las imgenes que se ofrecen de estos. Existen diversas opciones, cada una con un propsito diferente.En la siguiente imagen se aprecian algunas de ellas, as como el panel de navegacin con los distintos GEs.

Figura 4.1 Cloud: el apartado para cloud hosting en Fi-Ware.

En este momento no precisamos conocer en profundidad este apartado, por lo que simplemente utilizaremosaquello que nos sea til para nuestro propsito final.

Desplegando una instancia propia de Orion Context Broker

Para la utilizacin de Orion Context Broker en un determinado proyecto, es posible emplear la instanciaOrion de Fi-Lab (accesible desde http:// orion.lab.fi-ware.org:10026/ ) o desplegar una propia. En este caso,como pretendemos que el proyecto sea privado y nadie pueda tener acceso a nuestros datos, desplegaremosuna propia. Para ello seguiremos los pasos descritos en la wiki de Fi-Ware, desplegando una mquina consistema operativo CentOS e instalando todos los paquetes necesarios a travs de un acceso SSH.

41

42 Captulo 4. Desarrollo de aplicaciones en Fi-Ware

Figura 4.2 Instalando Orion Context Broker.

Necesitaremos conocer Linux y algunos comandos de administracin de MongoDB. Adems, para aadirseguridad a la mquina, solo abriremos los puertos necesarios y requeriremos una clave encriptada paraacceso mediante SSH.

Figura 4.3 Abriendo puertos y creando un grupo de seguridad.

Nuestra instancia de Orion quedara as activa y accesible a travs de la IP que se nos asigna.

4.1 Apartados de Fi-Lab 43

Figura 4.4 Orion Context Broker desplegado y accesible.

4.1.2 Mashup

Wirecloud es una plataforma open-source para creacin de aplicaciones masivas que forma parte de Fi-Waresiendo la implementacin de referencia del Application Mashup GE. Est basada en interfaces conocidascomo widgets que permiten conectar diferentes procesos y servicios web de fuentes diferentes. La plataformaest orientada a que usuarios sin conocimientos de programacin sean capaces de componer interfaces webde consulta de manera sencilla. Este apartado es el realmente interesante, ya que nos permitir desplegar lasaplicaciones que se nos ocurra desarrollar. El endpoint del Mashup sobre Fi-Ware queda accesible a travs dehttps://mashup.lab.fi-ware.org.

Figura 4.5 Wirecloud: capa ms alta de la arquitectura Fi-Ware.

Wirecloud ofrece un catlogo de widgets y operadores que pueden ser compartidos por la comunidad(nmero reducido hoy en da). De esta forma, desarrolladores y empresas pueden comercializar aplicacioneso difundirlas para un uso pblico.

Las tecnologas que se han utilizado para su implementacin son meramente tecnologas web: python


en lado servidor (back) y HTML/CSS/Javascript en el lado cliente (front). Es software libre y puede serredistribuida y modificada bajo los trminos de licencia GNU Affero General Public License.

Creando aplicaciones masivas: wiring

Un widget define tanto un back-end (motor) como un front-end (visual), no as un operador, que soloimplementa el lado back-end. Esto es, un widget tpico podra ser un mapa y un operador un pequeo procesoque consulte una base de datos y genere un objeto que contenga la informacin de la lectura. Este objetodebera ser consumido por otro widget u operador cableando (wiring) ambos en el Mashup.

Figura 4.6 Interconexin de widgets en el wiring.

En la imagen anterior, el operador NGSI Source define un proceso de backend por el que se ejecuta unaconexin NGSI con el Orion Context Broker mediante el que recaba la informacin de las entidades que sedeseen. Esto no es ms que una serie de consultas reiterativas a la mongoDB de la mquina que desplegamosen el Cloud. A travs del cable, la salida de este operador va hacia diferentes widgets que puedan alimentarsede esta informacin.

Un ejemplo sencillo de aplicacin masiva podra ser un mapa que muestre informacin a tiempo realde los sensores desplegados en la ciudad, as como su posicin exacta. En la solucin que ofrecemos msdelante, esta aplicacin requiere un operador que conecte con la mongoDB de Orion, recabe las diferentesentidades de sensores y las mande hacia otro operador. El siguiente operador preparara la informacin paraun widget cuya visual principal fuese un mapa de Google Maps sobre el que se muestra el emplazamiento delos sensores y la informacin asociada.

Creando widgets y operadores

Si bien nos harn falta algunos widgets y operadores ya existentes (sobre todo los que definan procesos debackend), lo realmente interesante ser crear nuevas aplicaciones que puedan ser utilizadas por la comunidado que sirvan de base para futuros proyectos.

Los widgets y operadores se ejecutarn en la plataforma, a la cual se accede mediante un navegador web.Los widgets, al poder ofrecer la visual que necesitemos, podrn ser programados como si de una web setratase, utilizando HTML/CSS. La lgica de control se la otorgaremos mediante Javascript. Por otra parte,los operadores slo definen procesos lgicos, por lo que se debern implementar ntegros en este ltimolenguaje. Wirecloud posee una API Javascript adems para tratar los eventos de entrada/salida de datos atravs del wiring y otros procesos, por lo que tambin nos ser de utilidad en este caso.

4.1 Apartados de Fi-Lab 45

Figura 4.7 Estructura bsica (grfica) de un widget.

Tabla 4.1 Estructura bsica de un widget (.wgt).

config.xml Informacin bsica del widget en lenguaje XML: entradas/salidas, preferencias...index.html Vista principal - Referencias a ficheros JS y CSS.

/js Contenedor de ficheros Javascript./css Contenedor de ficheros CSS.

/images Directorio para imgenes./doc Documentacin para su uso.

Esta estructura bsica de ficheros se comprimen en un fichero .zip, se renombra como .wgt y es este ficheroel que se incluye en los recursos propios del usuario en Fi-Ware si est bien construido.

4.1.3 Store

No requiere mayor resea, pues se trata del catlogo de widgets y operadores que quedan accesibles mediantepago o de manera gratuita al usuario final. Directamente se pueden desplegar sobre un workspace en elMashup y modificarse o utilizarse como se desee.

Figura 4.8 Marketplace en Fi-Lab.

4.1.4 Account

Aqu se definen algunos datos identificativos del usuario o concesin de permisos para aplicaciones quenecesiten utilizar Fi-Lab. Un ejemplo de esto sera permitir el desarrollo de widgets en un editor de cdigo(como Eclipse) de forma que resulte directo hacer pruebas sobre la plataforma a travs de ste.


4.1.5 Data

Una de las partes ms interesantes de Fi-Ware hacia el futuro. Un portal basado en CKAN (ComprehensiveKnowledge Archive Network) que define una plataforma de Open Data, en la que los desarrolladores yusuarios pueden almacenar datos de inters sobre su ciudad que pudiesen ser utilizados por otros usuariospara experimentacin o algn desarrollo de aplicacin concreta.

Figura 4.9 Marketplace en Fi-Lab.

4.2 Aplicaciones desarrolladas 47

4.2 Aplicaciones desarrolladas

Salvo la aplicacin del mapa, basada en una implementacin sobre Google Maps presente en el catlogode Fi-Ware, todas las dems han sido concebidas y desarrolladas desde cero. An as, esta aplicacin hasido mejorada para ofrecer una visual mucho ms adecuada acerca de los sensores, mejorando adems elcomportamiento en cuanto a eficiencia y rendimiento del widget.

4.2.1 Mapa

Aprovechamos la implementacin del widgetMap Viewer presente en el Marketplace para adaptarla a nuestrasnecesidades. Inicialmente, este widget base no es ms que un mapa tpico de Google Maps sobre el queaparecern las entidades geoposicionadas. la visualizacin de un sensor desplegado es idntica a la queobtendramos posicionando un edificio o elemento del mapa interactivo de Google.

Figura 4.10 Visualizacin de puntos de inters en Google Maps.

Presentaremos el marcador de manera diferente, dando un toque personal y adecuado al proyecto. Estono es ms que referenciarle una nueva imagen. Al pulsar sobre el dispositivo, deber abrirse una ventanaemergente sobre la que aparezcan los datos relativos a ste.

Figura 4.11 Visualizacin inicial de sensores en Google Maps.

Lo que resultara interesante conseguir sobre esta ventana emergente (capa) es una visualizacin personali-zada sobre el tipo de entidad en concreto. Adems, podramos indicar algo ms de informacin relevante, talcomo mostrar un icono diferente en caso de una notificacin importante (p. ej. un nivel bajo de batera). Elresultado final es el que a continuacin se muestra.


Figura 4.12 Visualizacin final de sensores en Google Maps.

4.2.2 Histrico de lecturas

Teniendo en cuenta que hemos desarrollado el software necesario para registrar los datos generados en una ba-se de datos y tenemos posibilidad de acceder a ellos, implementar un motor de back-end sobre una aplicacinde Fi-Ware para recabar las lecturas y presentarlas como datos histricos hara que nuestra aplicacin tuvieseun mayor impacto. Esto es lo que se describe a continuacin. A travs de un motor PHP, obtenemos laslecturas y las presentamos sobre grficas Javascript en Fi-Ware. Construir esta aplicacin de manera genrica,y no concebida para un uso particular, permite que pueda ser utilizada para diferentes fines y no slo parauna aplicacin de sensrica, como es nuestro caso. As pues, esta es la filosofa que se ha seguido para eldesarrollo. Las grficas desarrolladas son responsive y ofrecen informacin de las lecturas parametrizada en:fecha, valor. Se han utilizado modelos similares a las grficas open-source Chart.js (http://www.chartjs.org/ ).

El primer tipo de grfica que se nos puede ocurrir representar es una en la que queden reflejadas las ltimaslecturas de cada uno de los sensores. Se debe tener en cuenta que estas lecturas no se han tomado en unambiente urbano, como es el emplazamiento final en que se espera se encuentren, sino controlado (habitacin,laboratorio...) por lo que las medidas no difieren unas de otras en demasa.

Figura 4.13 ltimas 15 lecturas registradas para diferentes sensores.

El otro tipo de grfica que se ha desarrollado es aquella que provee los valores de las lecturas mximas,medias y mnimas por da.

4.2 Aplicaciones desarrolladas 49

Figura 4.14 Grfico de valores mnimos, medios y mximos.

Tener al alcance de la mano esta informacin puede ayudar a tomar decisiones en pos de, por ejemplo,reconducir el trfico en una cierta zona por riesgo a sobrepasar valores mximos para un cierto contaminante.El anlisis de este big data y las actuaciones posteriores son las que realmente definirn la vala de este tipode soluciones.

4.2.3 Inspector de sensores

Resulta interesante poder obtener las ltimas lecturas de los diferentes sensores a modo de comparativa entrezonas, instantes de tiempo, o simplemente para echar un rpido vistazo a la informaci

Control de polución en Smart Cities mediante aplicaciones en FIWARE.pdf

Documents

Transcript of Control de polución en Smart Cities mediante aplicaciones en FIWARE.pdf