-
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
Proyecto Fin de CarreraIngeniera de Telecomunicacin
Control de polucin en Smart Citiesmediante aplicaciones en
FIWARE
Autor: Miguel ngel Cao RojanoTutor: Jos Ramn Cerquides Bueno
Dep. Teora de la Seal y ComunicacionesEscuela Tcnica Superior de
Ingeniera
Universidad de Sevilla
Sevilla, 2015
-
Proyecto Fin de CarreraIngeniera de Telecomunicacin
Control de polucin en Smart Citiesmediante aplicaciones en
FIWARE
Autor:
Miguel ngel Cao Rojano
Tutor:
Jos Ramn Cerquides BuenoProfesor Titular
Dep. Teora de la Seal y ComunicacionesEscuela Tcnica Superior de
Ingeniera
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.
-
6 Captulo 1. Fi-Ware
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
-
8 Captulo 1. Fi-Ware
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.
-
10 Captulo 1. Fi-Ware
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.
-
14 Captulo 2. Eleccin de dispositivos
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.
-
2.2 Factores involucrados 15
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.
-
16 Captulo 2. Eleccin de dispositivos
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
-
2.2 Factores involucrados 17
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.
-
18 Captulo 2. Eleccin de dispositivos
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.
-
2.2 Factores involucrados 19
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
-
20 Captulo 2. Eleccin de dispositivos
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.
-
22 Captulo 2. Eleccin de dispositivos
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.
-
24 Captulo 2. Eleccin de dispositivos
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
-
26 Captulo 2. Eleccin de dispositivos
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.
-
30 Captulo 3. Desarrollo del software para dispositivos de la
red
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.
-
32 Captulo 3. Desarrollo del software para dispositivos de la
red
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.
-
34 Captulo 3. Desarrollo del software para dispositivos de la
red
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
-
36 Captulo 3. Desarrollo del software para dispositivos de la
red
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
-
3.4 Conexin con Fi-Ware y almacenamiento en BBDD 37
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
-
38 Captulo 3. Desarrollo del software para dispositivos de la
red
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.
-
3.4 Conexin con Fi-Ware y almacenamiento en BBDD 39
//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
-
44 Captulo 4. Desarrollo de aplicaciones en Fi-Ware
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.
-
46 Captulo 4. Desarrollo de aplicaciones en Fi-Ware
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.
-
48 Captulo 4. Desarrollo de aplicaciones en Fi-Ware
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