Desarrollo de software

pt5

Modulo de seguridad

linea

El módulo de seguridad abarca varias partes del software desarrollado. La parte de más bajo nivel es la Firma Digital mediante Certificado del software de la aplicación de ToT compilada. Esto ha sido una condición desde el principio del desarrollo, para evitar la suplantación del software por terceros. Firmar el código compilado significa que para que el sistema lo ejecute tiene que poder descifrarlo mediante la llave privada que lleva el sistema. En nuestro caso, todo software ejecutado en un de Apple debe de estar firmado digitalmente. Este es un requisito imprescindible para este tipo de dispositivos,  tanto para el desarrollo del mismo, hasta para subir el código en el Apple Store, el software debe estar firmado mediante un certificado que emite Apple.

A otro nivel otro posible problema de seguridad es el módulo de comunicaciones. El modulo de comunicaciones puede estar protegido a varios niveles. Desde el nivel de transporte de información, hasta nivel de red con una red encriptada. Desafortunadamente las redes en las que se puede encontrar una móvil puede ser de muchos tipos y no está en manos del desarrollador por lo tanto la seguridad se considera a varios niveles.

Tal y como está implementada la arquitectura la App de ToT hace un HTTPRequest a los servicios de ToT. Esta información en principio es accesible y publica. El sistema valida el formato de la información y si este formato no es el correcto lo descarta. La validación del formato tiene dos niveles.

El software se encarga de validarlo, si no puede decodificar la información (desde el punto de vista léxico y sintáctico) simplemente la descarta. El software intenta transformar el JSON en un Diccionario de diccionarios. Si el formato no es válido no sigue con el proceso de explotación de datos.

Cada otro lado cada URL Resquest que haga el módulo de comunicaciones debe de contener una key-code. Esta key es un valor alfanumérico codificado mediante una hash y es reconocida únicamente por los servicios de ToT. Esta key representa un servicio o un POI del cual se hace la consulta. Por ejemplo:

http://tot.ezentis.com/servicios/directories.json?negocio_id=I1oupPbtz9mD6fInHD4fz/zjj0s=&idioma=&idioma=es

Por ejemplo aqui ese está haciendo un URL Request al directorio del servicio / POI  cuya key es: I1oupPbtz9mD6fInHD4fz/zjj0s= En caso de que los servicios ToT no identifiquen la key, descarta la petición y la información solicitada.

Modulo de comunicación

linea

Este módulo es uno de los principales componentes de este software, fundamentalmente por dos requisitos. El primero es que la aplicación es de movilidad, ya que debe de estar contantemente en conexión con los servicios en la nube de ToT en una comunicación constante y fluida. El otro requisito tiene que ver con la arquitectura del sistema ToT. Para el proyecto ToT toda la lógica está en la parte de servicios. Cualquier aplicación tanto de móvil como de sobremesa o web no debería tener ninguna lógica asociada excepto la lógica de los componentes visuales y la interacción del usuario final. El módulo de comunicaciones sirve de interfaz entre el core de la aplicación móvil y los servicios en la nube de ToT. Por tanto trata de gestionar las consultas y trata los datos recibidos para adecuarlos al modelo de datos de la App de ToT. El modelo de datos es siempre una abstracción de los datos que pueden llegar de los servicios de la nube. Esto hace que el modelo de datos no dependa excesivamente del modelo de datos de los servicios, por lo que si en algún punto del desarrollo (o posteriormente) se cambian los servicios sólo habría que re-implementar esta parte, siendo relativamente soportar la modificación de los servicios y siendo completamente transparente al resto de la aplicación.

El módulo de comunicaciones accede a traves de llamadas HTTP Request a los servicios de ToT. La Transferencia de Estado Representacional (Representational State Transfer) o REST es una técnica de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web. El acceso es mediante HTTP  Request a traves del metodo GET, solo para recibir datos.Los datos de intercambio está realizado en los formatos JSON, acrónimo de JavaScript Object Notation, es un formato ligero para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos de  HTTP.

Módulo Semántico

linea

Hasta el momento se ha estado trabajando en un análisis de los mecanismos de persistencia existentes (se puede consultar en el E5.1) y se han analizado diferentes ontologías para estudiar su adecuación al contexto turístico en el que se enmarca el proyecto. A continuación se detallan algunos de los mecanismos de persistencia estudiados.

SESAME: Es un framework RDF, software libre desarrollado en Java, que soporta inferencia y búsqueda sobre RDF Schema y OWL. Fue diseñado para ser flexible, pudiendo trabajar sobre varios sistemas de almacenamiento (bases de datos relacionales, en memoria, en sistema de archivos, etcétera) con soporte transaccional, así como ofrecer una serie de herramientas para facilitar a los desarrolladores el aprovechamiento de los beneficios de RDF y RDFS, como una API de acceso a los datos que soporta comunicación local y remota (a través de RESTful HTTP), varios lenguajes de consulta (de los cuales SeRQL es, según los creadores de Sesame, el más potente) y diversos formatos de entrada y salida RDF. Puede ser utilizado como servicio como componente de otros sistemas.

Jena: es un framework en Java para construir aplicaciones de Web Semántica basado en las recomendaciones W3C. Provee una API de programación para almacenamiento (persistente y en memoria) y consultas mediante el uso de RDF, RDFS, OWL y SPARQL, e incluye un motor de inferencia basado en reglas para RDFS y OWL.

AllegroGraph: Se trata de una base de datos comercial, desarrollada para sistemas de 64 bits, persistente y de alto rendimiento para RDF. Posee soporte SPARQL, y razonamiento RDFS++ y Prolog, pero también integrable con el razonador RacerPro. Está orientada a aplicaciones en Java, Lisp, y acceso a través de HTTP y la herramienta TopBraid Composer, para crear y examinar ontologías. Denominada por sus autores “la base de datos de la Web 3.0”, añaden que su versión de 64 bits puede procesar del orden de 109 sentencias RDF.

3store: Es una biblioteca escrita en C que utiliza MySQL para almacenar datos RDF. Ofrece interfaces de búsqueda a través de OKBC [26] y RDQL, ambos sobre HTTP (a través de un módulo del servidor web Apache) o directamente a través de la biblioteca.

Actualmente puede manejar alrededor de 30 millones de sentencias RDF a través de una serie de Servicios del Conocimiento desarrollados por el proyecto AKT [27], además de ser utilizado por varias empresas externas.

Virtuoso: Es una plataforma creada por OpenLink Software concebida para integrar datos de empresa y una solución para gestión de procesos de negocio que implican SQL, RDF, XML y servicios web. La arquitectura híbrida del servidor permite comunicar diferentes funcionalidades, dentro de un producto único, a través de las siguientes características:

  • Gestión e integración de datos (SQL, XML y RDF).
  • Integración de aplicaciones (servicios web y SOA).
  • Gestión e integración de procesos (BPEL).
  • Aplicaciones distribuidas colaborativas.

El módulo semántico permitirá enriquecer los contenidos albergados en la plataforma ToT, de manera que puedan ser gestionados de forma más inteligente y eficiente. Este enriquecimiento semántico se llevará a cabo mediante ontologías.

Cabe destacar, que se ha dado una proliferación en el desarrollo de ontologías en los últimos años. Las ontologías se han diseñado por parte de centros de investigación, la propia industria turística y algunas universidades. CICtourGUNE ha elaborado además un análisis de ontologías. Las que se muestran en la siguiente lista son las ontologías más relevantes que se han encontrado en el dominio turístico.

  • Ontología QALL-ME (http://qallme.fbk.eu/index.php?location=ontology)
    • Proyecto Europeo
    • Objetivo: proporcionar una infraestructura común para responder a cuestiones multi-lenguaje y multimodales en el ámbito del turismo
    • Información proporcionada: destinos turísticos, sites turísticos, eventos turísticos y medios de transporte
    • Contiene 122 clases y 107 propiedades y está desarrollada en OWL DL
  • Ontología Harmonise
    • Desarrollada inicialmente en el ámbito del proyecto Harmonise, es el elemento central de la red harmoNET (Harmonisation Network of the Exchange of Travel and Tourism Information) que pretende crear una red internacional para la integración e intercambio de información turística.
    • Información proporcionada: eventos y alojamiento
    • Desarrollada en RDFS
  • Ontología Hi-Touch
    • Desarrollada en el proyecto europeo IST/CRAFT.
    • Objetivos:
    • Proporcionar metodologías basadas en tecnologías semánticas para un turismo intra-Europeo sostenible.
    • Formalizar el conocimiento sobre las expectativas de los viajeros y proporcionar, de esta manera, servicios turísticos personalizados.
    • Información proporcionada: objetos turísticos
    • Desarrollada en OWL
  • Ontología eTourism de DERI
    • Desarrollada por STI Innsbruck.
    • La ontología se centra en la descripción de alojamientos e infraestructura que permite al usuario encontrar la información deseada.
  • Ontología cDOTT (core Domain Ontology for Travel and Tourism)
    • Desarrollada por la Universidad Técnica de Viena, la Universidad Johannes Kepler de Linz y RHO Information Systems.
    • La ontología proporciona información “core” de turismo y, además, está vinculada con otras ontologías modulares que dan información sobre gastronomía, información geo-espacial, información temporal, información meteorológica, sobre alojamientos y sobre el usuario.
    • Desarrollada en OWL DL
  • Ontología Cruzar (http://idi.fundacionctic.org/cruzar/turismo.html)
    • Desarrollada por la Fundación CTIC
    • Ontología para la generación de rutas basadas en los perfiles y contexto de los turistas.
    • Información proporcionada: Turistas, Alojamiento, Monumentos, Rutas, etc.
    • Desarrollada en OWL
  • Ontología ebSemantics  (http://www.ebsemantics.net/doc/ )
    • Desarrollada por la fundación AUSTRIAPRO
    • Información proporcionada: Alojamiento, Eventos, Gastronomia.
    • Desarrollada en OWL
  • Especificación OTA
    • OTA: Open Travel Alliance. Los miembros de OTA son organizaciones que representan todos los segmentos de la industria de los viajes y del turismo, además de suministradores de servicios y tecnología.
    • Tiene alrededor de 140 documentos XML Schema que se corresponden con eventos y actividades en varios sectores turísticos.

En base al análisis de los términos que aparecen en las ontologías arriba mencionadas, se ha establecido la siguiente taxonomía referente a una clasificación de puntos de interés que puedan ser gestionados por la plataforma. A continuación se establece la jerarquía de contenidos resultante.

  • Hostelería
    • Bar
      • Piano bar
      • Discoteca
      • Pub
    • Cafetería
    • Heladería
    • Restaurante
      • Comida rápida
      • Buffet
      • Cocina de autor
      • Temático
        • Comida china
        • Comida Mexicana
        • Comida italiana
        • Comida francesa
        • Comida oriental
        • Vegetariano
      • Take Away
      • 1 tenedor
      • 2 tenedores
      • 3 tenedores
      • 4 tenedores
      • 5 tenedores
  • Alojamientos
    • Albergue
    • Apartamentos turísticos
    • Balnearios
    • Camping
      • Lujo
      • Primera
      • Segunda
      • Tercera
    • Casa rural
    • Establecimientos hoteleros
      • Hoteles
        • 1 estrella
        • 2 estrellas
        • 3 estrellas
        • 4 estrellas
        • 5 estrellas
      • Pensiones
        • 1 estrella
        • 2 estrellas
      • Apartahoteles
        • 1 estrella
        • 2 estrellas
        • 3 estrellas
        • 4 estrellas

 

  • Atracciones
    • Entretenimiento
      • Aquarium
      • Parque acuático
      • Parque temático
      • Cine
      • Teatro
      • Zoo
      • Museo
      • Espectáculo nocturno
    • Natural
      • Cueva
      • Jardín
      • Parque nacional
      • Playa
        • Cala
      • Monte
      • Sendero
    • Arquitectura
      • Edificio histórico
      • Edificio religioso
      • Plaza
      • Monumento
    • Infraestructura
      • Alquiler de coches
      • Banco
      • Cajero automático
      • Centro comercial
      • Supermercado
      • Comisaría de policía
      • Gasolinera
      • Hospital
      • Ambulatorio
      • Oficina de correos
      • Oficina de turismo
    • Instalaciones Transporte
      • Aeropuerto
      • Estación de autobús
      • Estación de tren
      • Parada de autobús
      • Parada de metro
      • Parada de taxi
      • Puerto
      • Parking gratuito
      • Parking de pago

Modulo de procesado de señal CMOS

linea

Compatibilización de la PiCamera con las librerías de OpenCV

La complejidad de compatibilización de la Picamera parte de que no se trata de conexión USB y por lo tanto en protocolo de comunicación que utiliza es totalmente diferente. Se trata de una conexión a un puerto CSI. A pesar de que es posible acceder a la Picamera utilizando las librerías MMAL y V4L, estas no permiten el tratamiento a posteriori de las imágenes con las librerías de OpenCV. Tras numerosos intentos de compatibilización dimos con una serie de librerías que permitían la conjunción de las anteriores, entre las cuales se encuentran las librerías U4L o PIL.

Estudio y aplicación de coordenadas de color

Se ha investigado la utilización de diferentes clasificaciones de color como el HSV, del inglés Hue-Saturation-Value (Matiz-Saturación-Valor) (Figura 4).

HSV es un sistema cilíndrico de coordenadas de color utilizado para representar los colores de la escala RGB desarrollado inicialmente para aplicaciones de computación gráfica. Este sistema de coordenadas pretende ser más intuitivo. La tercera coordenada corresponde con la luminancia y da un valor al brillo o la intensidad del color, como puede observarse en la figura anterior.

Los sistemas HSV y similares son comúnmente usados en detección de formas, reconocimiento de objetos, segmentación de imágenes, de aquí el interés para el proyecto. En general, los algoritmos de visión artificial están desarrollados para tratar imágenes en escala de grises. A la hora de llevar a cabo el seguimiento de un objeto, éste debe ser fácilmente distinguible en la escala de color. Las componentes de color en la escala RGB de un objeto están correlacionadas y esto los hace difícilmente distinguibles en términos de estas componentes, R, g y B. Por el contrario, la descripción de objetos mediante sus coordenadas HSV es más unívoca.

fg4

En primer lugar, en nuestro caso hemos representado una imagen ejemplo en el sistema de coordenadas de color HSV. Como se puede observar, la imagen correspondiente a cada coordenada es totalmente diferente. Estas primeras pruebas fueron de carácter orientativo y para ver de qué forma podrían ser útiles estas coordenadas de color. No hay que olvidar que uno de los requisitos más importantes del dispositivo es el cumplimiento de la Ley Orgánica de Protección de Datos. Como puede observarse en las figuras, las coordenadas H y S de la imagen no ofrecen características que permitan el discernimiento de los individuos observados, Figura 5. De este modo, estas dos coordenadas serían susceptibles de ser utilizadas para nuestra aplicación. Por el contrario, la coordenada V preserva la imagen casi de forma absoluta, lo cual la haría inútil en nuestra aplicación, al no preservarse el anonimato de los individuos observados.

fg5

Desarrollo de los algortimos y utilización de los mismos contemplando la posibilidad de utilizar la PiCamera

En la aplicación definitiva no va a utilizarse una imagen en color sino una imagen en escala de grises obtenida mediante la aplicación de una serie de funciones específicas de OpenCV. En la Figura 6 se muestra un extracto de un ejemplo del código generado en este proyecto:

fg6

La imagen a tratar es una imagen binaria en la cual el blanco corresponde a las zonas donde se ha producido movimiento y el negro a las zonas en las que no se ha producido movimiento.

La serie de algoritmos utilizados se han probado en entorno de laboratorio. En primer lugar se ha utilizado una cámara CMOS Logitech C170, que fue la cámara que fue seleccionada para utilizarla con la placa procesadora Minnowboard. A continuación se muestran varias imágenes obtenidas donde se han simulado en entorno de laboratorio el paso de peatones por la escena utilizando unas esferas, Figura 7, Figura 8 y Figura 9. Como puede observarse, el algoritmo detecta el movimiento y produce manchas de color blanco en los lugares donde se ha producido. Estas manchas, llamadas “blobs” en inglés serán posicionadas en cada instante y su movimiento monitorizado. De esta forma se hará el registro del paso de peatones a través de la escena.

fg7

fg8 fg9

Se ha postulado el seguimiento de las manchas mediante la utilización de un algoritmo basado en la función “GoodFeaturestoTrack” de OpenCV y otras funciones, Figura 10. Esta función realiza una búsqueda de los puntos de la imagen susceptibles de ser unívocos al seguimiento. En nuestro caso, ya que la imagen es binaria, los mejores puntos a los que anclar un seguimiento son los bordes de las manchas blancas, dónde el contraste es máximo. La adquisición de puntos a seguir se calibrará para que únicamente se considere un punto por cada peatón/mancha en la escena.

fg10

Módulo de geoposicionamiento

linea

Para realizar la geo localización el consorcio en un primer planteamiento se decantó por la tecnología RFID implantadas en forma de pulseras. Esta tecnología ha sido desestimada por el consorcio para ser sustituida por tecnología Wifi.

El  trabajo realizado por UCM/IMA en relación a las pulseras RFID y su utilización como sistemas de geo-localización sirve como justificación del trabajo realizado por UCM/IMA en este punto del proyecto.

Para realizar el geoposicionamiento se utilizarán dispositivos con conectividad a la red inalámbrica, de esta forma, se aprovechan de manera más eficiente los recursos generados por el proyecto.

Módulo de análisis y estadísticas

linea

fg11El módulo de análisis y estadística forma parte fundamental del proyecto TOT. Se encarga del tratamiento de la información para la obtención de resultados. Dependiendo de éstos resultados se puede variar contenidos y servicios prestados en función del perfil de Turista o las rutas propuestas en función del balanceo del flujo de turistas por todas las zonas de la región turística. Tal y como está planteado ToT toda la lógica proviene del los servicios en la nube, por lo tanto las información recabada se debe procesar en estos servidores, por lo que desde el punto de vista de las aplicaciones que hagan uso de los servicios de ToT. tiene que tener en cuenta dos consideraciones soportar  el envió de información al los servidores y que estos datos a enviar puede cambiar en cualquier instante.

Esto tiene implicaciones en el diseño y la arquitectura del software, es decir en ToT  no solo puede cambiar las respuestas del usuario, sino también las preguntas. Y todo esto puede cambiar el cualquier momento y en tiempo real. Por lo que el software tiene que estar preparado para ello. Desde la APP de todo hay un pequeño cuestionario para que el turista lo rellene y se pueda beneficiarse de una experiencia turística basada en sus gustos y su perfil. Por lo que la App de ToT está preparada para recoger información de carácter no personal del turista. Se trata de un pequeño cuestionario para definir sus gustos pudiendo personalizar las propuestas del sistema. Asimismo la información se puede usar para estudiar gustos según perfil, otros estudios.  Se trata de un conjunto de preguntas categorizadas. Las preguntas pueden ser de tres tipos en funciones de sus respuestas.

Preguntas numéricas, cuya respuesta es un número. Booleanas, cuya respuesta es un ‘Sí’ o un ‘No’, o de varias opciones de respuesta. Desde los servicios de TOT se puede crear/modificar una pregunta modificando su tipo, su categoría y si es necesario la lista de opciones de respuesta. El resultado de un cambio se vería inmediatamente en la App del usuario.

Módulo de servicios al turistas

linea

Aplicaciones en realidad aumentada

fg12Dentro de las aplicaciones de ToT, está considerada las aplicaciones de Realidad Aumentada. Estas aplicaciones, están todavía en sus inicios  pero supondrán en un futuro no muy lejano una manera de interactuar con los sistemas integrados de una manera más natural. La realidad aumentada está todavía en fase de desarrollo en el proyecto móvil ToT. Está previsto en la App móvil un módulo de Realidad Aumentada gracias a tres inputs. Los servicios en la nube de ToT nos proporcionan información de los POIs, su posicionamiento, altitud, longitud y altura sobre el nivel del mar. Los dispositivos actuales poseen un sistema de posicionamiento, un sistema GPS (Sistema de Posicionamiento Global) junto a las triangulación de torres GSM y Wifi nos dan un posicionamiento bastante exacto. Además el dispositivo móvil cuenta con un magnetómetro que permite calcular la orientación geográfica del mismo. Asimismo un inclinómetro de tres ejes nos permite saber cuál es la orientación espacial del dispositivo. Por último el reconocimiento de Imágenes.

En este punto se ha implementado un lector de códigos QR en tiempo real mediante la cámara del dispositivo. Se trata de un analizador de imagenes en tiempo real  que es capaz de leer códigos de barras y códigos QR. Un codigo QR no es más que una imagen que almacena informacion en una matriz de puntos.

La imagen está confeccionada para facilitar lectura para un computador mediante de un algoritmo de reconocimiento de imágenes. La aplicación decodifica estos códigos mediante la camara que incorpora en tiempo real. Esta imagen puede estár en los POIs o servicios y puede ser una forma de interactuar, obtener una información extra o conseguir algún descuento especial.

Guía interactiva

fg13Para facilitar la orientación in-situ del turista se ha desarrollado un mapa guia- interactivo con la posición del mismo y los POI puntos de interés turísticos junto a los servicios. Se trata de un complejo mapa callejero donde el turista puede ver con la perspectiva deseada su posición y puntos alrededor con el detalle deseado, la zona ampliada o concreta mediante eventos gestuales, asi como la navegación por el mismo.

El mapa tambien se encarga de mostrar la ruta seleccionada, además de permitir crear ruta al usuario.

simismo tiene una serie de opciones de centrado. El mapa se puede centrar en la posición del turista o en los servicios de la zona o en los Puntos de Interés turísticos. Asimismo se puede seleccionar servicios o POI en función de su categoria. Se puede elegir en cualquier momentos que categorias ver y cuales no.  Debido a que la zona puede tener un numero muy grande de POI o servicios podemos acotar el numero de POIs mostrados en el mapa.

Geo-localización Inteligente

El módulo de geo-localización inteligente surge en un nuevo escenario de movilidad dentro del marco de la ciudad inteligente del futuro. Una ciudad inteligente o Smart City, concebida como un espacio urbano con infraestructuras, redes y plataformas inteligentes, con millones de sensores y actuadores. Un espacio capaz de escuchar y comprender lo que está pasando en la ciudad, permitiendo la toma de decisiones y proporcionando la información y los servicios adecuados a sus habitantes. En una Smart City la información adecuada llega en el momento preciso, integrando así “digitalmente” las personas y cosas del entorno. De esta forma, los espacios digital y físico se recombinan en la ciudad en beneficio del ciudadano y turista conectado.

Impulsada por esta concepción de la Smart City, y en un dominio más concreto como el que corresponde al Smart Destination, se avecina una nueva revolución tecnológica que proporcionará un innovador abanico de dispositivos, infraestructuras y servicios para dar soporte a la movilidad de los habitantes y visitantes de las ciudades del futuro. Un ejemplo son los dispositivos “wearables“ o vestibles, que cambiarán el concepto de movilidad que tenemos hoy en día de la mano de los smartphones. Este tipo de dispositivos proporcionarán nuevas formas de acceso a la información, interacción y comunicación las 24 horas del día, 365 días al año. El reto ahora es proporcionar servicios de nueva generación adaptados a esta nueva gama de dispositivos móviles y wearables, que sirvan para cubrir las necesidades de las personas que conviven en la Smart City y los turistas que la visitan.

Descripción del módulo de geo-localización inteligente

El módulo de geo-localización inteligente diseñado e implementado por CICtourGUNE como responsable, tiene como objetivo poder obtener datos sobre la localización de los turistas en movilidad, con el fin de poder proporcionar información adaptada a su contexto. Este contexto, además de por los datos de localización, está compuesto por la fecha y la hora del día. Estos tres parámetros son los que se han tenido en cuenta a la hora de diseñar la plataforma de geo-localización.

Esta plataforma ha sido dotada de un entorno web donde los programadores pueden configurar envíos “push” proactivos y en tiempo real de contenidos (texto, fotos, vídeos, etc.) a dispositivos móviles, en base a los parámetros del contexto del usuario. Estos parámetros se configuran en función de reglas lógicas, que tienen en consideración tanto la localización del usuario en función de áreas geográficas determinadas, tanto en exteriores como en interiores, así como rangos de fecha y hora.

Se han desarrollado además librerías software (SDK) para Android e iOS que pueden ser embebidas en los servicios móviles turísticos a ser desarrollados. Estas librerías facilitan al programador el uso de las diferentes funcionalidades ofrecidas por la plataforma de geo-localización. La solución implementada también ofrece informes sobre el comportamiento de los usuarios de este tipo de servicios en base a la monitorización de su movilidad.

Gracias a la plataforma, un nuevo abanico de servicios móviles pueden ser abordados con suma facilidad, abstrayendo a las empresas de base tecnológica de la complejidad técnica que conllevan este tipo de soluciones sensibles al contexto. Servicios que informen del tiempo estimado de llegada del siguiente bus al reloj del usuario cuando llega a la parada, servicios de atención sanitaria continua y a distancia, ofertas personalizadas dentro de un centro comercial, alertas de tráfico en tiempo real o servicios que muestren en las gafas de un pasajero que acaba de llegar al aeropuerto información sobre la puerta de embarque estarán más cerca de convertirse en una realidad.

Arquitectura de la plataforma

La arquitectura planteada se divide en cuatro diferentes capas que se abstraen de capas inferiores para proporcionar una funcionalidad global, tal y como se recoge en la siguiente figura.

fig11

Fuentes de contexto

Las fuentes de contexto son todos aquellos sensores y dispositivos capaces de proporcionar los datos de contexto necesarios para realizar el envío de información a los dispositivos de los usuarios. En este caso concreto, la plataforma utiliza la información proveniente de los dispositivos, como un identificador anónimo del usuario, y su localización. Esta localización se obtiene en espacios abiertos gracias al GPS que llevan incorporado este tipo de dispositivos. En entornos cerrados, se hace uso de la tecnología iBeacon para poder procesar la localización del usuario. Esta tecnología se compone de dispositivos emisores de señal Bluetooth, que pueden ser posicionados en cualquier lugar (museos, supermercados, aulas, etc.) y que son capaces de detectar la proximidad de un dispositivo móvil o “wearable”. De esta forma, si se sitúa uno de estos dispositivos en un entorno cerrado, la infraestructura podrá conocer su localización aunque no se disponga en dicho entorno de cobertura GPS. Se han utilizado los iBeacon de Estimote [1] que proporciona un pack de 3 dispositivos Bluetooth. La plataforma es capaz de gestionar la disponibilidad de este tipo de dispositivos en entornos cerrados para conocer la localización de los usuarios. Además, se utilizan tanto la fecha como la hora para poder utilizarlas como parámetros de contexto adicionales. Existe también la posibilidad de incorporar nuevas fuentes de contexto de una forma sencilla, gracias a la flexibilidad que ofrece el API de la siguiente capa, la capa de Procesamiento.

[1] Estimote. http://estimote.com/ Último acceso 13/05/2014

fg122

Procesamiento

Esta capa dispone de un API o interfaz de programación, por el que la plataforma puede ampliar su abanico de fuentes de contexto de una forma sencilla. Simplemente hará falta que el dispositivo esté conectado a Internet y utilice el API diseñado para enviar datos de contexto. Así, fuentes que proporcionen datos adicionales referentes al tiempo meteorológico, niveles de ruido, ocupación de plazas de parking, etc. podrán ser añadidas a la infraestructura de una manera fácil. Además, esta capa dispone de un módulo de datos, que se encarga de representar los datos provenientes de las fuentes de contexto de una forma que pueda ser gestionada por computadores. Esto se realiza en base a un modelo de datos predefinido. Esta capa de procesamiento hace uso también de un módulo GIS, donde reside una base de datos geoespacial, con el fin de convertir las coordenadas de los usuarios en movilidad, en áreas concretas y determinadas (barrios, plazas, etc.).

Gestión

La capa de gestión es la más compleja de todas. En esta capa se almacenan y gestionan todos los datos recogidos tanto en bases de datos (BD) como en memoria, utilizando una base de conocimiento (KB) que utiliza algoritmos de inteligencia artificial y técnicas Big Data para procesar la gran cantidad de datos que llegan a la nube. Las reglas de contexto se definen mediante la interfaz de usuario (UI). Cuando una de las reglas definidas se cumple, se envía la información asociada al dispositivo del usuario gracias al módulo de envíos push.

La interfaz de usuario es un entorno web, que posibilita la creación de reglas en base a la localización del usuario, fecha y hora. Así, se pueden definir áreas circulares de diferentes diámetros, con el fin de definir localizaciones concretas en las que se quiere detectar al usuario para enviar una información determinada a su dispositivo (es lo que se denomina como geofencing[1]).

[1] Wikipedia. http://en.wikipedia.org/wiki/Geo-fence Último acceso 13/05/2014

fg133

Además, se proporcionan sencillos controles que posibilitan la configuración de las reglas para el envío de información. En la imagen a continuación, se muestra un pequeño ejemplo de controles proporcionados por la interfaz, con los que el programador usuario de la infraestructura o plataforma puede especificar las condiciones de contexto para enviar una determinada información al dispositivo del usuario. Estos controles permiten definir que la primera vez (o siempre) que el usuario entre (o salga) de un área previamente creada sobre el mapa, entre un rango de fechas determinado y un rango de horas determinado, se envíe al dispositivo una determinada información.

fg14

La plataforma también proporciona un API externo que los programadores pueden utilizar para realizar las mismas configuraciones de forma programática, sin tener que utilizar la interfaz de usuario. Esto da una mayor flexibilidad a la hora de incorporar la plataforma de geo-localización en soluciones propietarias de las empresas tecnológicas usuarias de la infraestructura.

Finalmente, en esta capa se encuentra el módulo de analítica que es el responsable de procesar los datos referentes a la localización de los usuarios en movilidad, para ofrecer a la capa de interfaz de usuario visualizaciones de los flujos de movilidad de los usuarios. Este módulo permite visualizar en un rango de fechas y por cada área creada, las notificaciones push enviadas a los usuarios por cada área definida en el sistema, así como el número de notificaciones enviadas en relación al número de usuarios.

fg15

Servicios

Finalmente, se encuentra la capa de servicios que los programadores de las empresas de base tecnológica podrán crear gracias a esta infraestructura. La plataforma les proporciona todas las funcionalidades más complejas a la hora de gestionar la información de contexto y proporcionar servicios adaptados a las necesidades de las personas en cada momento y lugar.

Tal y como se ha dicho anteriormente, para poder desarrollar los servicios o apps, los programadores cuentan con un SDK o kit de desarrollador para incorporarlos a los servicios que se quieran desarrollar y poder integrarlos con las capacidades de la plataforma de geo-localización. Gracias a este SDK integrable en todas las principales plataformas de Smartphone y dispositivos “wearable”, la plataforma puede obtener los datos referentes a la localización del usuario de forma totalmente transparente para el programador y usuario, y podrá integrarse con el módulo de geo-localización con cualquier servicio o app que se quiera desarrollar. El SDK también facilita la recepción de los envíos de información push realizados por la plataforma en base al contexto determinado de los usuarios, por lo que facilita la gestión de los mismos al programador.

Módulo de analítica

Además de la información accesible dentro de la plataforma web, se ha creado un apartado de informes donde se visualizan a través de gráficos descriptivos los datos de la muestra recogida, permitiendo así analizar mejor el patrón de comportamiento de los visitantes en base a su detección en las diferentes áreas definidas en la plataforma.

fg16

Esta visualización puede segmentarse en base a un rango temporal establecido y a las áreas seleccionadas. La información que contemplan estos informes se divide en dos bloques.

  • Análisis de áreas por notificaciones recibidas: realiza un estudio comparativo de áreas a las cuales han sido enviadas las notificaciones en base al periodo temporal y áreas seleccionadas. Por ejemplo, analizando la figura 1 se puede observar que el día 2 de octubre el área con más notificaciones recibidas fue el área “Unibertsitatea”.

Análisis de usuarios por notificaciones recibidas: realiza un estudio del número de usuarios distintos a los cuales se les ha mandado alguna notificación en base al periodo temporal y áreas seleccionadas. Este análisis permite conocer si la cantidad de notificaciones enviadas corresponde con el número de usuarios únicos a los que se ha mandado la notificación. Es decir, como se puede observar en la figura siguiente, el día 7 de octubre se recibieron 131 notificaciones pero solo hubo 5 usuarios únicos, lo cual implica que esos usuarios recibieron repetidas veces las mismas notificaciones respecto a una misma área.

fg17

NFC 

NFC, es una tecnología inalámbrica, de corto alcance que permite el intercambio de datos entre dispositivos. Alrededor del año 2004 se empezó a definir la tecnología y los futuros usos que podría proporcionar. No obstante, hasta hace unos dos años no se ha popularizado su inclusión en algunos Smartphones. Los dispositivos de alta gama ya incorporan NFC pero no termina de convertirse en algo habitual. Esta tecnología permite identificar al propio usuario, tener el abono de transporte en el móvil, recibir información de forma inmediata e incluso pagar con el móvil.

La tecnología NFC no ha sido adoptada lo suficiente en el mercado estatal, ya que se necesita apoyo de los bancos y de los transportes públicos. Para ello, los bancos deben implantar NFC en las tarjetas de crédito para poder realizar pagos. Respecto a los transportes públicos, si implantasen esta tecnología ayudarían a no desperdiciar papel en los billetes y permitiría agilizar las operaciones. Teniendo en cuenta esta situación, esta tarea queda pendiente de nuevo planteamiento.

ERP linea

Del inglés (Enterprise Resource Planning) es el sistema de planificación de recursos empresariales.

Bajo un concepto tan amplio cabe primero definir qué es lo que va a ser en este proyecto el (ERP).

Un sistema de administración de los recursos y su interacción administrativa mediante un software de gestión.

Los Recursos en este proyecto son los proveedores  “El Destino” con sus integrantes y su oferta tanto a nivel público como privado y por  otra parte los consumidores,  “El Turista” y a la vez por el circulo de la información otra vez “El Destino”.

El modelo de datos del ERP ya está tratado en el apartado T3.5 del PT3 (Diseño funcional y de arquitectura).

fg23

ARQUITECTURA

Para este proyecto se ha optado por una  arquitectura CQRS (Command Query Responsability Segregation).

fg24

Se han empleado Comandos y Consultas con responsabilidades diferenciadas.

Se ha optado por este tipo de arquitectura que permite un despliegue en la “Nube” mucho más modulable y escalable.

SERVIDOR

Desde el lado del servidor se han realizado las siguientes tareas:

  • Creación de la BBDD según el modelo expuesto.
  • Creación de la Infraestructura con el Framework de MS .Net.
  • Creación de los Servicios Web de comunicación con las aplicaciones cliente.

CLIENTE

Durante el 2013 se ha trabajado sólo en la parte del servidor. Se espera comenzar con el cliente en Enero-Febrero 2014. 

MAPA DE LIBRERIAS

A continuación se muestra el Mapa de Librerías

fg25