Wearables (y 3)

noviembre 12, 2023 on 6:53 pm | In análisis de datos, colección, m2m, iot | Comentarios desactivados en Wearables (y 3)

Adolfo García Yagüe | En estas líneas comentaremos como el uso de sensores ópticos, junto a otros de tecnología MEMS (Microelectromechanical Systems) y el empleo de microcontroladores, está permitiendo el desarrollo de una nueva generación de productos conocidos como Wearables (por aquello de que van entre nuestra indumentaria) especializados en recoger datos biométricos y de nuestra actividad física.

Microcontroladores
Los microcontroladores llevan entre nosotros desde los años 70. En ellos, compartiendo el mismo silicio, se reúnen los principales elementos que constituyen un ordenador: microprocesador, memoria ROM y RAM, puertos de entrada y salida e, incluso, etapas de conversión AD (Analógico-Digital) y DA. El espectro de aplicación de estos componentes es amplísimo al simplificar un diseño electrónico y abaratar costes. Otra cualidad que hace especialmente atractivos a ciertos microcontroladores es su bajo consumo eléctrico, razón por la cual son ampliamente usados en dispositivos integrados o embebidos.

Como podéis intuir, el clip de actividad Fitbit One (2012) cumple con la definición de dispositivo embebido y fue uno de los primeros de la generación Wearable. En él, además de su bajo perfil eléctrico, se observa un diseño compacto optimizado para realizar una funcionalidad con una necesidad de cómputo limitada y predecible. En este podómetro se emplea el microcontrolador STM32L de ST Microelectronics, que se basa en la arquitectura ARM 7 perfil M, o Cortex M3. Este componente, a través a sus buses digitales I2C, SPI o analógicos, puede recoger las lecturas procedentes sensores externos.

MEMS (Microelectromechanical Systems)
A pesar de que las micromáquinas están permitiendo el desarrollo de cientos de dispositivos y soluciones, la tecnología que rodea a estos ingenios es poco conocida. La idea de partida se basa en el desarrollo a escala nano y micrométrica de máquinas mediante técnicas de fabricación similares a las empleadas en los circuitos integrados, es decir, a través de la deposición sobre un sustrato de silicio de distintas capas de materiales y la posterior fotolitografía para “esculpir” microscópicamente un sencillo proceso mecánico junto a otro electrónico. Esta unión entre mecánica y electrónica ha hecho posible, por ejemplo, la miniaturización de sensores de presión, de gases, acelerómetros y giróscopos. Otros componentes desarrollados gracias a la tecnología MEMS tienen que ver con las comunicaciones ópticas, la radiofrecuencia o algo tan común como los inyectores de tinta de algunas impresoras. Por último, y no menos importante, son aquellas aplicaciones MEMS en el campo de la medicina como medidores del nivel de glucosa en sangre, parches para dosificar una sustancia a un paciente o las bombas de insulina, entre otras.

(a). Mecanismo ultraplanar construido con tecnología MEMS en Sandia National Laboratories. (b). Patas de un ácaro sobre los engranajes de un micromotor construido en Sandia National Laboratories. (c). Detalle de ejes y x de un acelerómetro capacitivo MEMS de ST Microelectronics.

La historia de los MEMS la podemos resumir en los siguientes hitos. En primer lugar, en 1954, se descubrió la existencia de propiedades piezo-resistivas en el silicio y germanio. La piezo-resistividad es el cambio de resistencia eléctrica que experimentan algunos materiales cuando se los somete a un esfuerzo o estrés mecánico de tracción o compresión. Durante década de los ’60 se harán las primeras demostraciones de sensores de presión y aceleración, ambos construidos con silicio. En 1977, a diferencia del sensor presentado años atrás, que se apoyaba la citada piezo-resistividad, se mostrará un sensor de presión basado en la variación de capacidad. En 1988 se presentarán los primeros prototipos de (micro) máquinas rotativas construidas con esta tecnología. Por último, al principio de la década de los ’90, Analog Devices pone a la venta el primer acelerómetro capacitivo de un eje con tecnología MEMS: el ADXL50.

Podómetro y calidad del sueño
En el caso del clip Fitbit One, para el medir el número de pasos, el citado microcontrolador STM32L realiza un promediado de los datos procedentes del sensor acelerómetro capacitivo MEMS C3H de tres ejes con el fin de identificar y eliminar aquellas muestras que, por su valor, exceden los valores normales de funcionamiento. Tras esta “limpieza” de las señales leídas en cada eje, los pasos del usuario se corresponderán con la repetición periódica de ciertos valores que destacan entre el resto. Sin abandonar este microcontrolador, tras reconocer los eventos asociados a un paso, se llevará la cuenta de estos y se realizarán los cálculos matemáticos para deducir, entre otros, la distancia recorrida, velocidad y calorías quemadas. Por último, guardará todos estos datos en una memoria pudiendo ser presentados en un display para ser consultados por el usuario o, enviados por radio bluetooth al Smartphone y de ahí a la nube de Google en el caso de un dispositivo Fitbit. Y vuelta a empezar.

Otra capacidad que se ha vuelto muy popular entre algunos usuarios de Wearables es la “medida” de la calidad del sueño. Como sabéis, gran parte de la población dormimos menos de lo que necesitamos y esto, lamentablemente, se puede manifestar en nuestra salud física y mental. Esta necesidad por conocer la calidad de nuestro descanso ha llevado a los fabricantes de Wearables a implementar algoritmos con los que registrar los movimientos de nuestro cuerpo mientras dormimos. Es bien conocido que durante este periodo de descanso se producen varias etapas y que el sueño reparador o, de más calidad, se desarrolla durante las fases III, IV o Delta y V REM (Rapid Eye Movement). Durante estas etapas, nuestra actividad motora va cesando hasta permanecer inmóviles. La duración de estos periodos de reposo son los que registran los Wearables. Es decir, al contrario que con los pasos, en la medida de calidad del sueño se lleva un control del tiempo en la que acelerómetro apenas registra movimientos.

Medición de escalones subidos
En el clip Fitbit One también se identifica el sensor de presión barométrica MS5607 de MEAS Switzerland. Gracias a este sensor de tecnología MEMS, este Wearable lleva la cuenta de los escalones que subimos añadiendo así más riqueza a los datos que describen nuestra actividad.

El MS5607 basa su funcionamiento en el efecto piezo-resistivo y, a través de éste, es capaz de medir la presión atmosférica en un rango que va desde los 10 a 1200 mbar (milibares). No olvidemos que, a nivel del mar, la presión atmosférica es de 1013 milibares y que, a medida que aumenta la altura, la presión disminuye en, aproximadamente, 1 mbar por cada 9 metros, o 110 mbar por cada 1.000 metros. No obstante, como deduciréis, la Fitbit One no pretende ser un barómetro y se apoya en la precisión de 20cm que ofrece el MS5607 para identificar los incrementos de altura que se producen cuando subimos las escaleras. Por último, al estar calibrado por MEAS durante el proceso de fabricación, este sensor entregará al microcontrolador STM32L sus lecturas listas para ser empleadas a través de un bus I2C o SPI y solo será necesario hacer -en el microcontrolador- la conversión de milibares a metros de altitud y cruzar estos datos incrementales con los que está registrando el acelerómetro en el movimiento que hace nuestro cuerpo mientras subimos la escalera.

Frecuencia cardíaca y oxígeno en sangre
En el texto dedicado al pulsómetro vimos cómo es posible conocer la frecuencia cardíaca a través de unos electrodos con los que se registra -en la superficie de nuestro pecho- los impulsos eléctricos que estimulan cada latido. Aunque esta técnica ha demostrado su efectividad y es usada por algunos deportistas, presenta ciertos inconvenientes como la colocación apropiada del sensor y su incomodidad. Estas dificultades son la consecuencia de que su uso no esté extendido más allá del círculo deportivo, siendo inviable en el día a día de una persona. Por este motivo, desde hace algunos años, ciertos Wearables emplean para este propósito la fotopletismografía (PPG) que es, como todos sabéis, la aproximación usada en fines médicos para la medición del nivel de saturación de oxígeno en sangre (SpO2).

Sin ser un entendido en fisiología, diré que la fotopletismografía se apoya en la medida del cambio de volumen del flujo sanguíneo durante la actividad cardíaca. Este cambio de volumen, que coincide con los latidos del corazón, también coincide con cambios en la coloración de la hemoglobina mientras ésta transporta oxígeno confiriendo a la sangre ese color rojo intenso y, en cambio, un color rojo oscuro cuando porta dióxido de carbono.

Como decíamos anteriormente, esta técnica de medida se viene utilizando en el mundo médico desde finales de los ’80 y, en los últimos años, está disponible en medidores de uso personal para comprobar la saturación de oxígeno en sangre y el pulso cardíaco: son los conocidos oxímetros y pulsímetros que se colocan en el dedo. Si analizamos uno de estos dispositivos observaremos que, en la parte que toca con la yema del dedo, se identifica un receptor de luz mientras que, en el lado contrario, hay una fuente de luz de tonos rojos. Mas concretamente, el oxímetro emite dos fuentes de luz: en la región infrarroja con un LED de 940nm y con otro LED rojo a 660nm, ambas lambdas tienen un grado de absorción diferente en función del contenido de oxígeno en la sangre. Es decir, se produce una transmisión luminosa a través del dedo y, a continuación, se mide la señal recibida para deducir el nivel de oxígeno e identificar una pulsación.

El primer Wearable donde se trasladó el principio de funcionamiento descrito a un formato pulsera fue en el Mio LINK (2014). En este dispositivo los elementos de emisión óptica y de lectura se encuentran adyacentes y, en lugar transmitir luz a través del dedo, se registra la reflexión de está a través del interior de la muñeca. Además, en vez de trabajar con fuentes de luz roja e infrarroja, se emplea un LED de color verde junto con un sensor óptico.

La técnica fotopletismográfica, tal y como se aplica en la mayoría de los Wareables, no está exenta de lecturas imprecisas y funcionamientos anómalos producto de la inadecuada colocación de la pulsera y el ajuste de esta, el movimiento de la muñeca, la pigmentación de la piel y sudoración de cada individuo o la temperatura de sus extremidades. Otro aspecto que hace inadecuada esta técnica es la existencia de una patología previa asociada a niveles bajos de hemoglobina. Por último, como se ha comentado, la PPG lleva tiempo facilitando al personal sanitario información fiable sobre el SpO2 y el pulso de un paciente, pero no ha demostrado ser totalmente efectiva en la medición de otros niveles, y es aquí donde la mayoría de los fabricantes están intentando desarrollar algoritmos más capaces y precisos para sus Wearables.

Hacia la completa monitorización de la información biométrica
Como podéis comprobar estamos asistiendo a una evolución tecnológica que intenta condensar en gadgets -de bajo coste- parte de la experiencia tecnológica del mundo médico. El objetivo no es otro que llegar a conocer, de manera fiable y no invasiva, las constantes vitales y ciertos marcadores de un individuo. En este sentido hay que recordar la capacidad que ya se tiene, a partir del Apple Watch 4 (2018), de hacer un sencillo electrocardiograma a través del electrodo existente en la corona de este reloj, o los planes declarados de esta compañía de ir incorporando nuevos sensores a su familia de relojes inteligentes para conocer, por ejemplo, el nivel de glucosa en sangre junto a otras capacidades de inteligencia artificial -desde su Cloud- para ayudar en la interpretación y seguimiento de los datos biométricos de un usuario.

Lamentablemente, esta rápida evolución también genera confusión entre los usuarios cuando se nos ofrecen ciertas capacidades a través de la contratación de servicios Premium o se escribe, por ejemplo, sobre los peligros de la apnea del sueño y el análisis de los ronquidos que pueden hacer los relojes Fitbit Versa 3 (2020) y Fitbit Sense (2021), o el registro del estrés y el estado de ánimo que, supuestamente, hace el Fitbit Sense 2 (2022)

Colección | Actividad física y podómetro (1) | Pulsómetro y posición GPS (2)

 

HarmonyOS y los Sistemas Operativos Móviles

agosto 16, 2019 on 10:48 am | In colección, copyleft, open source, hist. informática, hist. telecomunicaciones, m2m, iot | 2 Comments

Adolfo García Yagüe | Bueno, bueno… pues parece que al final el nuevo sistema operativo de Huawei no será una distribución basada en Android o Linux. Por lo visto está construido alrededor de un microkernel (lo cual le aleja de estos) y, además, Huawei ha dado a entender que ya lo tenía desarrollado para sus sistemas embebidos e IoT y “solo” había que adaptarlo al mundo Smartphone. Originalmente se llamaba HongmengOS y, tras su apresurado lanzamiento, se llamará HarmonyOS. En todo caso, se espera que su adopción en los teléfonos de Huawei sea gradual y dependerá de cómo se desarrolle el conflicto entre EE.UU. y China que, evidentemente, no beneficia a ambas empresas ni a sus usuarios. Por eso es prematuro vaticinar cuál será su éxito.

De lo que no cabe ninguna duda es que no hay que subestimar a Huawei, y mucho menos a China. Tampoco hay que minusvalorar la arquitectura y diseño de HarmonyOS ya que, al menos sobre el papel, es muy potente y se ha concebido para cualquier dispositivo, incluidos vehículos y electrodomésticos. De hecho, desde hace algún tiempo, Google comenta la hipotética jubilación de Android a favor de FuchsiaOS, este último también se plantea como un sistema operativo universal.

Volviendo a Huawei y HarmonyOS, parece evidente que éste se las tendrá que ingeniar y contar con un módulo de emulación que le permita ejecutar la mayoría de las Apps de Android. Esto solo será un paliativo porque, en el medio plazo, uno de los grandes retos, será ganarse el apoyo de los desarrolladores y la industria para ser totalmente independiente de Google. Sin esta característica no creo que llegue muy lejos aunque su arquitectura y potencia sean fabulosos. En este sentido Huawei ya anunciado que HarmonyOS será Open Source y que cualquiera tendrá acceso al código. Dicho esto habrá que ver que entiende este fabricante por Open Source y cuál es su capacidad de persuasión para captar la atención de otros fabricantes y desarrolladores. No obstante es una buena noticia y es la mejor forma de desactivar cualquier suspicacia sobre la seguridad o el control “gubernamental” del teléfono.

Si en el hardware hemos asistido a una evolución casi uniforme, en el software hemos conocido unas cuantas iniciativas que han condenado al olvido a algún fabricante. Hace bien poco el propio Bill Gates recordaba que su mayor fracaso ha sido la movilidad, y eso que Microsoft lo lleva intentando desde 1997 con su Windows CE y antes, en 1993, con su Windows Pen. Desde entonces esta compañía se ha empeñado en convencernos de que la movilidad era una versión para pantalla pequeña del Windows de escritorio (teléfono, acceso menús, navegación, configuración). Hasta que no aparecieron los primeros Nokia Lumia, allá por el 2011, no entraron en razón y ya era demasiado tarde.

A Nokia y a Ericsson les pasó algo parecido. Sus reflejos funcionaron muy bien cuando se hicieron en 1999 con EPOC. Este sistema operativo fue desarrollado por los británicos de Psion, otro histórico. La arquitectura de EPOC permitía abstraerse fácilmente de un determinado hardware y la comunicación de procesos era sencilla y modular. Nada que ver con los anteriores monolitos software. El Ericsson R380 fue el primer teléfono basado en la versión de 32 bits de EPOC, siendo este renombrado y popularizado bajo el nombre de Symbian. A partir de aquí fueron apareciendo numerosos teléfonos inteligentes basados en este sistema operativo que, en la mayoría de los casos, estaban inspirados en un entorno gráfico similar a una PDA. Symbian compartió época con PalmOS, BlackBerry OS y Windows Mobile. De aquel momento, quizás el más rupturista, fue el DangerOS donde ya se aprecian algunos detalles que luego veríamos en Android. Otro que supuso un cambio fue el LG Prada y su pantalla táctil capacitiva, pensada para ser usada solo con los dedos de la mano. En cualquier caso el Danger Hiptop y el LG Prada fueron teléfonos que tuvieron poca repercusión comercial.

Eran años donde los fabricantes apenas arañaban cuota a Nokia o a RIM con sus Blackberry. Nokia tenía la potencia y calidad para inundarnos de teléfonos, sin importar en que gama compitieran: alta, media o baja. Por su parte, Blackberry supo detectar la importancia del correo electrónico para las empresas. RIM venía del mundo de los buscapersonas bidireccionales. Este mercado se inició hacia mediados de la década de los ´90 por la venerable Motorola y la apuesta de RIM fue usar Mobitex, una red radio sencilla y económica, para que los Operadores prestaran este servicio. Eran tiempos donde el uso del correo electrónico en las empresas empezó a ser una revolución y RIM tuvo clara la visión de crear un dispositivo que, en lugar de presentar los escuetos mensajes de busca, sirviese para recibir y contestar los correos electrónicos de la organización. Además, como era algo empresarial, ya se consideró la importancia de la seguridad del dispositivo y, si se deseaba, la Blackberry podía encriptar toda la información en ella contenida.

Así las cosas, llegó Apple y su cuidada capacidad y experiencia para construir un hardware tan bueno o mejor que el de Nokia. Además, desde hacía unos años, Apple gozaba del éxito de iTunes y su iPod lo que le permitía tener claras las ideas: la creación de un ecosistema. No se trataba solamente de hacer un buen teléfono, había que crear una plataforma (hoy lo llamamos nube) donde vender aplicaciones y guardar datos… La idea no era totalmente nueva y hay antecedentes de cosas parecidas, incluso en los tiempos de WAP (Wireless Application Protocol) los Operadores de Telecomunicaciones lo intentaron (e-moción de Telefónica o Conect@ de Airtel) pero nadie como Apple supo darle forma.

La historia puede seguir con Android y su marketplace controlado por Google. Lo importante es que a lo largo de estos años numerosos sistemas operativos vagan en el limbo de la obsolescencia y, aunque algunos sigan en activo, pasan desapercibidos: FirefoxOS, Ubutu para teléfonos, MeeGo, GEOS, Maemo, Tizen… No lo olvidemos. Está por ver que pasara con HarmonyOS.

Colección | 1G o primera generación de telefonía móvil | Los Móviles | GTP y la seguridad en redes 4G y 5G NSA

Energía Eléctrica y Análisis de Datos

junio 18, 2019 on 5:36 pm | In análisis de datos, descarga textos pdf, m2m, iot | No Comments

Adolfo García Yagüe | En esta presentación se estudia una aplicación real del análisis de datos e IoT: El uso de la Energía Eléctrica y EMIOS de Energy Minus+. Sin pretender ser un curso de electrotecnia, en la primera parte he intentado resumir alguno de los conceptos relativos a la corriente alterna y al mercado eléctrico español. Soy consciente de que por ciertos temas paso de puntillas, e incluso alguna diapositiva puede no resultar 100% precisa para un experto. Pido disculpas por ello. He intentado rebajar el nivel de los conceptos expuestos para acercarlo al día a día de cualquier persona interesada en estos temas.

Agenda

Energía y Datos

  • La importancia del análisis de datos
  • Datos de consumo
  • Consumo eléctrico
  • La importancia del contexto
  • ¿Qué nos pueden ofrecer los datos?

Conceptos básicos

  • Corriente alterna
  • Magnitudes vectoriales
  • Monofásico y trifásico
  • Voltaje y corriente
  • Potencia
  • Energía activa
  • Energía reactiva
  • Factor de potencia y coseno de φ

Laboratorio

  • Buscapolos y pinza amperimétrica
  • Midiendo en un cuadro eléctrico
  • El osciloscopio
  • Laboratorio de recogida de datos
  • Medidor ModBus
  • Sonda de temperatura y luminosidad
  • Pasarela TELNET BabelGate G5002
  • Node-RED

Mercado eléctrico

  • Actores del mercado eléctrico
  • La importancia del Sistema
  • Perfil energético y tarifas
  • Tarifa 2.0A
  • Tarifa 2.0DHA y 2.1DHA
  • Tarifa 3.0
  • Termina de energía reactiva
  • Maxímetro
  • Ejemplo de una factura 3.0A
  • Tarifa 3.1
  • Tarifas 6.x

Monitorización eléctrica

  • Red de Monitorización
  • Datalogger, Medidor, Modem
  • Monitorización de contador fiscal
  • Medidor Trifásico
  • Transformador de corriente de 50A
  • Temperatura, humedad y luminosidad

Casos Prácticos con EMIOS

  • Configuración de tarifa
  • Simulación de una factura
  • Evolución del consumo
  • Ajuste de potencia
  • Energía reactiva
  • Configuración de Widgets
  • Consumo general y temperatura
  • Consumo alumbrado y luminosidad
  • Detección consumo anómalo
  • Estudio de cambio de iluminación

[Descargar ponencia]

Ciberseguridad e IoT

marzo 28, 2019 on 6:15 pm | In academia, análisis de datos, cibercultura, ciberseguridad, descarga textos pdf, internet, m2m, iot, telecomunicaciones | No Comments

Adolfo García Yagüe | Estos días estoy dando un curso sobre Ciberseguridad e IoT en Fuenlabrada. Se enmarca en un proyecto impulsado por el propio Ayuntamiento y la Unión Europea. Se pretende formar a los asistentes en nuevas capacidades con el fin de reforzar y actualizar su curriculum. Es una iniciativa admirable que ayuda a crear sociedad y, sobre todo, porque me está permitiendo conocer la realidad de otras personas. En este módulo denominado “IoT” comparto el papel de formador junto a otros profesionales de Flexbot, la Fundación Telefónica y la Fundación Santa Maria la Real. Como digo es un privilegio estar ahí.

Os dejo la presentación del curso que estoy dando por si os resulta de interés. Como digo va sobre IoT, economía de datos, comunicaciones y seguridad. Muchas de las cosas que aquí trato son totalmente trasladables a nuestra cotidianeidad como usuarios de un equipo informático o un Smartphone. También, como no, se aclaran conceptos acerca de la importancia de los datos o 5G y como puede cambiar el entorno en el que vivimos. Milma Fuenlabrada. Laboratorio IoT

Agenda

Acerca del TELNET
Conceptos de IoT y Sistemas Embebidos

  • Telemetría y telecontrol
  • Smartphones
  • Internet de las Cosas
  • Tratamiento y economía de datos, Big Data
  • Dispositivos basados en Microcontrolador y Microprocesador
  • Arduino
  • Raspberry PI
  • TELNET BabelGate
  • Riesgos Amenazas y Ataques

Software y Hardware

  • Seguridad Física
  • Identificación de vulnerabilidades
  • Bootloader, Kernel, drivers y librerias
  • Aplicaciones
  • Cifrado
  • Repositorios de claves
  • Puertos Abiertos, Banners y Port-Knocking
  • API (Application Program Interface)
  • Ejemplo de instalación y mantenimiento desatendido
  • Electrónica y Buses
  • Memorias SD
  • SIM (Subscriber Identity Module)
  • TPM (Trusted Planform Module)

Conectividad Inalámbrica de un dispositivo IoT

  • Conectividad Radio
  • Frecuencias
  • Topología, seguridad y radio
  • Servicios M2M de Operador
  • Sigfox
  • LoRa
  • Zigbee
  • Z-Wave
  • Bluetooth
  • IEEE 802.11

Buses y Redes Industriales

  • Seguridad lógica en Redes Industriales
  • PRIME/COSEM

[Descargar ponencia]

5G, no todo se reduce a una rivalidad entre EE.UU, China y Europa

septiembre 24, 2018 on 6:25 pm | In análisis de datos, m2m, iot, telecomunicaciones | No Comments

Adolfo García Yagüe | Esta mañana leía un interesante artículo de Ignacio del Castillo a quien habitualmente sigo. He de decir que me gustan sus análisis aunque en este caso eché en falta más ángulos desde los que comentar la cuestión. Digo esto porque su último texto sobre 5G se plantea en términos competitivos entre Europa, EE.UU. y China, o fabricantes como Qualcomm y Broadcom. Tras la lectura de estas líneas da la sensación de que la rápida implantación de esta tecnología es una cuestión de Estado en donde “ganará” el País que antes tenga disponible el servicio.

Para llegar a esta conclusión se recurre incluso a una referencia publicada en The Wall Street Journal donde se dice que el éxito digital de EE.UU. es consecuencia de la rápida adopción de 4G. No sé ¿y qué ha sucedido con Amazon siendo contemporánea de la telefonía GSM? ¿Y Google y su Android no son de la época 3G? ¿GPRS?… De Apple no hablemos pues su iPhone y la eclosión de las Apps reposaban sobre la humilde conectividad que ofrecía GPRS y 3G.

Es cierto que 5G permitirá el desarrollo de servicios que hoy parecen inalcanzables con las actuales tecnologías radio. Fundamentalmente me refiero al coche conectado autónomo y el desarrollo de IoT en miles de dispositivos. Más allá de esto, creo que las actuales tecnologías LTE 4G satisfacen las necesidades de navegación y conectividad de millones de usuarios. Qué nadie me interprete mal: no quiero decir que 5G no sea importante y un gran salto, únicamente que detrás de su adopción hay innumerables cuestiones que escapan al texto de Ignacio.

Me parece un poco exagerado plantear solo el análisis solo en términos de rivalidad entre países, aunque pueda llamar mucho la atención el subtítulo que subyace: Oriente vs. Occidente. Aquí no solo hablamos de la tecnología radio y la estación base o BTS. Diría que esto ya está superado y está “atado y bien atado” por las patentes de cada fabricante y los estándares del 3GPP. Ahora la pelota está en el tejado de los Operadores de Telecomunicaciones y no parece claro que tengan la misma urgencia de desplegar 5G salvo que quieran publicar una nota de prensa y así llamar la atención de accionistas, usuarios y periodistas.

Empecemos por el plan de frecuencias. No está claro la idoneidad de las frecuencias asignadas a este servicio y la naturaleza del despliegue actual. Quiero decir que si queremos usar 3500MHz tenemos que poner muchas más estaciones base porque, desde las actuales, hay dificultad para dar cobertura a todos los usuarios y objetos. Aunque sea una opción viable, instalar Small Cells (estaciones muy pequeñas) en cada esquina de una ciudad cuesta mucho dinero, por lo tanto el problema no se reduce solo a comprar el 5G de un determinado fabricante. También podemos optar al segundo dividendo digital y usar la frecuencia la baja de 700MHz, incluso esperar a los 1500 MHz pero esto no será algo rápido. Por cierto, dan escalofríos cuando el Gobierno sondea el mercado sobre el uso de la banda de 26GHz. Por esta razón, parece lógico pensar que, más tarde o más temprano, se debería producir un desacople del actual binomio frecuencia-servicio y las actuales frecuencias bajas (700, 850 y 900 MHz), de mayor propagación y menor ancho de banda, se reserven para aplicaciones IoT y coches en 5G, y las frecuencias altas (1800, 1900, 2100 y 2600MHz) se destinen a la navegación y Apps, también en 5G, e incluso 4G. Pero todos sabemos que estas cosas, los apagones y los reframing, van despacio y suelen estar regulados y, de la noche a la mañana, un operador no se puede “cargar” un servicio.

Capacidad. Plantear o dar a entender que el 5G supera la capacidad de las actuales comunicaciones por fibra es equivocado o al menos incompleto o inexacto. Lo cierto es que a la fibra instalada le queda recorrido para crecer durante décadas con tecnologías como XGSPON o NGPON 2. Esto, a priori, es tan fácil como actualizar con pequeñas modificaciones las actuales OLT GPON y las redes de fibra. En el mundo radio esto no es nada fácil porque exige una minuciosa planificación, contratación de emplazamientos e instalación de nuevas antenas. Por eso, cualquier cambio en la red de acceso radio se hace con mucha cautela y pies de plomo.

En este sentido una vez más me viene bien el comentario que hace The Wall Street Journal. En él se dice que el éxito de Netflix ha sido gracias a que EE.UU. ha liderado la tecnología 4G. En fin, no soy capaz de ver esta relación cuando está demostrado que el éxito de esta plataforma de TV se basa en producir sus propios contenidos y en distribuirlos “devorando” ancho de banda de las redes de fibra y sus tarifas planas. Dicho de otro modo: si dependiéramos del ancho de banda que tenemos en nuestro plan de datos móvil me temo que no veríamos tantas series… Pensemos que mucho antes de cualquier tecnología móvil ya existía en EE.UU. una industria cinematográfica potentísima que solo tenía de trabajar para el dueño que mejor pague…

Servicios y coche conectado. Es cierto que la adopción de 5G abrirá el mercado a nuevos actores que aún no existen. Seguramente estos vengan a través del mundo IoT porque, en el mundo del coche conectado-autónomo, me temo que “el pescado ya está vendido”. Examinado la posible cadena de valor, a menos que alguien invente algo totalmente novedoso, los actores ya están y dudo que se dejen robar una porción del pastel. Empezando por el vehículo: dudo que BMW, el grupo Volkswagen, PSA, Toyota o Daimler dejen de vender coches. Ellos saben fabricar un coche y todos confiamos en alguna de estas y otras marcas (sin olvidar los puestos de trabajo que generan en Europa), tienen sus líneas de producción acostumbradas a cambiar, redes de distribución, proveedores auxiliares, logística, dominan los entresijos políticos, etc. Un caso a destacar sería el de Tesla que tantas pasiones despierta pero realmente cuál es su diferencial ¿Un coche lujoso, su sistema de navegación, sus baterías, puntos de carga que han sido subvencionados?

Por otro lado está el sistema de navegación de a bordo y detección de obstáculos. Aquí puede existir sitio para la innovación, no lo sé. Ahora se están probando muchos sistemos que convergerán con uno, el mejor, y que terminará siendo integrado durante la fabricación del coche. Una vez más dudo que a gente como Bosch esto le suene raro.

Hablemos de cartografías, planificación de rutas, etc. ¿Quién fue el primero y hoy por hoy es el más preciso? Google. Realmente aquí es donde está uno de los diferenciales. Ellos han cartografiado medio mundo y saben recoger y tratar datos masivamente. Con todos mis respetos, la información del tráfico y rutas facilitada por la DGT o los Ayuntamientos, palidece con la precisión de Google. Por eso, si dependemos de los sistemas públicos para que un coche sea autónomo estamos perdidos…

Otro eslabón que cobra fuerza en esta cadena de valor, especialmente en los últimos años, es el alquiler del servicio de transporte. Parece normal que en el futuro existan empresas ofreciendo este servicio con coches autónomos. Todos conocemos los actores que se han posicionado aquí: desde coches sin conductor donde tú conduces, hasta aquellos que viene a recogerte. En último caso, a la vista de lo que en las últimas semanas está pasando con Uber, Cabify y las licencias VTC, parece poco recomendable meterse aquí sin garantías… Me temo que el impacto social es tan fuerte que pocos gobernantes están dispuestos a quemarse en un conflicto con el mundo del taxi. Este ejemplo también debería servir como “aviso para navegantes” para todos aquellos innovadores que pongan en entredicho la viabilidad económica de un servicio o colectivo tradicional…

Por último y vuelvo a los operadores: Ellos y solamente ellos explotarán las nuevas y futuras redes 5G y por las razones anteriores, actualmente, no tienen tanta urgencia en correr hacia un nuevo despliegue.

NB-IoT y LTE Categoría M, mientras llega 5G

septiembre 25, 2017 on 2:51 pm | In m2m, iot, telecomunicaciones | 1 Comment

Adolfo García Yagüe | Todo el mundo habla del próximo 5G y, entre otras cosas, de lo maravilloso que será para IoT (Internet of Things). Mientras llega, se implanta y aparecen los primeros dispositivos IoT los fabricantes -y los operadores- nos giramos hacia nuevas tecnologías como NB-IoT (Narrow Band IoT) y LTE Cat. M o LTE-M (LTE Categoría M) que prometen adaptar a IoT las actuales redes LTE y frenar el avance de tecnologías como Sigfox y LoRa

En efecto, la semana pasada Orange publicó una nota de prensa donde nos informaba del éxito conseguido al hacer que sus BTS de Ericsson funcionaran con una Pasalela IoT, equipada con un modem LTE Cat. M, de TELNET Redes Inteligentes. Parecido a este ensayo, Telefónica mostró NB-IoT al principio de este año en el Mobile Word Congress.  En esta ocasión NB-IoT también interoperaba con Ericsson, y era un sensor de detección de apertura de tapas de alcantarilla fabricado por la aragonesa antes mencionada.

Ambos casos evidencian el interés de los operadores por comprobar que su actual red móvil puede “conectar” con un dispositivo IoT de última generación. También se pone de manifiesto la importancia de estas redes en la evolución de IoT y la necesidad de dejar atrás -cuanto antes- las antiguas redes 2G y 3G. Menos evidente, e igual de cierto, es el peso que han cogido otras tecnologías como Sigfox y LoRa en esta carrera del Internet de las Cosas.

En España, Sigfox es una red propietaria cuyo operador es Cellnex. Esto significa que hay que llegar a un llegar a un acuerdo con ellos si deseas que tu IoT aproveche esta red. La empresa que está detrás de esta tecnología es la francesa Sigfox. Realmente en Sigfox se utiliza una banda de radio libre -como en Wifi o en Zigbee- por lo tanto ni Sigfox ni Cellnex pagan por el uso del espectro. Algo parecido pasa con LoRa. Lo que sucede con LoRa es que es más abierto y define solamente el nivel radio. En cambio, en Sigfox, además del nivel radio, tus dispositivos IoT (y tu) utilizáis otros servicios para facilitarte la vida. Lógicamente, por esto se paga.

Sigfox apareció hace ya unos años y hoy se puede disfrutar de un buen servicio en numerosos países. En el mercado se pueden encontrar -sin problema- chips con la capacidad radio Sigfox en las frecuencias (libres) europeas y americanas. El consumo eléctrico, importantísimo en aquellos dispositivos IoT que son autónomos y se alimentan con baterías, es muy bajo comparado con la alternativa GPRS (2G). Esto juega a su favor y la sencillez del despliegue de Red. Hay otro aspecto menos conocido relacionado con la robustez frente al uso de inhibidores radio, razón por la cual es empleado por la empresa Securitas en el caso que se llegue neutralizar la propagación de una alarma. En contra está lo limitado del ancho de banda que ofrece y el hecho de usar una frecuencia “libre”. Esa limitación del ancho de banda hace que sea muy difícil -por no decir imposible- el uso de Sigfox en aplicaciones IoT donde se envíe un volumen importante de datos. Sigfox se ha pensado para que los dispositivos envíen pequeños mensajes alertando de un hecho. Este canal ascendente es limitado, al igual que el descendente, tan importante en tareas de mantenimiento y teledescarga de un nuevo firmware. No obstante, a su favor, cuenta el ser una tecnología muy dura, rápida en el despliegue de Red, de bajo consumo eléctrico, sencilla, económica y, realmente, la primera pensada para IoT.

Aunque LoRa (Spread Spectrum) utiliza un nivel radio diferente a Sigfox (Ultra Narrow Band), el silicio LoRa también consume poco, es robusto, sencillo y económico. No obstante LoRa es una tecnología donde no se especifica nada más que el nivel radio. Si deseas o necesitas un Cuadro de Mando, o tienes que resolver el handover de un dispositivo IoT entre dos antenas LoRa (o instalar estas y asegurar la cobertura), te lo tienes que programar y montar tú. Lógicamente, esto choca con aquella aproximación en la que hay que buscar socios especializados en cada porción de tarta IoT. Sin olvidar alguna de las limitaciones de Sigfox, LoRa puede ser visto como la solución de comunicación IoT totalmente libre. Orange, en Francia, ha seleccionado LoRa como tecnología antagónica a Sigfox permitiendo desplegar servicios IoT que sería difícil realizar con 2G, 3G o 4G.

Tras estos párrafos es más fácil entender el anuncio de Orange España, o la experiencia de Telefónica con NB-IoT. En ellos nos hablan de la importancia que juega la radio en las comunicaciones IoT y de lo lejos que están los actuales 2G, 3G y 4G de estos temas. Realmente estas tecnologías se concibieren para que hablaran las personas (2G), tuviéramos ancho de banda y navegáramos un poco (3G); y la red fuera más eficiente al permitir IP y tuviéramos más ancho de banda (4G). En ningún caso se pensaron para que de la Red colgaran decenas de miles de dispositivos IoT de una única BTS, ni que estos estuvieran “dejados de la mano de Dios” consumiendo muy poco y enviando unos pocos datos. Tampoco se pensó que estas comunicaciones garantizaran el Tiempo Real de algunas aplicaciones IoT, ni que el uso del espectro radio fuera más eficiente (se ocupara poco espectro y el caudal de datos fuese menor).

Ahí es donde reside la fortaleza de NB-IoT y LTE Cat. M. Hasta que llega 5G, ambas resuelven sobre las actuales redes LTE los servicios IoT que se demandan. En las dos tecnologías se resuelve el ancho de banda y el uso del espectro. No obstante, en esta primera fase de interoperabilidad y fabricación de módems, estamos un poco lejos del consumo energético que tenemos con Sigfox y LoRa. También la necesidad de Tiempo Real puede no ser la esperada. Aun así, es la evolución de las actuales redes móviles para soportar IoT.

IoT y M2M, lecciones aprendidas

octubre 26, 2016 on 11:35 pm | In innovación, m2m, iot | 3 Comments

Adolfo García Yagüe | Hace cuatro años publiqué aquí un pequeño texto sobre M2M e IoT. Desde entonces el mercado ha madurado, pero no tanto como era de esperar. Apenas quedan 3 años para llegar al 2020 y la predicción de conectar 31.000 millones de dispositivos parece, a finales del 2016, algo difícil de conseguir. Como sucede en la adopción de nuevas tecnologías, en IoT hemos transitado por diversos ciclos anímicos: desde el entusiasmo desbocado hasta la confusión generalizada. Hoy, tras visitar la 2ª edición del IoT World Congress, parece que estamos entrando en una etapa de realismo y madurez. Estos ciclos de entusiasmo, confusión, desánimo, realismo y despegue no son nuevos en la historia de la tecnología y, ni mucho menos, son exclusivos de IoT. De hecho Gartner suele analizar la evolución de tecnologías emergentes a través de sus Hype Cycle. Si hacemos caso de este análisis comprobamos que el año pasado “IoT” toco el techo de máxima expectación y ahora, en el 2016, ha desaparecido del diagrama constatando que ya no estamos hablando de una tecnología emergente. No obstante podréis comprobar que en 2016 sigue en pendiente de ascenso la expectación hacia las plataformas de gestión y administración IoT.

Garner Hype Cycle 2015

Gartner Hype Cycle 2016

En ciertos aspectos la tecnología no ha estado a la altura de las necesidades: Dispositivos caros, fiabilidad y seguridad limitada, soluciones cerradas, autonomía limitada por elevado consumo eléctrico, comunicaciones caras y poco flexibles, etc… Por otra parte, los planes de negocio han estado muy alejados de la realidad. Como aún estamos a tiempo de rectificar y, por supuesto, para los recién llegados, he querido resumir algunas lecciones aprendidas.

Por dónde empezar (de nuevo)
Comencemos analizando servicios tradicionales para identificar ineficiencias y mejoras ¿Cuál es el objetivo de esto? Obviamente, lograr ahorro de costes o incrementar los ingresos en la explotación y prestación de un servicio. Con parte de estos ahorros o ingresos extra deberíamos ser capaces de “pagar la fiesta” del IoT. Si no salen las cuentas, mejor no seguir.

¿Por qué adoptar tecnología IoT o M2M?

A continuación analicemos si la adopción de IoT/M2M puede mejorar la calidad del servicio, aportando algún valor añadido o mejorando la experiencia del usuario para buscar su fidelidad.

Por último están los nuevos modelos de negocio. A veces, el análisis de un servicio a través de los datos que rodean a este, nos permite descubrir que es posible generar algún tipo de valor o beneficio. Incluso, esta extracción de información nos puede poner en la pista de la creación de un nuevo servicio, tangencial o complementario, al servicio original.

Ejemplos de aplicaciones M2M e IoT

La paradoja Do it yourself
Cómo comentábamos, las expectativas han estado por delante de la realidad técnica. La aparición de numerosas plataformas de desarrollo como Arduino, Raspberry Pi o Galileo, han generado una paradoja. Estas y otras placas han facilitado que cualquier individuo con una buena idea y suficientes conocimientos técnicos haya desarrollado soluciones IoT. Muchas de estas soluciones han captado importante atención mediática, incluyendo acceso a fondos públicos porque todos hemos intuido una revolución en ciernes y, sobre todo, un foco de innovación y progreso.

Consideraciones sobre el hardware IoT

La realidad es que detrás de la mayoría de estas iniciativas había poco más que una placa de desarrollo y una pequeña aplicación. Es decir, durante estos años nos hemos movido en un terreno caracterizado por prototipos y no hemos sido capaces de transformar ideas (algunas muy buenas) en productos. La paradoja reside en que esa imagen de “cualquiera con dos plaquitas puede hacer una solución IoT” ha amplificado la expectación a la vez que ha enturbiado la imagen de las soluciones y su aplicació real. Tras estos años ha quedado demostrado que pasar de “dos plaquitas” a un producto fabricable, eficiente y competitivo hay un largo camino.

Evolucionar del prototipo al producto

Verticalidad frente modularidad
Estrechamente relacionado con lo comentado en el párrafo anterior, es la existencia de soluciones verticales monolíticas frente al desarrollo de elementos modulares y/o individuales. Sin pretender restar mérito a nadie, todo lo contrario, es preciso reconocer que muchas de las iniciativas nacidas en el seno de startups se caracterizan por ser soluciones donde el sensor o elemento físico solo sabe hablar con su cuadro de mando a través de sus piezas software intermedias. Suele resultar difícil, e incluso imposible, desacoplar niveles para trabajar con diferentes planos de gestión IoT o base de datos. De manera inversa, un buen plano de gestión puede ser incapaz de funcionar con otros dispositivos IoT que no sean los originales. Otro efecto de esta aproximación de desarrollo monolítico es la dificultad de “mantener vivo” y actualizado todo el vertical siendo, además, competitivo en precio y prestaciones.

Arquitectura IoT modular

Por esta razón cada vez se impone más centrarse en el desarrollo de una pieza del puzle IoT, hardware o software, y trabajar en cómo interoperar con el mayor número de plataformas Cloud e IoT; o pasarelas IoT, sensores y tecnologías de comunicaciones.

Cadena de valor
Al inicio de la revolución IoT también se pretendido reconfigurar la cadena de valor. Embriagados por el exceso de expectativas no se ha dudado de desembarcar en el cliente final para poner en marcha una solución M2M/IoT. Esta aspiración es muy loable y meritoria pero el tiempo nos ha demostrado que, además de suministrar una solución, es necesario integrarla en los procesos de negocio del cliente. Para esto hay que entender bien su realidad (la del cliente) y quizás dominar ciertas tecnologías fuera de nuestro alcance.

Cadena de valor IoT

Y aquí es donde necesitamos compañeros de viaje en nuestra aventura IoT. Para acabar recurro a ese conocido proverbio africano que dice «Si quieres ir rápido camina solo, pero si quieres llegar lejos anda acompañado»

¡Suerte!

Pasarela IoT de Telefónica Globalrider

julio 19, 2016 on 3:38 pm | In análisis de datos, globalrider, m2m, iot | 5 Comments

Adolfo García Yagüe | Afrontar el desarrollo y fabricación -en menos de 4 meses- de un dispositivo IoT en el que se integran 20 sensores es un pequeño reto. Si a este desafío añadimos la necesidad de que este elemento satisfaga los exigentes requerimientos que supone dar una vuelta al mundo sobre una moto de trail, rozamos la proeza. En este artículo queremos compartir con vosotros las claves de diseño que han hecho posible la conexión de la moto de Hugo Scagnetti.

Potencia y capacidad de proceso
Ante el reto de Telefónica Globalrider, el primer paso fue seleccionar un núcleo de proceso lo suficientemente potente para absorber el caudal de datos y contenidos multimedia que se generarían a lo largo de 37.000 kilómetros. Este micro también tenía que ser capaz de gestionar “holgadamente” los sensores y líneas de comunicación que de él dependen. Por último, la plataforma elegida, nos tenía que ofrecer un marco sencillo y flexible para poder desarrollar diferentes aplicaciones software. Estas y otras cuestiones han sido atajadas mediante el empleo de un SoC (System on chip) E3845 de la firma Intel Corporation. Este chip es el hermano mayor de una familia de procesadores basados en Atom pensados para su uso en dispositivos móviles y equipos IoT. El E3845 cuenta con cuatro núcleos trabajando a una frecuencia de 1,91GHz. En él también se integran los periféricos auxiliares para la gestión de entradas y salidas, gestión de memoria y tratamiento de vídeo. Es una pequeña bestia que nos aporta capacidad de proceso facilitando el objetivo de hacer inteligente a la moto.

Globalrider - Arquitectura hardware de Pasarela IoT Globalrider

Por poner un ejemplo de la inteligencia de la Pasarela IoT cabe destacar el análisis en tiempo real que hace de la velocidad e inclinación de la moto para predecir accidentes. Es decir, si la Pasarela identifica un patrón de caída, nos enviará un mensaje de alta prioridad alertándonos de un accidente inminente. Otro signo de inteligencia y capacidad es el tratamiento que se hace de todos los datos que captan los sensores, aplicando a cada dato muestreado una referencia temporal y posición GPS. Por último, es importante recordar, el importante esfuerzo de proceso que supone la adquisición de vídeos y fotos, su transcodificación, y posterior envío a través de redes de telefonía móvil de baja capacidad.

Como hemos dicho, el SoC Intel E3845 forma parte de una familia que integra como núcleo el microprocesador Atom. Como no podía ser de otra forma, este micro es heredero de la arquitectura x86 de Intel lo que facilita enormemente la portabilidad de desarrollos software previos. TELNET, como miembro de la IoT Solutions Alliance de Intel, ya fabrica y comercializa otras Pasarelas IoT para aplicaciones Industriales y Hogar Digital. Para ambos casos hemos recurrido al Atom E3815, menos potente pero 100% compatible a nivel software e incluso huella de pines.

 

Arquitectura Software
Los mayores quebraderos de cabeza de un sistema embebido están relacionados con el software, concretamente con el sistema operativo y los controladores o drivers. Si no se tiene pleno control sobre todo lo que está “corriendo” dentro de un sistema embebido, lo que en apariencia puede funcionarnos a la primera puede traicionarnos en cualquier momento y desencadenar una catástrofe, sin mencionar inadvertidos agujeros de seguridad. Esta es una de las razones por la que en TELNET nos gusta armar nuestra propia distribución de Linux a través de Buildroot o Yocto.

Globalrider - Aquitectura software Pasarela IoT TENET

Sobre el kernel de la Pasarela IoT de Globalrider están ejecutándose seis gestores principales. Estos gestores administran agentes especializados en diferentes tareas: desde analizar la información que recogen los sensores hasta mantener la conectividad de Hugo o interactuar con la pasarela.

El Gestor de Supervisión o Supervisor Manager se responsabiliza de la administración del resto de Gestores y, a través de él, accedemos e interactuamos con la Pasarela. Este Gestor tiene competencia sobre el Display  y los pulsadores de a bordo que representan la vía más cómoda y segura para interactuar con la Pasarela mientras la moto se encuentra en marcha. También nos ofrece un interfaz Web para facilitar la configuración avanzada desde un móvil o tablet. De igual manera este Gestor de Supervisión es la puerta de entrada remota a todo el sistema.

GPS Manager tiene responsabilidad sobre la citada conexión para conocer el posicionamiento de la motocicleta en todo momento. Este Gestor tiene que entregar al resto de gestores (Supervisor, Sensor y Camera) una referencia horaria UTC (Universal Time Coordinate) junto con la posición de longitud, latitud y altitud. Esta información será la referencia temporal y espacial que acompañará a los datos adquiridos por los sensores.

Los datos recogidos a través de los sensores son procesados por Sensor Manager. Dentro de este Gestor identificamos un agente especializado en cada sensor (bio, ambiental, giroscopio, acelerómetro, etc). Además de los datos reportados por los propios sensores, también será responsabilidad de este Gestor calcular la velocidad de la moto a partir de la información de posición GPS. Sobre todos los datos captados o calculados, Sensor Manager estampará una marca de tiempo y localización para “posicionar” cada muestra.  Otra de las atribuciones de este Gestor tiene que ver con el análisis en tiempo real de los datos recogidos. Como comentábamos anteriormente, la Pasarela IoT de Globalrider dispone de un motor de reglas o políticas que nos permite identificar un patrón y desencadenar una alerta ante la inminencia de un accidente o cualquier otro evento. Por último Sensor Manager es el responsable de empaquetar los datos recogidos en archivos CSV (comma-separated values) para su posterior envío.

Globalrider - Elementos funcionales Pasarela IoT TELET

La naturaleza de los contenidos recogidos a través de la cámara de aventura nos obligó a programar un gestor específico para la gestión de la cámara y el tratamiento de fotos y vídeos: Camera Manager. En primera instancia este Gestor, a través del Camera Agent, se encarga del control remoto de la cámara. A continuación, a los contenidos captados, se les aplica la marca de tiempo y posición que establece GPS Manager. Más tarde, gracias a Transcoding Agent, podemos recodificar y comprimir los contenidos multimedia para adaptarlos al ancho de banda disponible. Con esta estrategia podríamos incluso recodificar para ofrecer un bitrate suficiente para hacer streaming a través de una conexión de bajo ancho de banda.  Por último, dentro de Camera Manager también hemos habilitado un agente denominado Secure Loop. Éste, al entrar en servicio, funciona en modo bucle capturando pequeños fragmentos de vídeo y enviándolos inmediatamente a los servicios Cloud de Telefónica.

Upload Manager es un repositorio temporal donde se van almacenando los archivos CSV generados en Sensor Manager y los contenidos multimedia de Camera Manager.  Además de esta atribución de almacenamiento, Upload Manager también se responsabiliza del correcto envío de todos los datos a través de una conexión segura lo que significa que tiene, entre otros atributos, capacidad para detectar errores de transferencia, gestionar reintentos, envíos parciales y cifrado. De igual forma, Upload Manager es capaz de priorizar envíos de alertas y vídeos de seguridad.

Para finalizar, mediante WAN Manager se administra la conectividad de la Pasarela IoT. Este gestor tiene competencia sobre la conexión M2M Global de Telefónica siendo capaz de conectarse a través de cualquier tecnología y servicio de telefonía móvil. Además, este gestor de conexión WAN, es capaz de establecer conexiones de respaldo a través de redes Wifi.

 

Puedes hacer el seguimiento de esta aventura en: telefonica.yamaha.globalrider.org

[Descargar texto]

Análisis del clima, 10.000 kilómetros después

julio 5, 2016 on 1:57 pm | In análisis de datos, globalrider, m2m, iot | No Comments

Adolfo García Yagüe | Quienes estáis siguiendo el día a día de esta aventura, habréis apreciado que hace unas semanas se produjeron pequeños saltos en el itinerario de Hugo. Esto obedece a que tuvimos cortes esporádicos en la comunicación de la Pasarela IoT. Como sabéis la pasarela está permanentemente conectada y envía datos cada pocos segundos.

A partir del análisis de los datos recogidos por la Pasarela tenemos la sospecha de que existe cierta relación entre estas pérdidas de conexión con una deficiente cobertura móvil y un fuerte incremento de la temperatura. Los problemas se manifestaron en el momento en el que Hugo llegó a Kazajistán y Uzbekistán. Analizando los datos de temperatura recogidos en el interior de la Pasarela (microprocesador, etapa radio y un sensor en placa) hemos descubierto que cuando se alcanza una temperatura próxima a 65ºC, la exterior sobrepasa 43ºC, y además la cobertura es muy baja acontece el fallo. Trabajamos sobre la hipótesis de que la baja cobertura hace que la radio de la pasarela IoT eleve la ganancia de sus amplificadores para garantizar la comunicación. Como es normal, esta amplificación eleva la temperatura del conjunto de radio afectando a la tarjeta SIM. Todavía no lo sabemos con certeza, sólo han sido tres fallos y no hemos podido identificar un patrón claro.

Ante esta situación -que tiene difícil análisis a más de 10.000 kilómetros de distancia y en ruta- estamos coordinando con Hugo la sustitución de la Pasarela IoT a su llegada a San Francisco. Entretanto confiamos que durante su periplo ruso la climatología y la cobertura móvil sean más benévolas.

Aprovechando que hemos tenido que enfrentarnos a datos climáticos, ¿por qué no hacer un repaso del primer mes de Globalrider desde la perspectiva meteorológica?

Globalrider - Ruta hasta el día 28 de junio (10.000 kilómetros)

 

Evolución de la temperatura
En el siguiente gráfico queda reflejada la evolución térmica durante los primeros 32 días. Para esta representación gráfica hemos recurrido a un mapa de calor. En este tipo de gráficos se asocia un color al valor de un dato o, como en nuestro caso, a la media aritmética de la temperatura registrada durante una hora. En este mapa destaca con gran claridad el cambio de temperatura que sufrió Scagnetti en su paso por Turquía (días 12 y 13 de junio) hacia Asia Central (a partir del día 20 de junio). A partir de aquí hubo días que registramos temperaturas por encima de 40 grados a la sombra. Es decir, el sol no incidía directamente sobre el sensor.

Globalrider - Mapa de calor de la temperatura (primeros 32 días)

El mapa de calor también revela los momentos donde nuestra Pasarela IoT sufrió los efectos antes comentados: 13h del día 20, 11h del día 25 y 9h del día 26. Por último, los huecos en blanco, corresponden a momentos en los que la pasarela ha permanecido apagada sin registrar datos.

 

Humedad relativa y presión atmosférica, además de temperatura
El análisis anterior podemos enriquecerlo añadiendo los datos de humedad y presión atmosférica. Si además fuéramos capaces de medir la velocidad del viento y registrar las precipitaciones estaríamos a un paso de convertir a Hugo en “el señor del tiempo”. En efecto, estos cinco elementos definen el clima y su análisis es la esencia de la predicción del tiempo. Aunque nos gustaría, nosotros no somos capaces de llegar tan lejos y solo nos limitaremos a realizar algún razonamiento sobre climatología a partir de los datos que vamos recogiendo y procesando.

En la siguiente tabla hemos reunido los registros de temperatura, humedad relativa del aire y presión atmosférica. Para hacernos una idea del perfil del clima por cada día de travesía, presentamos el valor mínimo, máximo y calculamos la media.

Globalrider - Tabla de temperaturas, humedad relativa y presión atmosférica

Con permiso de los lectores más adelantados, antes de pasar a la interpretación de datos, haremos un pequeño repaso del concepto humedad relativa y presión atmosférica.

La humedad relativa del aire, como su nombre indica, es una variable con la que medimos la humedad del aire, ahora bien, esta medida es relativa a la temperatura. Esto significa que no podemos medir correctamente un dato de humedad relativa sin conocer la temperatura a la que se ha tomado la muestra. Para comprender esta relación debemos recurrir a la Física. Esta nos dice que una masa de aire a una temperatura alta es capaz de contener más agua en estado gaseoso que la misma masa de aire a una temperatura inferior. Por lo tanto la capacidad de “almacenar” vapor de agua (o humedad) en un volumen de aire viene determinado por la temperatura. Cuando esta masa de aire no puede almacenar más vapor decimos que se satura porque alcanza el 100% de su capacidad, produciéndose a continuación el fenómeno de condensación que se manifiesta en forma de lluvia, nieve, granizo, niebla, rocío o escarcha.

Globalrider - Explicacion de anticiclón y borrasca

La presión atmosférica indica la fuerza que ejerce la atmosfera sobre la superficie terrestre. Se mide en milibares. Esta presión no es uniforme a lo largo y ancho de nuestro planeta y depende de factores como la altitud, latitud y la temperatura. Esto quiere decir que, en condiciones atmosféricas iguales, si estamos en lo alto de una montaña mediremos menos presión atmosférica que si nos encontramos a nivel del mar. De manera inversa la relación entre temperatura y presión demuestra que, a menor temperatura, la presión atmosférica se incrementa. Esto provoca que el aire tenga más densidad y tiende a descender hacia la superficie provocando una zona de alta presión o anticiclón. Por el contrario, el aire caliente, al tener menor densidad, se eleva lo que provoca que baje la presión generando una zona de borrasca. El viento es un fenómeno atmosférico que se origina por la diferencias de presión entre anticiclón y borrasca. Éste circula desde la zona anticiclónica hacia la borrasca.

 

Análisis descriptivo de tormentas
Con los datos recogidos por Hugo vamos a intentar identificar el desarrollo de una tormenta. Si revisamos la tabla anterior notaremos que la humedad relativa máxima de los días 27, 28 y 29 de mayo, así como la de los días 2, 5, 7, 12 y 27 de junio superan el 70%. Con mucha cautela vamos a tomar estos datos como un indicio de que esos días pudo suceder algo especial. Quiero insistir en la prudencia ya que una subida de la humedad relativa no tiene por qué estar exclusivamente relacionado con la lluvia. Como no somos meteorólogos necesitamos tener un elemento que constate si nuestras sospechas son correctas o no.  Para lograr esta certificación hemos recurrido a la bitácora que mantiene Scagnetti en Facebook y en Twitter donde recoge los instantes más relevantes de cada día.

Globalrider - Bitácora Facebook y Twitter de Hugo (tormentas)

En efecto, parece que vamos por buen camino. Como podéis comprobar en el resumen anterior, a excepción del día 12, los días citados fueron lluviosos. Para profundizar en el análisis echemos un vistazo a alguno de esos días de lluvia. En este caso lo que queremos representar es la evolución de la temperatura y la humedad y, si existe, algún cambio apreciable en la presión atmosférica.

En día 5 de junio Hugo nos contaba que se detenía porque empezaba a llover. En el siguiente gráfico podemos ver que sobre las 16:30h detiene la moto (línea verde). La moverá un poco hacia las 17:10 y pasadas las 18h. Durante ese este tiempo de espera podemos apreciar como la temperatura (línea azul) experimenta un descenso pronunciado desde los 30ºC hasta los 20ºC en aproximadamente 30 minutos. Este descenso de temperatura coincide con un brusco incremento de la humedad relativa (línea naranja) que arranca en el 39% hasta alcanzar el 75%. Si afinamos un poco en el análisis nos damos cuenta que durante estos 30 minutos la presión atmosférica (línea gris) disminuye ligeramente 4mbr, desde los 984 a 980. Pasado este tiempo vuelve a 984mbr. En nuestra opinión se produce una tormenta que provoca el descenso de la temperatura unos grados. Parte del agua recién precipitada se convierte el vapor incrementando así la humedad relativa registrada.

Globalrider - Registro meteo día 5 de junio 2016

Veamos ahora el registro del día 7.

Globalrider - Registro meto día 7 de junio 2016

Como evidencia el diagrama anterior, a partir de las 16:30h y en la media hora siguiente, se manifiestan fluctuaciones en la presión atmosférica que oscilan desde 1015 milibares hasta 980 (17h). El final de este ciclo de inestabilidad en la presión coincide con un fuerte incremento de la humedad relativa, subiendo desde 49% (17:08h) hasta 78%(17:24h). En paralelo a este fuerte ascenso de la humedad identificamos un descenso de la temperatura desde 25ºC a 21ºC.

Por último tomemos el día 27 de junio. Una vez más apreciamos la pauta descrita en días anteriores: Al final de un ciclo de inestabilidad atmosférica (de 13:30 a 14:40) destaca un fuerte incremento de la humedad relativa hasta alcanzar 97%. Simultáneamente a este ascenso de la humedad se produce un descenso de la temperatura desde 23 a 19ºC.

Globalrider - Resitro meteo día 27 junio 2016

Como hemos podido comprobar, tras conocer los máximos de humedad relativa, hemos intuido en qué días se produjeron tormentas. A continuación, con la información facilitada por Hugo, hemos sido capaces de comprobar la veracidad de nuestras sospechas. El siguiente paso era conocer el desarrollo de la tormenta y como se expresaba ésta a través de los datos de temperatura, humedad relativa y presión atmosférica.

El desarrollo anterior encaja a la perfección en el estudio de los días 27, 28 y 29 de mayo y 2, 5, 7, 27 de junio. En cambio, el día 12 junio, donde la humedad máxima alcanzó el 70%, Hugo no dejó constancia de precipitaciones. Puede ser que este umbral no implique necesariamente lluvia, incluso es posible que Scagnetti no indicara que llovía.

Globalrider - Registro meteo 12 de junio 2016

Como no nos podemos quedar con esta duda, echemos un vistazo al día 12 (diagrama anterior). Salta a la vista que el momento de máxima humedad es a primera hora de la mañana, a las 9:30h, poco después de ponerse en marcha la Pasarela IoT. Esa humedad matinal y su relación con la temperatura corroboran que Hugo se encuentra en la orilla del Mar Negro y que lo que estamos “viendo” puede ser alguna neblina que levanta con la mañana.

Globalrider - Ruta del día 12 de junio 2012

 

Análisis predictivo de presión atmosférica y altura
Hasta ahora hemos visto algunos ejemplos de estadística descriptiva. Esta rama de la estadística, a partir del análisis de datos conocidos, nos ayuda a entender cómo funciona un fenómeno. Por su parte, la estadística predictiva, nos permite elaborar predicciones sobre datos desconocidos a partir de datos que conocemos. Como paso previo a la predicción necesitamos hacer un análisis de regresión sobre un amplio histórico de datos conocidos para descubrir si existe una relación matemática entre datos de diferente naturaleza (por ejemplo altura y presión atmosférica). A través de este análisis conoceremos cuál es el tipo de función de regresión o relación matemática entre estas dos variables: una independiente (altura) y otra dependiente (presión atmosférica). Por lo tanto, si existe esta relación matemática, estaríamos en condiciones de predecir el valor de la presión atmosférica cuando enfrentemos la variable altura a una función de regresión. Veamos un pequeño ejemplo.

Globalrider - Conrrelación entre valores de altura y presión atmosférica

En el diagrama superior, en el eje horizontal x, queda representada la altura. Esta será la variable independiente. En el eje vertical y indicamos la presión atmosférica, variable dependiente. Podemos distinguir, en forma de cuadrado azul, los datos conocidos de altura-presión recogidos por Hugo durante los primeros 10.000 kilómetros. Realmente la Pasarela IoT ha registrado muchos más datos de los que hay representados pero, por motivos prácticos de visualización, solo hemos presentado uno por hora. En total hay 780 cuadrados azules. Con ellos hemos confeccionado un gráfico de dispersión.  El paso siguiente es enfrentar este gráfico de dispersión a diferentes funciones matemáticas (lineal, polinómica, logarítmica, exponencial, parabólica, etc) para ver cuál de ellas ofrece el modelo más preciso, es decir, con menor error. En nuestro caso vemos que una sencilla función lineal (línea naranja) expresa razonablemente bien la relación existente entre altura y presión: Menor altura, más presión. Nuestra herramienta de análisis nos ofrece la siguiente función para, en el futuro, predecir la presión atmosférica con solo conocer la altura. También nos advierte de un margen de error del 0,89% que, traducido en milibares, son 8,75656.

y = 1015,4861 – (0,1131 * x)

Somos conscientes de la obviedad del ejercicio anterior. Solo pretendíamos introducir de manera divulgativa el concepto de análisis predictivo a partir de los datos que estamos recogiendo en Globalrider. También nos ha permitido constatar que la presión atmosférica no solo depende de la variable altura, de ahí el error de la función.

Como podéis sospechar la predicción meteorológica recurre a este tipo de análisis para adelantarnos el tiempo que hará en los próximos días. Evidentemente, los meteorólogos manejan millones de datos recogidos de cientos de fuentes y cuentan con superordenadores para realizar los cálculos rápidamente. A pesar de todo, la naturaleza caótica de la atmosfera, reduce la fiabilidad de los modelos matemáticos más allá de una semana.

Puedes hacer el seguimiento de esta aventura en: telefonica.yamaha.globalrider.org

[Descargar texto]

Monitorización de partículas contaminantes

junio 16, 2016 on 11:40 am | In análisis de datos, globalrider, m2m, iot | 1 Comment

Adolfo García Yagüe | No todos los días alguien te ofrece un sitio en su moto para dar la vuelta al mundo. Globalrider - Francis Rastrilla, de TELNET, instalando la pasarela IoTCuando te enfrentas a una aventura como Globalrider, una de las cuestiones más difíciles es encontrar un punto de equilibrio entre el entusiasmo técnico por hacer algo insuperable y lo que es materialmente realizable, con garantía de éxito. En el caso de las funcionalidades y atribuciones que debía tener la Pasarela IoT este dilema nos ha acompañado hasta una semana antes de que Hugo partiera desde Distrito Telefónica. Como comentaremos en próximos post, esta es la razón por la que, a última hora, descartamos mantener la conexión CAN Bus con la centralita de la moto o, como es el caso que nos ocupa, incluir sensores para detectar el grado de contaminación.

Globalrider - Detalle de la pasarela IoT y ubicación de los sensoresEn las especificaciones iniciales no se contempló monitorizar los niveles de Dióxido de Carbono (CO2) y Compuestos Orgánicos Volátiles (VOC). La idea surgió sobre la marcha, en los últimos días de desarrollo. El planteamiento fue el siguiente: La motocicleta, como vehículo a gasolina, es contaminante. Además circulará en carreteras de medio mundo y atravesará ciudades y zonas industriales ¿Por qué no medir la huella de estas sustancias? En este punto es importante matizar que tomaremos registros de CO2 y VOC en el entorno de la motocicleta, circulando próxima a otros vehículos. Es decir, lo que vamos a ver es la estela de contaminación que existe a lo largo de carreteras y autopistas. Esto quiere decir que si Hugo circula en un atasco, tiene delante un camión “quemando” aceite o, incluso, la moto está parada pero con el motor encendido apreciaremos niveles (muy) altos de las citadas sustancias.

Globalrider - Flujo de aire a través de la pasarela IoT y sensores

 

Sobre CO2 y VOC
El CO2 es un gas esencial para la vida en la tierra y antes de la primera Revolución Industrial el ciclo del dióxido de carbono se encontraba en equilibrio. A grosso modo, los animales inspiramos oxígeno y exhalamos CO2, mientras que las plantas, a través de la fotosíntesis, absorben CO2 y generan oxígeno. Como decimos, el equilibrio era perfecto hasta que entró en escena la industrialización que, como todos sabéis, era dependiente de la combustión del carbón y el consumo de madera. Por un lado generábamos toneladas de CO2 “no presupuestadas” por Gaia y, si esto no fuera suficiente, el desarrollo industrial y urbano demandaba miles de toneladas de madera dando origen a una deforestación sin precedentes. Así las cosas, este exceso de CO2 en nuestra atmosfera origina el famoso efecto invernadero que tiene, como consecuencia directa, el cambio climático.

Al igual que vinculamos la Revolución Industrial con el inicio del desequilibrio en el CO2, el momento en el que empiezan a despuntar los niveles de VOC se sitúa en la incorporación de procesos químicos a nivel industrial. Más concretamente en aquellos procesos industriales donde se utilizan disolventes orgánicos como el benceno, etanol, acetona, anilinas o el tetracloruro de carbono, entre otros. Por otro lado también se producen VOC durante la combustión de gasolina, gasoil, gas natural, carbón y madera. El tercer grupo generador de VOC tiene un carácter “más natural” pero no menos perjudicial, ahí aparece el gas metano generado en los procesos naturales de descomposición de materia orgánica, en particular en las “emisiones” de las vacas. El hecho es que hay más de mil Compuestos Orgánicos Volátiles y algunos de ellos son realmente malos para la salud, además de que son precursores del ozono troposférico (un potente oxidante) y destructores de la capa de ozono (si, esa que nos protege de la radiación ultravioleta). El sensor VOC que hemos incorporado a esta aventura detecta las siguientes sustancias:

  • Hidrocarburos aromáticos
  • Hidrocarburos alifáticos
  • Gases licuados del petróleo
  • Monóxido de carbono
  • Aminas
  • Alcoholes
  • Aldehídos
  • Cetonas
  • Metano
  • Ácidos orgánicos

 

Manos (y datos) a la obra
Al igual que en ejercicios anteriores vamos a visualizar cual ha sido de presencia de CO2 y VOC el pasado 27 de mayo. Para los recién llegados recordar que ese día Hugo partió desde Madrid y llegó a la frontera francesa. En este primer análisis vamos a identificar ciertos patrones de comportamiento relacionados con la velocidad de la moto, el arranque de esta y la relación de las partículas en estudio en la proximidad de ciudades.

Globalrider - Impacto CO2 y VOC día 27 de mayo 2016

En el gráfico anterior se aprecia con claridad cierta correspondencia entre ciudades importantes y los niveles de CO2. Tras correlar estas “crecidas” de CO2 con la ruta que siguió Hugo hemos identificado sin dificultad las localidades de Tres Cantos, Colmenar Viejo, Aranda de Duero, Burgos, Miranda del Ebro y Vitoria. Hay que decir que Scagnetti no ha visitado ninguna de estas ciudades, únicamente ha circulado por la periferia. Normalmente, en la periferia de los núcleos urbanos, hay mayor densidad de tráfico pesado y están situadas las zonas industriales.

Otro evento que ha quedado registrado en el diagrama de arriba es la parada que hizo Hugo en el puerto de Canencia. Ahí vemos un “pico” de VOC y CO2 que está relacionado con el arranque de la moto. El conjunto sensor de VOC y CO2 se ha situado de tal forma que no esté expuesto al tubo de escape de la Super Tenere, no obstante, cuando Hugo arranca, antes de soltar el embrague una nube de partículas de CO2 y VOC son detectadas por el sensor. Tras Canencia, en las siguientes dos horas y media, se vuelven a apreciar cinco “picos” con un aspecto similar. Algo parecido sucede cuando la moto circula a baja velocidad. Esto sucede cuando Hugo se encaminó hacia la Ayllón. En este periplo fotográfico Hugo rodó a baja velocidad e hizo varias paradas. En este espacio de tiempo, cuando la moto va despacio, el sensor no se ventila lo suficiente y detecta las propias emisiones.

A la altura de Aranda de Duero vemos que los totales de partículas experimentan un incremento. Esta progresión se repite en las proximidades de Burgos, Miranda del Ebro y Vitoria. En este tramo del viaje nos ha llamado la atención otro pico de CO2 antes de las 18h. Este evento coincide con una parada que hizo Scagnetti en la estación de servicio de Oquillas.  En el siguiente diagrama se aprecia que poco antes de las 17:20, Hugo desaceleró hasta prácticamente detenerse (línea marrón). Rodó a muy baja velocidad por la estación de servicio y estiró las piernas hasta que a las 17:57 (flecha roja señalizando nivel CO2 en línea azul) metió gas y soltó embrague.

Globalrider - Perfil CO2 y VOC en estacíón de servicio de Oquillas

En los diagramas previos hemos comprobado el ciclo de emisiones del primer día superpuesto a la ruta seguida. También hemos identificado como afecta la velocidad de la motocicleta a la detección de partículas. Ahora bien, hay un dato más importante que subyace en este análisis y tiene que ver con los niveles mínimos de CO2 y VOC. Estos niveles mínimos o línea base siempre están ahí, independientemente de que la moto esté apagada, parada con el motor en marcha o circulado a toda velocidad, o que incluso hayamos registrado medidas erróneas o espurios. En la siguiente representación gráfica hemos querido destacar esos niveles mínimos de CO2 y VOC.

Globalrider - Desarrollo de línea base CO2 día 27 de mayo 2016

Globalriderr - Desarrollo de línea base VOC día 27 de mayo 2016

Desde el año 2013, los niveles de CO2 han rebasado la barrera de las 400 partes por millón. Teniendo en cuenta que estas emisiones están creciendo anualmente, lamentablemente, los datos recogidos no van desencaminados. Respecto a las partículas VOC, podréis comprobar que a lo largo del itinerario del día 27 se aprecia cierta relación con los niveles CO2, especialmente en las arrancadas de la moto. No obstante, en el diagrama anterior también se aprecia una línea base de los niveles VOC que no desciende de las 450 ppm. Recordar que esta es la suma de las distintas partículas que es capaz de medir el sensor. Siendo este el análisis más detallado al que podemos llegar.

Puedes hacer el seguimiento de esta aventura en: telefonica.yamaha.globalrider.org

[Descargar texto]

Página siguiente »


(c) 1999-2024 Ccäpitalia.net - Se autoriza el uso según terminos Creative Commons BY-NC-SA
Powered by WordPress