Investigacion en la seguridad de los Juguetes - MEMORIA … · 2016-12-16 · 2. Introducción a la...

API4Toys Desarrollo e incorporación de elementos interactivos basados en el

internet de los juguetes para el aprendizaje adaptativo mediante el juego.

Nº Expediente: IMDECA/2015/8

PROGRAMA: PROYECTOS EN COLABORACIÓN

ACTUACIÓN: IMDECA - Proyecto de I+D en colaboración

Fecha de concesión: 23/10/2015

Entregable 4.1 (E4.1)

Arquitectura de sensibilidad al contexto para el campo del juguete.

T.4.1. Diseño de la arquitectura global de sensibilidad al contexto.

Perteneciente al paquete de trabajo: PT4

Participante responsable: ITI

Mes estimado de entrega: Mes 8

ENTREGABLE 4.1 PÁGINA 2 de 31

Tabla de Contenidos

1. Introducción ................................................................................................................................. 4

1.1. Objetivos del paquete de trabajo 4 ........................................................................................... 4

1.2. Objetivo del presente documento (E4.1) ................................................................................... 4

2. Introducción a la arquitectura ...................................................................................................... 4

2.1. Arquitecturas hardware .............................................................................................................. 5

3. Análisis de protocolos de comunicaciones .................................................................................... 5

3.1. RFID........................................................................................................................................... 6

3.2. NFC ............................................................................................................................................ 6

3.3. WiFi ........................................................................................................................................... 7

3.4. WiFi Direct ................................................................................................................................ 8

3.5. Bluetooth .................................................................................................................................. 8

4.5.1 Bluetooth estándar ............................................................................................................ 9

4.5.2 Bluetooth Low Energy ...................................................................................................... 10

4.5.3 Bluetooth Dual/Bluetooth Smart Ready .......................................................................... 11

4. Tecnologías, soluciones y plataformas comerciales existentes ................................................... 12

4.1. Visible Light Communication ..................................................................................................... 12

4.2. Lego Mindstorms ...................................................................................................................... 13

4.3. Calipso ....................................................................................................................................... 14

4.4. BeeWi ........................................................................................................................................ 14

4.5. Smart Toy .................................................................................................................................. 15

4.6. Anki ........................................................................................................................................... 16

4.7. Kiteracy ..................................................................................................................................... 17

4.8. Karendon ................................................................................................................................... 17

4.9. Patente Google juguete interactivo .......................................................................................... 17

4.10. Project Legion............................................................................................................................ 18


5. Análisis de requisitos .................................................................................................................. 18

6. Análisis comparativo de tecnologías de comunicación y elección para la arquitectura ............... 20

7. Arquitectura ............................................................................................................................... 24

8. Ejemplos de casos de uso ........................................................................................................... 27

8.1. Un juguete – un dispositivo ..................................................................................................... 27

8.2. Varios juguetes – un dispositivo .............................................................................................. 28

8.3. Diagrama de flujo .................................................................................................................... 29

9. Referencias bibliográficas ........................................................................................................... 31


1. Introducción

1.1. Objetivos del paquete de trabajo 4

Los objetivos de este paquete se centran en la definición, diseño e implementación de una arquitectura de sensibilidad al contexto aplicada al campo del juguete y la comunicación hacia un equipo o dispositivo móvil. Esta información permitirá posteriormente ser utilizada para su análisis en búsqueda de patrones de juego y del uso del propio juguete en aquellos contextos que los desarrolladores desean conocer para dotar de nuevas adaptaciones al juguete.

Son objetivos específicos de este paquete:

La definición y diseño de una arquitectura global de sensibilidad al contexto aplicada al campo del juguete.

La implementación de la propia arquitectura tanto en el dispositivo como en la parte hardware del juguete.

La definición de un API que permita a los desarrolladores del campo del juguete crear productos sensibles al contexto.

1.2. Objetivo del presente documento (E4.1)

Esta tarea se encarga de definir una arquitectura de recogida de datos que pueda ser aplicada al campo del juguete y que permita obtener diversa información útil de cara a su posterior análisis y procesado para la extracción de información contextual. Previo a este diseño se ha realizado el análisis del estado del arte en tecnologías de comunicaciones y plataformas para juguetes, y el estudio de necesidades y requisitos, que se resumen también en este documento.

2. Introducción a la arquitectura

El diseño de una arquitectura que de soporte al intercambio de datos entre los elementos del juego es de especial de interés. De la buena elección y diseño de tecnologías, protocolos, paradigmas y aplicaciones dependerá tanto la facilidad de construcción de aplicaciones sobre la misma como las mayores capacidades para su mantenimiento, ampliación e interoperabilidad con otras soluciones. Por tanto, debe analizarse con detalle las distintas posibilidades que se presentan para poder realizar este diseño de arquitectura, eligiendo entre la adopción de tecnologías existentes que pueden agilizar el desarrollo o bien el empleo de una solución completamente nueva que este adaptada totalmente a las necesidades de la aplicación final.

En este documento se presentan diferentes tecnologías y soluciones existentes que pueden ser empleadas para la definición de la arquitectura del proyecto con el objetivo de analizar sus ventajas e inconvenientes, sirviendo así de base para el diseño. Una vez presentadas estas soluciones se procede a describir el diseño de la arquitectura a adoptar en el proyecto, realizando una descripción básica de la misma, permitiendo de este modo ser el paso preliminar de cara al comienzo detallado de la implementación de la propia arquitectura.


2.1. Arquitecturas hardware

Tratando de conocer más a fondo los diferentes dispositivos hardware que más adelante se enunciarán, cabe destacar los 2 tipos de arquitecturas que se utilizan para el control de los dispositivos: arquitectura centralizada y distribuida [TiposArquitectura]. La arquitectura centralizada está basada en que el control se encuentra en una localización central, usando dispositivos conectados a un dispositivo central. De esta forma, el dispositivo central podrá controlar todos los dispositivos directamente. Ofrece mayor seguridad sobre los sistemas con arquitecturas descentralizadas, debido a que todo el proceso es controlado centralmente. En el caso de que un dispositivo fallara o se dañara, se podría utilizar otro dispositivo dentro de la misma red, y todos los archivos o recursos seguirán siendo accesibles. Como principales ventajas destaca que se trata de un sistema con un solo punto de control, que posee una mayor capacidad de control de seguridad y protección de la información. Es fácil de mantener, ya que el soporte sólo se ha de aplicar en el dispositivo central. Sin embargo sus principales desventajas son que la interfaz de usuario puede llegar a ser muy simple y poco atractiva, debido a que el uso de la red será amplia. La velocidad de respuesta también puede llegar a ser un problema, ya que será lenta, dependiendo de la conexión que tenga la red central. Se deben de hacer copias de seguridad en intervalos cortos de tiempo, ya que si cae el dispositivo central caerá toda la red a nivel general. Y otro agravante a tener en cuenta es la ampliación de la red, ya que el crecimiento estará sujeto a la capacidad del dispositivo central.

Por otra parte, una arquitectura distribuida trata de una disposición de los dispositivos separados físicamente, y conectados entre sí por una red de comunicación distribuida. Cada usuario poseerá su propio dispositivo, y contará con un software común para todos los demás usuarios, de esta forma, el usuario podrá acceder a los recursos remotos (RPC) de la misma forma en que acceda a recursos que se encuentren en local, o un grupo de dispositivos que utilicen un software cuyo objetivo es común. Los sistemas distribuidos tienen que ser muy fiables, debido a que si un componente del sistema cayera, otro dispositivo debería tener la capacidad de reemplazarlo. Sus principales ventajas son el aumento de fiabilidad en el sistema, es decir, un sistema más confiable, ya que si uno de los sistemas falla, los demás sistemas podrán seguir funcionando perfectamente. El crecimiento del sistema no supondrá ningún problema. Se podrá realizar copias de seguridad en cualquier dispositivo del sistema, sin miedo a perder nada. También se podrá utilizar una interfaz atractiva y amigable. Y destacar que la velocidad de respuesta será rápida, ya que los datos se encontrarán dentro de una red local. Por el contrario, las principales desventajas que podemos encontrar en un sistema distribuido son que los soportes o actualizaciones deberán de realizarse de forma local, es decir, dispositivo por dispositivo. Se puede crear una red excesivamente amplia, lo que provocaría una mala distribución de los datos. La seguridad de los datos será más vulnerable, ya que será más difícil de controlar.

3. Análisis de protocolos de comunicaciones

Paso previo a la definición y diseño de una arquitectura de comunicación deben estudiarse cuales son los protocolos y estándares existentes en esta materia que serán integrados dentro de la arquitectura. Actualmente podemos encontrar muchos protocolos de comunicación que


pueden ser potencialmente útiles para la arquitectura específica de comunicación en el campo del juguete que se pretende desarrollar. En esta sección describimos algunos de las más relevantes y que nos servirán posteriormente para realizar la elección más adecuada.

3.1. RFID

RFID [RFID] es el acrónimo de “Radio Frequency IDentification”. Esta tecnología emplea tags o etiquetas que permiten almacenar y recuperar información. Las etiquetas son pequeños elementos de tamaño reducido que son adheridas a ciertos elementos y que integran una pequeña antena que les permite recibir y contestar a las peticiones que a través de radio frecuencia realiza un emisor-receptor de RFID. La etiqueta contiene un pequeño chip donde se alberga la información de la propia etiqueta. Se distinguen dos tipos de etiquetas:

Pasivas: estas no requieren de ninguna fuente de alimentación interna ya que son capaces de obtener energía al ser activadas por el lector de energía, mediante la inducción de una pequeña corriente eléctrica en la propia etiqueta. Sin embargo su alcance práctico de detección-funcionamiento puede llegar hasta unos pocos metros.

Activas: estas necesitan de algún tipo de fuente de alimentación adicional, usualmente una pequeña pila de botón. Las etiquetas activas presentan mejoras significativas en comparación con las pasivas, en particular en cuanto a funcionamiento en entornos ambientales difíciles como puede ser su implantación en materiales metálicos y su alcance de detección que puede llegar a varios centenares de metros garantizando así una mejor y mayor fiabilidad.

La tecnología RFID permite reemplazar de una forma económica los sistemas de reconocimiento e identificación por códigos de barras, presentando la ventaja que no requiere un contacto visual directo entre la etiqueta y el dispositivo lector. Básicamente la aplicación de la tecnología RFID es la de la identificación automática de objetos y elementos mejorando la trazabilidad de productos en las industrias. Si bien las etiquetas activas si permiten la recepción y envío de datos, esta tecnología no es la adecuada para el intercambio masivo de información entre dos elementos. Debido a la propia fisonomía de las propias etiquetas presentan algunas deficiencias de seguridad ya que pueden estar integradas de forma oculta en los componentes y pueden ser fácilmente leídas sin la autorización del usuario.

3.2. NFC

NFC es el acrónimo de “Near Field Communication”. Este estándar es realmente un subconjunto de las posibilidades que ofrece RFID que limita el rango de alcance a unos 10 centímetros, limitando así los potenciales problemas de seguridad que adolecen a RFID. De forma similar, NFC ofrece dos modos de funcionamiento:

Activo: en el cual los dos dispositivos que desean intercambiar información generan su energía y campo electromagnético que les permite transmitir y recibir los datos.

Pasivo: en el cual solo un dispositivo en la comunicación es capaz de inducir energía. El elemento pasivo pues transfiere la información al elemento inductor.


Este protocolo permite transmitir pequeñas cantidades de datos a velocidades de hasta 848 Kbit/s, aunque previamente ambos dispositivos deben ponerse de acuerdo en la velocidad de trabajo y comunicación. NFC no distingue entre etiquetas y antenas sino que cada dispositivo es a su vez una antena y etiqueta. Este protocolo es ampliamente usado en teléfonos móviles para el intercambio de información como pueden ser contactos, información sobre las aplicaciones aunque su principal diseño está penado para realizar acciones que requieran autenticación, como pueden ser control de acceso, pagos a través de móvil, etcétera.

3.3. WiFi

Bajo el nombre de WiFi [WiFiAlliance] se abarca la especificación IEEE 802.11 (ISO/IEC 8802-11) para el estándar internacional que define y especifica las características para la formación de redes de área local inalámbrica (WLAN). Paralelamente existe la entidad de certificación Wi-Fi Alliance [WiFiAlliance] para garantizar la compatibilidad entre diferentes dispositivos que utilizan este estándar. Cuando se habla de una red Wi-Fi se trata pues de una red que cumple con el estándar 802.11. Wi-Fi especifica los niveles inferiores del modelo OSI en conexiones inalámbricas, es decir la capa física que define las características de señalización para la transmisión de datos y la capa de enlace de datos que define entre el equipo y la capa física siguiendo un método de acceso similar al utilizado en el estándar Ethernet.

Bajo el estándar 802.11 (que fue el primer estándar definido) se recogen varias modificaciones y versiones para dotar de nuevas características al mismo. Algunas de las versiones más destacadas son:

802.11a: con un ancho de banda total máximo de 54 Mbps pero trabajando en la frecuencia de los 5GHz.

802.11b: hasta 11 Mbps y con un alcance de hasta 300 metros en espacio abierto. Trabaja en la frecuencia de los 2.4GHz.

802.11e: que hace hincapié en la mejora de la calidad de servicio desde el nivel de la capa de datos basándose en la definición de los requisitos de los paquetes para permitir mejores transmisiones de datos, en especial de audio y vídeo.

802.11g: hasta 54Mbps manteniendo compatibilidad con el 802.11b. Trabaja en la frecuencia de los 2.4GHz.

802.11n: una nueva revisión del estándar para alcanzar una velocidad de hasta 600Mbps basándose en la utilización de varias antenas y canales de transmisión para enviar y recibir datos. Permite trabajar en las frecuencias de 2.4GHz y 5GHz manteniendo compatibilidad entre las especificaciones 802.11b, 802.11g y 802.11a.

802.11ah: orientada a “Internet de las Cosas”, esta nueva revisión permitirá la transferencia de bajas tasas de datos y la utilización de bandas sub-GHz, que permiten una mejor penetración en paredes, todo orientado a reducir el consumo energético y los requisitos hardware de los equipos. Sin embargo este grupo aún está en formación


y no se esperan los primeros estándares hasta final de 2016, por lo que su salida a mercado no llegaría hasta 2017-18.

3.4. WiFi Direct

Bajo el nombre de WiFi Direct se presenta un perfil de trabajo basándose en la tecnología WiFi que dota a este de características que permiten la formación de redes de área personal. Básicamente se trata de un protocolo que actúa similar a como lo hace Bluetooth pero aprovechando el soporte y las características que WiFi ofrece. Para ello se ofrece soporte a la formación de redes WiFi en el cual cada dispositivo implementa un software de punto de acceso (Soft AP) y la capacidad de autogestión y autogeneración de la configuración de la red.

De esta forma cuando un dispositivo se encuentra en un radio cercano a una red ad hoc creada por otro dispositivo WiFi Direct, este puede solicitar la conexión con este par, recibiendo así la información para su configuración. La aplicación particular podrá implementar el Soft AP que más convenga dependiendo de los propios requerimientos y funcionamiento de la misma ya que es realmente este software el que vertebra y provee los mecanismos y servicios de interacción entre los dispositivos. Este protocolo está basado en las técnicas WPS (WiFi Protected Setup) que permite crear pequeñas redes WiFi en la cual todos los dispositivos son autoconfigurados. WiFi Direct además permite la compatibilidad con antiguos chips WiFi que no soportan directamente estas características mediante la creación de conexiones punto a punto en modo ad hoc.

3.5. Bluetooth

Bluetooth [Bluetooth] es una especificación para la creación de redes inalámbricas de área personal (WPAN). Está especialmente indicada para la transmisión de voz y datos entre diferentes dispositivos, facilitando las comunicaciones entre equipos móviles en especial el emparejamiento y comunicación entre periféricos. Esta especificación actúa en la banda de los 2.4GHz y tiene como objetivo permitir la comunicación de dispositivos con un bajo consumo en un corto alcance de emisión. Además, los transceptores están definidos para que tengan un bajo costo y sea fácil su implantación en diferentes sistemas. La especificación es capaz de definir diferentes clases de dispositivos en base a su potencia de transmisión (clase 1 hasta 100 metros, clase 2 hasta 10 metros, clase 3 hasta un metro). Bluetooth se basa en el concepto de “Profiles” o perfiles. Los perfiles ofrecen servicios que a su vez tienen características que definen que valores se intercambian. Básicamente un perfil es un catálogo de recursos para una aplicación determinada. Los servicios cuentan con un identificador universal denominado UUID. Cualquier comunicación establecida con Bluetooth tiene tres fases fundamentales:

1. Búsqueda, escaneo y conexión de los dispositivos.

2. Establecimiento de cuáles son los servicios y características disponibles. Para ello se utiliza el protocolo SDP (Service Discovery Protocol) para conocer los perfiles Bluetooth que son soportados.

3. Comienzo del intercambio de valores y mensajes.


4.5.1 Bluetooth estándar

La especificación estándar de Bluetooth define un canal de comunicación de hasta 1 Mbit/s y con un rango máximo de 100m (empleando repetidores). El éxito de este protocolo está fundamentado en el bajo costo de obtener una implementación de un módulo de comunicación que además presente un consumo reducido de energía. Este hardware a su vez presenta un diseño muy sencillo y fácilmente adaptable por las empresas fabricantes de componentes electrónicos, ya que se compone únicamente de un dispositivo de radio encargado de la modulación y transmisión de la señal y de un controlador digital que se encarga de procesar las señales y gestionar la comunicación con otros dispositivos con un protocolo muy sencillo.

La topología de red empleada por el protocolo está basada en la definición de Piconets que une a dos o más dispositivos en un mismo canal físico de transmisión que es compartido. Uno de los dispositivos actuará como master (maestro) y establecerá un reloj y secuencia de saltos en el espectro única para evitar colisiones con otras redes. Así mismo, una piconet puede estar formado como máximo por 7 dispositivos slaves (esclavos) aunque estos permiten a su vez ser parte de otras redes llegando así a soportar hasta un máximo de 10 piconets. Los dispositivos maestros pueden enviar y recibir datos a cualquiera de sus nodos esclavos, sin embargo estos solo pueden transmitir y solicitar información a través de su nodo maestro.

El protocolo Bluetooth ha sido mejorado y redefinido con el paso del tiempo, existiendo diferentes versiones que varían sobre todo en la capacidad del canal o ancho de banda. Estas versiones son:

Versión 1.2: con un ancho de banda de 1 Mbit/s. Fue la primera versión estable y que solventaba algunos de los problemas y deficiencias presentadas por las primeras especificaciones.

Versión 2.0 + EDR: con un ancho de banda de 3 Mbit/s. Mantiene la compatibilidad con la versión 1.2, introduciendo una velocidad de datos mejorada gracias a la tecnología EDR (Enhanced Data Rate) que se basa en la utilización de diferentes combinaciones de modulación de la señal. Hay que mencionar que la característica EDR es opcional, pudiendo los dispositivos reclamar una compatibilidad Bluetooth 2.0 sin soportar estas mejoras a la velocidad de transmisión.

Versión 3.0 + HS: con un ancho de banda de hasta 24 Mbit/s. Esta mejora de velocidad no se realiza directamente por un enlace Bluetooth sino que se utiliza el protocolo para realizar el emparejamiento y negociación entre los equipos mientras que el tráfico de datos de alta velocidad se realiza mediante un enlace 802.11. Los dispositivos sin el sufijo “+HS” no soportan la transferencia a alta velocidad. Esta característica permite utilizar el modo de baja energía que proporciona Bluetooth cuando el sistema se encuentra inactivo o transmite bajas cantidades de datos, mientras que se permuta a 802.11 cuando se requiere enviar grandes cantidades datos.


Versión 4.0: con un ancho de banda de 24 Mbit/s. Esta nueva revisión de la especificación permite integrar al Bluetooh clásico, las revisiones de alta velocidad y los nuevos protocolos Bluetooth de bajo consumo energético (BLE). Este define un uso de Bluetooth de alta velocidad mediante 802.11/WiFi, mientras que se seguirá usando el radio del Bluetooth para el resto de casos. Se han realizado dos revisiones; 4.1. que aporta novedades para facilitar la conexión y reconexión de dispositivos sin intervención del usuario, y la 4.2 que integra capacidad para la conexión a internet sin intermediarios gracias al soporte al protocolo IPv6/6LoWPAN.

4.5.2 Bluetooth Low Energy

Bluetooth Low Energy o BLE, aunque también es conocido como Bluetooth LE o Bluetooth Smart) es una variante de una tecnología de radio que también está acogida bajo la especificación Bluetooth. Bajo esta especificación se trata de ofrecer unas prestaciones similares en cuanto a rango de comunicación con respecto al Bluetooth clásico pero con un consumo considerablemente más reducido. Bluetooth LE comenzó su desarrollo bajo el nombre de Wibree por la empresa Nokia en 2006 pero finalmente fue adoptado como parte de la especificación 4.0 de Bluetooth en el año 2010. Cada vez son más los dispositivos y sistemas operativos que dan soporte a este protocolo, previéndose que para 2018 más del 90% de los smartphones con Bluetooth soporten Bluetooth LE.

Esta especificación está especialmente destinada a la creación de redes de área personal donde las restricciones de un bajo consumo energético sean un requisito fundamental tal y como pueden ser aplicaciones en “smart homes”, dispositivos de salud, deportes y fitness, etcétera. Como características más destacadas del protocolo se tienen:

Un bajo consumo energético del protocolo, permitiendo operar a los dispositivos durante meses o años con solo una pila de botón.

Coste reducido y tamaño muy pequeño.

Permitir la compatibilidad e interoperabilidad entre varios tipos de dispositivos ya establecidos anteriormente, como pueden ser teléfonos móviles, tablets o computadores personales a través del Bluetooth Dual o Bluetooth Smart Ready.

Al igual que Bluetooth Classic permite un rango de operación de unos 100 metros con tasas de transferencia de hasta 1 Mbit/s

El interfaz de comunicación ofrecida por Bluetooth Smart está basada en el perfil y terminología GATT (Generic Attribute Profile) que se integra dentro del propio Bluetooth. En síntesis se trata de un perfil similar al SDP (Service Discovery Protocol) pero especialmente adaptado a la versión Low Energy de Bluetooth para operar de la forma más energéticamente eficiente posible. Este perfil permite definir un catálogo para el descubrimiento de servicios y propiedades que son conocidos como atributos. Este distingue entre clientes, que son los dispositivos que envían comandos y solicitudes, y servidores que son los que responden con los mensajes. Por ejemplo un cliente podría ser un computador que solicita información sobre las medidas y accesos a un


nodo sensor que actuaría así como servidor de información. El objetivo de GATT es permitir el emparejamiento de dispositivos interoperables desde cero, negociando las interfaces de intercambio de datos mediante el ofrecimiento de servicios. De esta forma pueden ofrecerse servicios en los cuales el comportamiento está totalmente definido y es predecible. Los servicios se componen de características que es un dato particular que se transfiere entre el cliente y el servidor. Así los servicios se componen de un grupo de características que son necesarias para ofrecer y ejecutar una función específica. Además existen los descriptores que proporcionan información sobre las propias características. Finalmente el concepto de perfil agrupa un conjunto de determinados servicios. De esta forma, y para facilitar la programación y trabajo con el protocolo se ofrecen un amplio rango de perfiles pre-definidos que aseguran la compatibilidad y modo de funcionamiento entre dispositivos. Los perfiles están definidos por tipos de aplicación y por dispositivo. Algunos de los más importantes son:

Health Care Profiles (perfiles destinados a aplicaciones de salud): BLP (Blood Pressure Profile), HTP (Health Thermometer Profile), GLP (Clucose Profile), CGMP (Continuos Glucose Monitor Profile).

Sports and fitness profiles (perfiles destinados a aplicaciones deportivas): BCS (Body Composition Service), CSCP (Cycling Speed and Cadence Profile), CPP (Cycling Power Profile), HRP (Heart Rate Profile), LNP (Location and Navigation Profile), RSCP (Running Speed and Cadence Profile), WSP (Weight Scale Profile).

Internet Connectivity (destinado a dar conexión a Internet al dispositivo): IPSP (Internet Protocolo Support Profile).

Generic Sensors (perfiles generales): ESP (Environmental Sensing Profile), UDS (User Data Service).

Además, con las mejoras introducidas en las revisiones 4.1. y 4.2. se dota de mucha más capacidad a este protocolo para su uso en aplicaciones de Internet de las cosas, ya que se permite la gestión de las desconexiones de la red de forma automática y el uso del protocolo IPv6/6LoWPAN.

Finalmente hay que hacer un pequeño inciso entre el diferente funcionamiento de Bluetooth clásico y Bluetooth Low Energy. La principal diferencia en el diseño y funcionamiento se da en el mantenimiento del canal de comunicación. En el caso de la versión clásica el canal de comunicación se mantiene abierto aun cuando no haya tránsito de información entre los extremos, mientras que en la versión de bajo consumo el canal solo se mantiene cuando hay intercambio de datos entre los dispositivos con lo que se consigue un mayor ahorro energético.

4.5.3 Bluetooth Dual/Bluetooth Smart Ready

Bluetooth Smart no es compatible con la versión clásica de Bluetooth. Es por ello que dentro de la especificación 4.0. de Bluetooth podemos encontrar dos tipos de dispositivos diferenciados:

Bluetooth Smart: que son aquellos dispositivos que solo son capaces de trabajar con el protocolo Bluetooth LE. Este tipo de dispositivos usualmente están diseñados para


difundir algún tipo de información muy específica como valores de sensorización determinados (estado de apertura o cierre de una puerta, pulsaciones por minuto, temperatura, etcétera) y ser enviados a un dispositivo de tipo Bluetooth Smart Ready. Incorporan por defecto el perfil Generic Attribute Profile (GATT).

Bluetooth Smart Ready: que son los dispositivos que realmente pueden operar en modo dual, es decir son compatibles con el modo Bluetooth Classic como con Bluetooth LE.

Por tanto, siempre que se quiera formar una red con dispositivos de ambos tipos se debe requerir al menos la presencia de uno que sea compatible con Bluetooth Smart Ready.

4. Tecnologías, soluciones y plataformas comerciales existentes

En esta sección se describen brevemente algunas propuestas, proyectos y soluciones que se han utilizado para dar soporte a la comunicación entre juguetes y/o dispositivos, ofreciendo ejemplos de cómo pueden emplearse distintas tecnologías y arquitecturas para solventar el problema de la comunicación. Dentro de las tecnologías y novedades presentadas por algunas compañías en el campo del juguete encontramos dos vías principales de propuestas de soluciones:

Comunicaciones y tecnologías propietarias o no estándar con la creación de nuevas soluciones tecnológicas o protocolos propietarios.

Uso de comunicaciones y tecnologías estándar mediante el cual se basan y se adaptan si es necesario las soluciones existentes al producto

4.1. Visible Light Communication

Visible Light Communication [VisibleLightCommunication] cuenta con la participación de Disney Research [DisneyResearch] es un protocolo de comunicación a bajo nivel que utiliza tecnología de emisión/recepción de luz para la comunicación. En este caso, se emplean diodos emisores de luz (LEDs) como emisores y receptores. El objetivo es crear unos interfaces y protocolos de comunicación muy económicos, con bajo consumo y fácilmente integrables en los juguetes aprovechando el rápido reemplazo de luces incandescentes por LEDs en los juguetes. Si bien existen otras tecnologías de bajo alcance económicas para la comunicación de juguetes como pueden ser infrarrojos o comunicaciones de radio, el hecho de que los juguetes tengan este tipo de luces permite reutilizar la instalación y abaratar costes.

El protocolo emplea un software que se encarga de modular la luz a altas frecuencias para el envío de mensajes y comandos. Las aplicaciones del protocolo no solo se restringen a la comunicación entre juguetes sino que puede utilizarse la pantalla de un teléfono móvil para emitir estos mensajes (mediante la modulación de la luz) y también usar la cámara integrada en el propio dispositivo para recibir. De esta forma se enriquecen las posibilidades de aplicaciones a desarrollar, ofreciendo así nuevas experiencias de juego.


4.2. Lego Mindstorms

Lego Mindstorms [Mindstorms] es una serie de juguetes electrónicos educativos que son fabricados por la empresa Lego. Con ellos pueden construirse pequeños robots. La plataforma proporciona los componentes de construcción, los sensores, motores, servos y un lenguaje de programación visual denominado Robolab que es una simplificación para el uso educativo del lenguaje de programación visual Labview [Labview]. El sistema se compone de bloques o bricks que albergan un microcontrolador programable donde el usuario puede definir el comportamiento del propio juguete, sensores y actuadores y las clásicas piezas de lego para formar la estructura o diseño de juguete deseado.

Comercialmente se han distribuido tres versiones o generaciones de Lego Mindstorms que se denominan bloques:

RCX: de la que a su vez existen tres diferentes versiones (incompatibles entre bloques por utilizar diferentes regulaciones de voltajes) y que se basa en un microcontrolador de 16MHz. Esta versión no tiene capacidad para la comunicación entre otros Robots creados por la plataforma.

NXT: la cual se basa en un microcontrolador de 32 bits con capacidad para la ejecución de programas en paralelo. Este bloque presenta unos conectores para los sensores distintos a los de la versión RCX pero pueden adquirirse adaptadores para poder utilizar los de esta versión. En esta versión se incorporan capacidades de comunicación tales como incorporar un interfaz USB para la conexión con un computador y un interfaz Bluetooth 2.0. que habilita la comunicación con otros robots y computadores.

EV3: esta versión amplia a NXT dotando de muchos más conectores para la comunicación y asociación de periféricos tales como más conectores USB, puerto para tarjetas Micro SD, WiFi.

La arquitectura dispone de un amplio conjunto de sensores entre los que se encuentran: sensor de luz, sensor de temperatura, sensor de contacto, sensor de giro, sensor de ultrasonido, etcétera.

A partir de la versión NXT, la comunicación entre diferentes robots se realiza a través del protocolo Bluetooth, siguiendo toda la especificación que este protocolo define pero intercambiando datos en el protocolo de alto nivel llamado NXT. Existen así pues librerías disponibles para la programación de otros dispositivos diferentes a los propios de Lego pero que habilitan el protocolo NXT para la comunicación de órdenes y acciones. Adicionalmente, puede utilizarse USB para este fin.


Ilustración 1. Lego MindStorms

4.3. Calipso

Disney Research [DisneyResearch] participa dentro del proyecto europeo Calipso [Calipso]. Calipso se fundamente en el desarrollo de un protocolo de comunicación software que permita el descubrimiento de objetos, la construcción de redes ad hoc y la comunicación de la forma más eficiente posible para maximizar la duración de las baterías. En particular, Disney está involucrada en la utilización del protocolo para el descubrimiento de juguetes y en la experimentación en la creación de escenarios para el desarrollo de juegos.

El protocolo Calipso está basado en el protocolo IP, pero siendo adaptado para la conexión de objetos (en este caso juguetes) conteniendo métodos para obtener un consumo energético muy bajo y proporcionando interoperabilidad entre los objetos. La pila que ofrece Calipso para Smart Toys facilita a los juguetes poder conectarse automáticamente entre ellos basándose en su localización y perfil o tipo de juguete. Para optimizar los recursos el protocolo es construido en base al sistema operativo ContikiOS [ContikiOS]. Además, un objetivo adicional del proyecto es que los juguetes no solo interaccionen con otros juguetes, sino puedan hacerlo con otros elementos del entorno para enriquecer así la experiencia de juego en cualquier situación (por ejemplo un juguete en un museo podría recibir información para el seguimiento de la propia visita). El proyecto que se encuentra en sus últimas fases ha presentado algunos resultados que pueden consultarse en la propia página web del mismo.

4.4. BeeWi

BeeWi [BeeWi] es una empresa que entre sus productos se encuentran diferentes juguetes que integran un receptor Bluetooth 3.0. El objetivo es permitir ser controlados desde aplicaciones desarrolladas para un dispositivo móvil. Estos juguetes utilizan el perfil de Bluetooth definido como SPP (Serial Profile). Mediante este perfil se permite conectar a dos dispositivos Bluetooth


mediante la creación de dos puertos serie virtuales. De esta forma se permite emular el comportamiento de dos puertos series a nivel de aplicación, permitiendo enmascarar el proceso de establecimiento de conexión y emparejamiento asociado al propio protocolo Bluetooth. La comunicación a nivel de aplicación se realiza en “crudo” es decir, no existen servicios y atributos definidos en este perfil y deben ser las aplicaciones las que sepan realizar el tratamiento adecuado de la información.

Ilustración 2. Bee Wii

4.5. Smart Toy

Smart Toy [SmartToy] es un producto de la empresa Fisher Price que permite ser utilizado como juguete educativo, ya que presenta juegos y consejos para realizar distintas tareas como música, dibujo, aseo personal, etcétera. Dispone de tarjetas de ampliación para soporte de más juegos de tal manera que la actualización de los mismos puede ser continua. Estas tarjetas son códigos QR con diferente información para el juguete que son leídas por el mismo. Además del lector QR integrado en el juguete, este presenta un adaptador WiFi que permite conectarse a la red inalámbrica de la casa. Así pues puede ser configurado y manejado desde dispositivos móviles o computadores dentro de la misma red mediante una conexión WiFi. La aplicación para la gestión del juguete es ofrecida por el fabricante.


Ilustración 4. Anki Overdrive

Ilustración 3. Smart Toy Fisher Price

4.6. Anki

Anki [Anki] es un juguete muy similar al clásico “Scalextric” en el cual se emplea tanto Bluetooth Low Energy como WiFi para las distintas partes del juego. Cada usuario puede controlar su coche en la pista a través de un teléfono móvil o tablet a través del protocolo Bluetooth Low Energy. Para ello la empresa ha desarrollado una aplicación para iPhone y para Android desde el cual se pilotan los coches. El sistema permite recrear usuarios virtuales mediante un complejo sistema de inteligencia artificial que compiten con el jugador de tal forma que no es necesaria la presencia de al menos dos personas para poder realizar una partida. Adicionalmente el sistema permite realizar partidas multijugador utilizando así una conexión WiFi en la que los jugadores se asocian en la misma red y pueden recrear en la aplicación de sus móviles diferentes opciones y lances del juego.


4.7. Kiteracy

Kiteracy [Kiteracy] es un sistema para el aprendizaje y juego de niños con síndrome de Down que emplea etiquetas RFID en diversos objetos y materiales de tal forma que los usuarios deben reconocer el objeto a través de las pistas e información que se les va informando a través de una aplicación en un dispositivo móvil. Los juguetes tienen incorporadas etiquetas RFID de alta frecuencia (13.56 MHz) que permiten ser leídas a través de un lector de RFID que es incorporado a la tablet o teléfono móvil. Cuando el niño coloca un juguete el software identifica la información sobre el objeto, mostrando una representación gráfica en la pantalla y proporcionando el sonido de la misma. Adicionalmente el sistema se complementa con un software que se aloja en un servidor que alberga información sobre el progreso y evolución del aprendizaje del niño en el juego.

4.8. Karendon

Karendon [Karendon] es un proyecto educativo basado en tecnología RFID. Este se compone de una mesa de juego compuesta por un computador o Tablet que incorpora un lector de etiquetas RFID además de una serie de objetos que integran esas etiquetas. Los objetos tienen forma de frutas, verduras, letras, bloques lógicos, etcétera. El juego está basado en el software Toca Toca [TocaToca] que es un juego pensado para el aprendizaje y educación de la respuesta voluntaria de una persona (causa-efecto) delante de un ordenador, englobando las repuestas aspectos perceptivos (atención, percepción, observación), motrices (acciones, precisión, rapidez) y cognitivos (discriminación, memoria, toma de decisiones, lectura).

4.9. Patente Google juguete interactivo

Google ha presentado una patente [GoogleJuguetes] con una solicitud sobre juguetes interactivos que fue presentada ya en 2012 y en el cual se presenta un diseño de una mascota que tiene funcionalidad similar a la de un asistente virtual. Este juguete incorpora diversos tipos de sensores, incluyendo cámaras, micrófonos y altavoces que permiten recoger y grabar sonidos y la propia imagen del niño. Hace empleo de tecnología WiFi lo que permite conectarse a Internet desde donde pueden almacenarse información y descargarse contenidos a la propia mascota. Debido al propio diseño el juguete puede ser empleado como elemento interactivo lúdico o bien en modo de dispositivo de control y vigilancia. Los juguetes además permiten ser emparejados con dispositivos móviles para el control de los actuadores del juguete o el

Ilustración 5. Proyecto Karendón


intercambio de información multimedia. Como se ha comentado previamente, se trata de una patente presentada por la empresa.

Ilustración 6. Sensores incluidos en el prototipo de patente

4.10. Project Legion

Project Legion [ProjectLegion] es un juego de mesa que incorpora en sus fichas y elementos diversas etiquetas NFC de tal forma que puede complementarse el juego con aplicaciones diseñadas para dispositivos móviles. Con ello se permiten crear y ver representaciones gráficas y otro contenido multimedia añadido sobre el desarrollo del juego en los propios teléfonos o tablets.

5. Análisis de requisitos

Los requisitos definen el alcance y las funcionalidades que ofrecerá la plataforma, y permiten realizar el diseño de arquitectura, selección de tecnología e implementación de sistemas (APIs, modelado de contexto, motores de reglas, etc). La tarea de enumerado y selección de requisitos se ha realizado conjuntamente entre AIJU e ITI gracias a los distintos puntos de vista de sus campos de experiencia, y se han apoyado en empresas del sector del juguete. Como resultado, se ha obtenido una selección final de requisitos necesarios que deberá contemplar la arquitectura propuesta.

Id. Descripción de la necesidad - característica Elementos

involucrados

Prioridad

RQ01 El juego debe estar formado por un elemento computacional central (móvil, Tablet o PC) y uno o más juguetes.

Juguetes, computador

Alta

RQ02 El juguete debe ser capaz de enviar su información de sensorización.

Juguete, computador

Alta


RQ03 El computador debe recibir la información de sensorización con una latencia no superior a 250ms para permitir las aplicaciones interactivas.

Juguete, computador

Alta

RQ04 El consumo del sistema electrónico del juguete debe ser lo más reducido posible para aumentar su autonomía.

Juguete Media

RQ05 La configuración inicial del sistema (conexión de nuevos juguetes) debe ser sencilla, pudiendo estar asistida por terceros (por ejemplo padres).


Media

RQ06 La puesta en marcha del sistema ya configurado (cada vez que comienza un nuevo juego) debe ser automática y transparente para el usuario, evitando la dependencia de un tercero (por ejemplo el padre).


Alta

RQ07 La distancia entre los juguetes y/o computador debe ser lo suficiente para permitir el juego en un lugar amplio.


Alta

RQ08 El juguete debe permitir el juego autónomo sin necesidad de requerir de otros elementos (más juguetes o computador)

Juguetes Alta

RQ09 Los juguetes deben poder interaccionar con computadores de distinto tipo (teléfono móvil, Tablet, PC, etcétera)


Alta

RQ10 Los juguetes pueden ser compatibles con otros elementos de terceros diferentes (reproductores multimedia, intercambio de archivos, pantallas, etcétera)

Juguetes Baja

RQ11 Los juguetes y computadores deben emplear los interfaces, protocolos, técnicas y mecanismos más estándares y abiertos posibles


Media

RQ12 Los diseños definidos deben estar preparados para un posible soporte futuro al intercambio de datos multimedia


Baja

RQ13 El costo total de la arquitectura debe ser lo más reducido posible


Media

Tabla 1. Listado de requerimientos básicos


Esta colección de requerimientos facilita una primera visión de las necesidades y características principales que afectan al diseño de los juguetes interactivos. Esta colección nos permitirá además emplearla para seleccionar las tecnologías más adecuadas para el desarrollo del proyecto partiendo de la base que el requerimiento RQ08 indica que el juguete podrá ser usado como juguete tradicional siempre y cuando su diseño permita su juego de esta manea.

6. Análisis comparativo de tecnologías de comunicación y elección para la arquitectura

Examinando las principales tecnologías y algunas de las propuestas y productos del mercado puede observarse la utilización de dos principales grupos tecnológicos:

Uso de elementos de identificación o información estática: en las que los dispositivos únicamente intercambian un conjunto mínimo de datos (en general estáticos) que permiten identificar a los elementos. Para ello se emplean las tecnologías RFID y NFC.

Uso de tecnologías para el intercambio de datos: en las que los dispositivos intercambian diferentes datos en cualquier momento, necesitando para ello mantener un canal de comunicación con determinados requisitos de tasa de transferencia y latencia. Para ello se emplean las tecnologías WiFi y Bluetooth.

Dentro de los objetivos del proyecto y ampliando el horizonte al Internet de los Juguetes (Internet of Toys) con unas mayores posibilidades de comunicación e interacción entre los diferentes elementos que componen el juego, las tecnologías RFID y NFC no se contemplan como soluciones prácticas, ya que estas simplemente son empleadas para la identificación de dispositivos pero no son factibles para el intercambio de datos entre dispositivos. Además, estas tecnologías suelen requerir que los dispositivos que desean comunicarse tengan que estar prácticamente en contacto directo (en especial con NFC) por lo que las posibilidades de juego se reducen considerablemente, no satisfaciendo uno de los principales requisitos de diseño definido en RQ07. Finalmente, un factor limitante que debe tenerse en cuenta es la mayor facilidad para la lectura de las etiquetas en entornos externos al juego. La forma de trabajo de estas tecnologías no requiere de ningún proceso de formación de redes o emparejamiento por lo que existe la posibilidad de utilizar lectores de etiquetas que accedan a la información contenida en ella.

Las tecnologías de comunicación para el intercambio de datos más empleadas en productos jugueteros son los protocolos de comunicación WiFi y Bluetooth (en cualquiera de sus versiones). Esto es debido a la gran disponibilidad de estos interfaces, las herramientas existentes y la familiaridad con los propios usuarios en el uso de los mismos. Además, con los mecanismos y arquitecturas adecuadas puede establecerse un flujo de datos desde el propio juguete hasta posibles aplicaciones en la nube siguiendo así una filosofía totalmente similar a la del Internet de las Cosas (Internet of Things) en el cual los sensores y actuadores (en nuestro caso los juguetes) pueden facilitar y recibir datos de aplicaciones situadas en cualquier punto de Internet y posibilitando al acceso de recursos, servicios y aplicaciones alojadas en la nube cumpliendo con los requisitos definidos en RQ01, RQ02 y RQ10. Las tecnologías WiFi y Bluetooth presentan conceptos y objetivos similares pero sus características técnicas son bastante


diferentes, por lo que debe elegirse la mejor opción en base a los atributos del sistema final. A continuación se muestra una tabla resumen donde se recogen los principales aspectos que diferencian a las tecnologías anteriormente comentadas y que sirven para mostrar las similitudes y diferencias entre ellos de cara a la elección del protocolo más adecuado para el desarrollo del proyecto.

WiFi WiFi Direct Bluetooth 2.0 EDR

Bluetooth LE

Distancia teórica

100 metros 200 metros 100 metros Hasta 250 metros

Velocidad teórica

54 Mbits/s (versiones más

estándar)

Hasta 250 Mbit/s 3 Mbit/s 1 Mbit/s

Productividad a nivel de

aplicación

- - Hasta 2.1 Mbit/s

Hasta 0.27 Mbit/s

Dispositivos 65535 Teórico. Depende del

punto de acceso (usualmente 255

dispositivos)

65535 Teórico 1 maestro, 7 esclavos

No definido, depende de la

implementación por parte del

fabricante

Seguridad Cifrado de hasta 256 bits y

posibilidad de usar cifrado a nivel de

aplicación

Cifrado de hasta 256 bits y

posibilidad de usar cifrado a nivel de

aplicación

Cifrado de hasta de 128

bits y posibilidad

de usar cifrado a nivel de

aplicación

Cifrado de 128 bits y

posibilidad de usar cifrado a

nivel de aplicación

Acceso al medio

Espectro ensanchado por

secuencia directa DSSS

Espectro ensanchado por

secuencia directa DSSS

Salto de frecuencia adaptativa

Salto de frecuencia adaptativa

Latencia 10 ms, sin embargo se

requiere que el dispositivo esté

permanentement

10 ms, sin embargo se

requiere que el dispositivo esté

permanentement

100 ms 6 ms


e escuchando incrementando el

consumo energético

e escuchando incrementando el

consumo energético

Tiempo mínimo de envío de

datos

10 ms 10 ms 100 ms 3 ms

Capacidad envío de voz en

tiempo real

Sí Sí Sí No

Topología de red

Estrella Punto a punto, Estrella

Scatternet Scatternet

Consumo de energía

máximo

- - 1 mW 0.150 mW

Pico de consumo de

energía

116mA 116mA 30 mA 12.5 mA

Descubrimiento de servicios

integrado

Sí, a través de WPS

Sí Sí, a través de SDP

Sí, a través de GATT

Definición perfiles

No No por defecto Sí Sí

Aplicación Creación de una red local

inalámbrica, proveer conexión

a internet a través de un punto de

acceso

Compartición de datos multimedia entre dispositivos

Teléfonos móviles,

periféricos de juego y

computador, dispositivos

de audio

Dispositivos wearables,

Dispositivos para control

médico, Deporte,

Aplicaciones industriales

Tabla 2. Tabla resumen de características

Como se ha comentado, NFC y RFID no se contemplan como posibles soluciones a adoptar para dotar de una experiencia satisfactoria en el Internet de los Juguetes dentro del ámbito del proyecto. Por otra parte, WiFi y Bluetooth son los dos protocolos más empleados a la hora de dotar de comunicación en todos los productos destinados al mundo del juguete. Ambos interfaces están presentes e integrados en gran cantidad de dispositivos por lo que existe un


amplio mercado potencial con los cuales los juguetes pueden interactuar, tal y como se define en el requisito RQ11. En ambos casos, para la conexión, control y configuración de pequeños dispositivos la tendencia actual es la de utilizar Bluetooth como principal opción frente a WiFi. Si bien WiFi es un protocolo muy establecido e integrado en diferentes dispositivos del hogar conectados a Internet para el intercambio de grandes volúmenes de datos, si es cierto que presenta desventajas como sus posibles problemas de seguridad que puede acarrear (poder utilizar suplantación de identidad, habilitar una conexión a Internet, etcétera), el consumo energético que presenta que puede hacerlo inviable en su integración en placas y juguetes de tamaño reducido donde no pueda ser alimentado con una fuente de alimentación, tiene un mayor requisito de recursos hardware, y puede presentar de autoconfiguración en el caso de integrarse dentro de una red doméstica (direccionamiento, protocolos de seguridad, etcétera).

Por otra parte Bluetooth es un protocolo que con su nueva revisión BLE esta optimizado para la transferencia de pequeños comandos con un consumo energético reducido ya que delega gran parte del funcionamiento y sobrecarga en los dispositivos con mayores capacidades computacionales y de batería (los masters), mostrándose ideal para ser integrados en los juguetes, ya que la comunicación de estos suele limitarse a la comunicación de valores de sensorización o la espera de comandos de actuación. Esto permite cumplir el requisito definido por RQ04. Además, con la aparición de la nueva versión de Bluetooth se habilita el perfil GATT (Generic Attribute Profile) ofreciéndose la posibilidad de acceder a un mecanismo interoperable para el descubrimiento de servicios optimizado para el consumo energético y que puede permitir en el futuro interoperar con otros dispositivos similares de fabricantes de terceros, consiguiendo de este modo satisfacer los requisitos definidos en RQ05, RQ06, RQ09 y RQ10. Además, en el caso que el diseño del propio juego/juguete requiriese de transferencias de datos más elevadas, por ejemplo para el intercambio de contenido multimedia, podría utilizarse interfaces de comunicación que soporten la versión clásica del protocolo para la transferencia de los mismos. Con ello se posibilita permutar el uso de uno de los dos modos de operación de Bluetooth (clásico con HS o Low Energy) en función de los requerimientos del juguete. Esto sin duda representa una ventaja frente al protocolo WiFi que solo permite un modo de funcionamiento adaptado al intercambio masivo de datos. Así se consigue satisface el requisito definido en RQ12. Obviamente, con la propia especificación del protocolo se tiene que los tiempos de transmisión son lo suficiente holgados para cumplir el requisito definido en RQ03.

Los dispositivos transmisores Bluetooth presentan un bajo coste de fabricación y adquisición por lo que ayuda al no encarecimiento del producto final permitiendo ser integrados en diferentes dispositivos electrónicos y cumpliendo el requisito definido en RQ13. Esto es especialmente importante en la tendencia actual de crear aparatos electrónicos cada vez más pequeños y ligeros, ya que para conseguir estos objetivos comienzan a prescindir de los interfaces y conectores para el uso de periféricos auxiliares como auriculares, micrófonos o teclados, siendo sustituidos por otros métodos de interconexión que permitan diseñar estos aparatos. Es en este caso cuando Bluetooth es empleado como principal método de emparejamiento de dispositivos electrónicos y se espera que cada vez lo vaya siendo más con el avance de la tecnología para la creación de aparatos extra-slim (muy poco grosor y reducido peso).


7. Arquitectura

Una vez revisadas las principales posibilidades tecnológicas existentes en el mercado, podemos definir la arquitectura de comunicación que se desarrollará en el proyecto. El protocolo de comunicación a emplear en la arquitectura será el definido por Bluetooth en sus versiones 4.x, ya que presenta la posibilidad de utilizar el modo de bajo consumo Bluetooth Low Energy para ser utilizado dentro de los juguetes, ya que estos tendrán las mayores restricciones en cuanto a consumo energético se refiere, añadiendo además la posibilidad de habilitar el uso del modo clásico con HS para el caso de diseño de juegos y juguetes que requieran de transferencia de datos multimedia. Dentro de la arquitectura se definen dos actores principales:

Dispositivo móvil o computador: que puede ser desde un teléfono móvil o tableta hasta un computador de sobremesa con un interfaz de red de tipo Bluetooth Smart Ready, es decir con capacidad para trabajar y operar con los dos modos que ofrece Bluetooth; clásico y Low Energy.

Juguetes: que dispondrán de un microcontrolador programado con el código que permite obtener la sensorización, realizar actuaciones en su caso y la lógica del juguete dentro del propio juego además de un interfaz de comunicación de tipo Bluetooth Smart.

Los juguetes establecen una conexión siempre con el dispositivo central que actúa como dispositivo maestro dentro de la arquitectura. Los juguetes no se comunican directamente entre ellos, sino a través del dispositivo central que podrá vertebrar la comunicación entre los mismos. De esta forma la arquitectura presenta un esquema similar al definido en el siguiente gráfico.

Ilustración 7. Diagrama arquitectura


El dispositivo central proveerá a los desarrolladores de aplicaciones de una serie de interfaces que faciliten el desarrollo de aplicaciones sobre los juguetes con capacidad para el trabajo dentro de la arquitectura. Estas interfaces ofrecen las siguientes funcionalidades básicas:

Solicitud de datos de un juguete: que permitirá solicitar el estado en el que se encuentra alguno de los sensores del juguete.

Envío de datos a un juguete: que permitirá enviar información de acción hacia el juguete si este tiene actuadores habilitados.

Gestión de avisos ante determinados eventos: que serán gestionados desde el dispositivo central y permitirá a las aplicaciones ser notificadas ante eventos que puedan ser producidos en el sistema, facilitando de este modo la creación de aplicaciones con capacidad de adaptación al contexto.

El dispositivo central se encargará de mantener un registro con los juguetes que permanecen conectados en el juego, asociándoles una dirección lógica interna dentro de la propia aplicación a construir y que permita ser utilizada para direccionar los mensajes hacia estos.

Los dispositivos Bluetooth Low Energy deben implementar dos perfiles obligatorios; Generic Access Profile (GAP) y Generic Attribute Profile (GATT). GAP define tanto las características del dispositivo como el nombre, parámetros de conexión, rol, etcétera como la funcionalidad básica describiendo como son las capas físicas y de enlace y la seguridad en las comunicaciones. Por otra parte el perfil GATT es un protocolo de alto nivel empleado para el descubrimiento de servicios. Este perfil distingue entre cliente y servidor. Un dispositivo cliente (en nuestro caso dispositivo central) consultará cuales son los recursos que contiene un determinado dispositivo servidor (en nuestro caso el juguete). El protocolo GATT define los siguientes conceptos:

Característica: representa un servicio de proporción de un valor o dato (como puede ser la temperatura o un switch para un actuador) y que puede estar definido por uno o varios descriptores.

Servicio: que agrupa a varias características y que dotan de una funcionalidad única establecida.

Perfil: que agrupa a varios servicios. GATT soporta por defecto varios perfiles predefinidos [BluetoothProfiles].

Una vez se han descubierto los distintos perfiles y servicios que ofrece un dispositivo pueden comenzar a trabajar en caso de compatibilidad de estos. Bluetooth define una serie de servicios y perfiles estándar que permiten ser usados por las aplicaciones asegurando así la interoperabilidad entre ellas. Por ejemplo el perfil definido como Alert Notification Profile (ANP) permite a los dispositivos cliente (central) recibir alertas e información de los dispositivos servidores (periféricos) cuando estos disponen de información, además de información de la cuenta de alertas y de posibles lecturas no efectuadas. Sobre este puede enviarse un texto descriptivo que puede emplearse para facilitar el origen de la alarma, en nuestro caso podría ser el cambio en el valor de un sensor.


Por otra parte si los servicios y perfiles estándar disponibles no se ajustan a las necesidades de la arquitectura y aplicación, pueden definirse servicios y perfiles propios. En este caso la interoperabilidad entre aplicaciones se pierde (no se convierten en estándar) pero por el contrario se facilita y ajusta mucho más al sistema a desarrollar. Sin embargo, si pueden reutilizarse definiciones y conceptos aplicados en el campo de la sensorización que permitan trabajar más fácilmente con el sistema. Un ejemplo es la aplicación de la nomenclatura y estandarización propuesta por IPSO Smart Objects [IPSOSmartObjects]. Bajo esta definición se definen un conjunto unívoco de identificadores para los tipos de sensores y actuadores y los recursos que estos disponen, de tal forma que pueden conocerse cuales son las acciones y valores que pueden obtenerse según el tipo de objeto (sensor o actuador). Esto permite unificar la forma de operación con el catálogo de objetos del sistema. Con este concepto puede definirse un perfil Bluetooth en el cual se definan características según la nomenclatura IPSO que pueden disponer los juguetes y dispositivos involucrados bajo un conjunto de servicios y perfil propio de tipo “juguete”.

En cualquier caso la decisión final sobre el uso de un perfil estándar o bien uno específico será determinado con el avance del proyecto una vez se hayan definido todos los requisitos y funcionalidades y se hayan seleccionado el conjunto de dispositivos y herramientas a emplear en el mismo. Aun así, pueden definirse algunos de los comportamientos mínimos que la arquitectura debe ofrecer. Estos son descritos brevemente a continuación.

Búsqueda de juguetes y dispositivos

Los juguetes y dispositivos son entes preparados para trabajar en modo autónomo, desconociendo en un principio cuales son las entidades que se encuentran en el entorno. Es por este motivo que estos deben ofrecer algún mecanismo que les haga “visibles” frente al resto de entidades presentes. Bluetooth ofrece este comportamiento definido dentro de su propio protocolo por lo que no hace falta más que adaptar su funcionalidad a la aplicación en el proyecto. Los dispositivos y juguetes deben tener la capacidad de deshabilitar su modo “visible” de tal forma que puedan seguir funcionando de forma autónoma o bien no sea adecuado o pertinente la posibilidad de establecer un juego compartido.

Emparejamiento de juguetes y dispositivos

Cuando los juguetes y dispositivos conocen al resto de elementos “visibles”, antes de comenzar el juego compartido deben emparejarse y establecer cuáles serán los elementos potenciales que compongan el grupo para el juego. Bluetooth ofrece este comportamiento definido dentro de su propio protocolo por lo que no hace falta más que adaptar su funcionalidad a la aplicación en el proyecto. En este paso también se establecerán diferentes configuraciones compartidas sobre el uso de identificadores y direcciones, etcétera que serán utilizados durante el juego.

Intercambio de información sobre las características y servicios

Una vez establecido los componentes que participarán en el juego (al menos un dispositivo y uno o más juguetes) deben compartirse entre el dispositivo y el resto de juguetes cuales son las características de cada uno de los elementos, de tal forma que se conozcan las lecturas, acciones y eventos que pueden establecerse con cada uno de los elementos. Los datos deberán ser


informados a la aplicación para que gestione correctamente la información proporcionada y a su vez puedan reaccionar y comunicar las acciones pertinentes en su caso. Bluetooth ofrece este comportamiento bajo el perfil GATT que está definido dentro de su propio protocolo por lo que no hace falta más que adaptar su funcionalidad a la aplicación en el proyecto. En todo caso, si este no pudiera adaptarse a los requerimientos finales se deberá establecer un protocolo de descubrimiento de recursos y servicios entre los diferentes elementos.

Lectura de datos de sensores / envío de datos hacia actuadores

Una vez establecido el emparejamiento y conocidos los recursos y servicios disponibles, la aplicación del juego instalada en el dispositivo móvil puede comenzar a solicitar lecturas provenientes de los juguetes y también el envío de comandos hacia los mismos mediante el acceso a los diferentes servicios ofrecidos por los elementos que componen el grupo y que habrán sido declarados y definidos previamente en el perfil de uso. Será labor del software middleware conocer el origen y destino del intercambio de datos producido.

El acceso a los datos tanto en modo lectura como escritura se realiza accediendo a los identificadores de parámetros definidos en los perfiles y servicios. Una vez obtenidos los identificadores de características a emplear por los servicios y perfiles de la aplicación bastará por tanto con acceder con operaciones de lectura o escritura facilitadas por la librería de programación del protocolo y el lenguaje utilizado.

8. Ejemplos de casos de uso

A continuación se muestran los escenarios básicos de funcionamiento que pueden encontrarse en la arquitectura, describiendo brevemente el comportamiento y flujo de intercambio de operaciones y datos entre los elementos. Principalmente se distinguen dos tipos de escenarios que son descritos a continuación.

8.1. Un juguete – un dispositivo

Este escenario representa el escenario básico. Se cuenta con un único dispositivo móvil donde se aloja el software middleware y un juguete con capacidad de conexión. Los pasos que definen este escenario son los siguientes:

1. Tanto el dispositivo móvil como el propio juguete deben tener activadas las opciones de “visibilidad” adecuadas conforme al protocolo Bluetooth Low Energy.

2. Desde la aplicación del juego se realiza una búsqueda de los juguetes disponibles en ese momento que se encuentran en el alcance de radio frecuencia y son compatibles con el protocolo.

3. La aplicación y el juguete se emparejan de tal forma que se intercambian información sobre los servicios y perfiles que comparten entre ellos. Se determina que la aplicación del juego esté diseñada para el trabajo con los perfiles y servicios ofrecidos por el juguete.

a. En el caso de ser compatibles se comienza la aplicación del juego.


b. En el caso de no ser compatibles (perfiles y servicios necesarios no están habilitados o bien la aplicación no ha sido diseñada para el trabajo con este elemento) el software middleware informa a la aplicación del juego de la no compatibilidad.

4. Una vez establecidas las conexiones y emparejamientos necesarios el software middleware de sensorización comienza su proceso. Este tendrá dos modos de trabajo:

a. Solicitud de los datos de forma explícita al juguete a medida que sean necesarios procediendo a su interpretación.

b. Recepción de los datos que un juguete puede enviar al dispositivo procediendo a su posterior interpretación.

5. Cuando los datos son procesados se pueden realizar las siguientes acciones (dependiendo del contexto y la propia información recibida):

a. Si se trata de un evento o comunicación interna del sistema se actuará de forma automática. Esto puede darse en el trato de errores de recepción de mensajes, comunicación no establecida, gestión del protocolo de comunicación, etcétera.

b. Si se trata de un evento o contexto este será comunicado a través del interfaz de programación de aplicaciones.

Los eventos y comandos recibidos a través del interfaz de comunicaciones serán comunicados y enviados al juguete.

8.2. Varios juguetes – un dispositivo

Este escenario representa el escenario donde pueden coexistir varios juguetes en el mismo juego. Se cuenta con un único dispositivo móvil donde se aloja el software middleware y varios juguetes con capacidad de conexión. Los pasos a seguir serán prácticamente los mismos que en el caso básico. Simplemente la diferencia que debe tenerse en cuenta que no existirá comunicación física real entre los juguetes, sino que esta se efectuará siempre a través del software middleware actuando este de agente intermedio. De hecho, será la propia aplicación del juego la que dotará de una imagen de comunicación interactiva entre los juguetes. Los pasos que definen este escenario son los siguientes:

1. Tanto el dispositivo móvil como los propios juguetes deben tener activadas las opciones de “visibilidad” adecuadas conforme al protocolo Bluetooth Low Energy.

2. Desde la aplicación del juego se realiza una búsqueda de los juguetes disponibles en ese momento que se encuentran en el alcance de radio frecuencia y son compatibles con el protocolo.

3. La aplicación y los juguetes se emparejan de tal forma que se intercambian información sobre los servicios y perfiles que comparten entre ellos. Se determina que la aplicación del juego esté diseñada para el trabajo con los perfiles y servicios ofrecidos por los juguetes.

a. En el caso de ser compatibles se comienza la aplicación del juego. b. En el caso de no ser compatibles (perfiles y servicios necesarios no están

habilitados o bien la aplicación no ha sido diseñada para el trabajo con este elemento) el software middleware informa a la aplicación del juego de la no compatibilidad.


4. Una vez establecidas las conexiones y emparejamientos necesarios el software middleware de sensorización comienza su proceso. Este tendrá dos modos de trabajo:

a. Solicitud de los datos de forma explícita a los juguetes a medida que sean necesarios procediendo a su interpretación.

b. Recepción de los datos que los juguetes pueden enviar al dispositivo procediendo a su posterior interpretación.

5. Cuando los datos son procesados se pueden realizar las siguientes acciones (dependiendo del contexto y la propia información recibida):

a. Si se trata de un evento o comunicación interna del sistema se actuará de forma automática. Esto puede darse en el trato de errores de recepción de mensajes, comunicación no establecida, gestión del protocolo de comunicación, etcétera.

b. Si se trata de un evento o contexto este será comunicado a través del interfaz de programación de aplicaciones.

6. Los eventos y comandos recibidos a través del interfaz de comunicaciones serán comunicados y enviados al juguete. Esto es especialmente importante a destacar. Si la acción de un juguete debe provocar una reacción en otro este será gestionado a través del software middleware y la aplicación del juego de este modo:

a. Un juguete causa un evento y es comunicado al software middleware de comunicación.

b. El software middleware comunica el evento de la manera adecuada a la aplicación del juego.

c. La aplicación del juego responde de la manera adecuada comunicando al interfaz el envío de un comando hacia el juguete deseado.

d. Es el software middleware el que realiza el envío del comando hacia el juguete deseado.

8.3. Diagrama de flujo

A continuación mostramos un pequeño gráfico resumen que resume el flujo de secuencias e intercambio de datos que se dan en la arquitectura permitiendo observar a grandes rangos el funcionamiento del sistema sin entrar en los detalles.


Ilustración 8. Flujo de operaciones e intercambio de datos

Básicamente será el software de la arquitectura de sensorización y sensibilidad al contexto instalado en el dispositivo móvil el que gestione el flujo de información entre los dos principales actores, los juguetes y la aplicación de dispositivo del juego.


9. Referencias bibliográficas

[TiposArquitectura] Definiciones de Arquitectura Centralizada y Distribuida. http://iscbunkerramo.blogspot.com.es/2011/11/sistema-distribuido-vs-sistema.html [WiFiAlliance] Página oficial de la entidad de certificación Wi-Fi Alliance – http://www.wi-fi.org [Bluetooth] Página oficial de Bluetooth – http://www.bluetooth.com [MindStorms] Página oficial de Lego Mindstorms – http://www.legomindstorms.com [Labview] Página oficial de LabView – http://www.ni.com/labview/esa [DisneyResearch] Página de Disney Research – http://www.disneyresearch.com [Calipso] Página oficial de Calipso – http://www.ict-calipso.eu [VisibleLightCommunication] Página de Disney Research sobre investigación en el protocolo – http://www.disneyresearch.com/project/visible-light-communication [ContikiOS] Página oficial de ContikiOS – http://www.contiki-os.org [WebBluetooth] Página oficial de Web Bluetooth – http://webbluetoothcg.github.io/web-bluetooth/ [BeeWi] Página oficial de BeeWi – http://www.bee-wi.com [SmartToy] Página oficial de SmartToy – http://www.smarttoy.com [BluetoohProfiles] Página con los perfiles soportados por Bluetooth – https://developer.bluetooth.org/TechnologyOverview/Pages/Profiles.aspx [IPSOSmartObjects] Página oficial de la alianza IPSO - http://www.ipso-alliance.org/ [Anki] Página oficial de Anki – https://anki.com/ [Kiteracy] Página oficial de Kiteracy – https://kiteracy.com/ [Karendon] Página que recoge una noticia sobre el proyecto – http://www.educaciontrespuntocero.com/noticias/karendon-el-rincon-digital-para-alumnos-de-infantil-y-con-necesidades-especiales/12081.html [TocaToca] Página del desarrollador del software – http://www.xtec.cat/~jfonoll/ [GoogleJuguetes] Página de noticia con enlace a la patente – http:// http://computerhoy.com/noticias/hardware/google-patenta-juguetes-interactivos-conectados-internet-28973 [ProjectLegion] Página donde se comenta el producto – http://www.monkeypotion.com/devblog/project-legion-board-game/ [RFID] Página oficial de la alianza Rain RFID – http://rainrfid.org

http://iscbunkerramo.blogspot.com.es/2011/11/sistema-distribuido-vs-sistema.html

http://www.wi-fi.org/

http://www.bluetooth.com/

http://www.legomindstorms.com/

http://www.ni.com/labview/esa

http://www.disneyresearch.com/

http://www.ict-calipso.eu/

http://www.disneyresearch.com/project/visible-light-communication

http://www.contiki-os.org/

http://webbluetoothcg.github.io/web-bluetooth/

http://webbluetoothcg.github.io/web-bluetooth/

http://www.bee-wi.com/

http://www.smarttoy.com/

https://developer.bluetooth.org/TechnologyOverview/Pages/Profiles.aspx

http://www.ipso-alliance.org/

https://anki.com/

https://kiteracy.com/

http://www.educaciontrespuntocero.com/noticias/karendon-el-rincon-digital-para-alumnos-de-infantil-y-con-necesidades-especiales/12081.html

http://www.educaciontrespuntocero.com/noticias/karendon-el-rincon-digital-para-alumnos-de-infantil-y-con-necesidades-especiales/12081.html

http://www.xtec.cat/~jfonoll/

http://computerhoy.com/noticias/hardware/google-patenta-juguetes-interactivos-conectados-internet-28973

http://computerhoy.com/noticias/hardware/google-patenta-juguetes-interactivos-conectados-internet-28973

http://www.monkeypotion.com/devblog/project-legion-board-game/

http://rainrfid.org/

Investigacion en la seguridad de los Juguetes - MEMORIA … · 2016-12-16 · 2. Introducción a la...

Documents

Transcript of Investigacion en la seguridad de los Juguetes - MEMORIA … · 2016-12-16 · 2. Introducción a la...