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

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, 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]

Humblodt, Scagnetti y la Meseta Ibérica

junio 15, 2016 on 10:48 am | In análisis de datos, globalrider, m2m, iot | No Comments

Adolfo García Yagüe |  Actualmente pocos sabrían decir quién fue Alexander von Humblodt (1769-1859). Menos aún que durante su estancia en España en 1799 descubrió la meseta de la Península Ibérica. Alexander von Humblodt (1769-1859)En aquel año Humblodt iba camino de Barcelona para embarcarse rumbo a la costa argelina. Esta era su intención inicial al adentrarse en tierras españolas pero, en su inquieta cabeza, también le rondaba la idea de cambiar de destino, dirigir sus pasos al continente americano y allí hacer un gran estudio científico sobre el clima, la geografía, fauna y flora. Para esta vasta misión necesitaba la obtención de un salvoconducto de la Corona Española, lo cual a su vez exigía un nivel de contactos nada fáciles de conseguir. Pues bien, nuestro admirado Humblodt se valió de su prestigio como inspector de minas, contactos con el mundo de la ciencia y una hábil gestión de las relaciones personales para abrirse camino hasta el mismísimo Rey Carlos IV.

Humblodt, además de viajero infatigable, fue un individuo con un dominio extraordinario de numerosos campos del saber entre los que se encuentran la botánica, zoología, geología, geografía y astronomía. Esta actitud científica la combinó con un profundo espíritu humanista y dotes diplomáticas. Quizás el mejor resumen de la grandeza de Humblodt queda reflejado en la carta que escribió con 65 años a su amigo Karl August Varnhagen. En ella afirmaba “Tengo la disparatada idea de plasmar en una sola obra todo el universo material, todo lo que hoy en día sabemos de los fenómenos de los espacios celestes y de la vida terrestre, desde las nebulosas estelares hasta la geografía de los musgos en las rocas de granito, con un estilo vivo que causará deleite y cautivará la sensibilidad […] Ahora mi título es Cosmos”.

La citada estancia en España apenas duró 6 meses, de enero a junio del 1799. Tras descartar el viaje a África su prioridad fue la obtención de los salvoconductos. En esos meses Humblodt no descuidó su curiosidad científica y fue recopilando datos barométricos de toda la Península para establecer el perfil topográfico de esta. Solo se limitó a reunir datos y a tratarlos, obviamente no tuvo tiempo de realizar trabajo de campo a lo largo y ancho de la Península para el registro de medidas. No obstante, cuando aquellos datos fueron transformándose en imágenes, Humblodt no tardó en llegar a la conclusión de que en España existía un fenómeno topográfico singular que describió con estas palabras “En el extremo más occidental de Europa, bañado por el mar por tres lados, se eleva el altiplano de España, una verdadera meseta, de 2.200 pies parisienses de altitud casi ininterrumpida y que abarca 4.200 leguas cuadradas geográfica. Tal fenómeno geognóstico es extremadamente raro en nuestro continente, pues, aunque también en el sur de Alemania las mesetas bávaras y suaba alcanzan 1560 y 900 respectivamente, esas regiones alemanas no forman un todo cerrado y están parcialmente surcadas por anchas depresiones y cuencas fluviales”

Perfil de la península española segun la dirección S.E - N.O. - Alexander von Humblodt

 

Transcurridos más de 200 años desde la estancia de Humblodt en tierras españolas, nuestro “viajero monitorizado”, Hugo Scagnetti, nos ofrece otra instantánea de la meseta ibérica en su recorrido desde Madrid hasta más allá de la frontera de Irún.

Globalrider - Ruta día 27 de Mayo 2016

Gracias a los datos de altitud proporcionados por su GPS es fácil trazar la ruta que ha seguido. Una vez que tenemos los datos, además de una representación sobre un mapa es interesante conocer el perfil topográfico del itinerario de ese día para identificar singularidades o corroborar que todo está funcionando como se espera. Aquí es donde viene lo divertido de trabajar con los datos…

 

Globalrider - Altura sobre el nivel del mar día 27 de mayo 2016

En la representación topográfica anterior se evidencia con toda claridad una parte de la meseta que tanto llamó la Globalrider - Puerto de Canenciaatención de Humblodt. De igual forma salta a la vista el paso de Hugo por el puerto de Canencia (primera flecha del gráfico) que está a una altura sobre el nivel del mar por encima de los 1500m, en la Sierra de Guadarrama. Su travesía a través del Canencia dura 15 minutos aproximadamente. Desde ahí, Scagnetti desciende por la carretera M-629 y la M-604 hasta Lozoyuela donde se incorpora a la autovía del Norte.

La siguiente subida importante es el paso de Somosierra que está por encima de los 1400 metros y queda reflejado a las 13:19h con toda claridad en el segundo pico de la gráfica.

Sin gran esfuerzo deductivo la representación gráfica de los datos de altitud ilustra a la perfección que el descenso de la meseta se produce tras cruzar Burgos. Hasta aquí todo discurre según lo esperado hasta que a las 20:35h topamos con una llamativa singularidad. En ese instante el GPS nos indica una altitud de 137 metros por debajo del nivel del mar. Es decir, una depresión geográfica. Desde luego existen depresiones geográficas (ver enlace en Wikipedia) pero no es algo común, y menos de 137 metros. Algo está fallando.

No hay problema. Como podemos jugar con los datos a nuestro antojo, lo que vamos a investigar es en qué punto del viaje está esa “magnífica” depresión digna de ser registrada en Wikipedia…

Oh, sorpresa. No se trata de una depresión geográfica, es una estación de servicio cubierta a la altura de Hernani donde Hugo se detuvo a repostar y a estirar las piernas. Aquella parada hizo que nuestra unidad GPS perdiera precisión durante unos minutos.

Globalrider - Estación de servicio en Hernani

 

Nos despedimos recordando que Humblodt partió hacia América el 5 de junio de 1799. En este viaje visitó Caracas, La Habana, Bogotá, Guayaquil, Lima, Quito, México, Filadelfia y Washington. En su visita a EE.UU. llegó a ser huésped del presidente Thomas Jefferson; y Simón Bolivar se refería a él como «el descubridor científico del Nuevo Mundo, cuyo estudio ha dado a América algo mejor que todos los conquistadores juntos».

Humblodt trabajó en Cosmos como si se tratara de una carrera contra la muerte. El primer volumen llegó en 1845, cuando tenía 76 años de edad, el segundo a los 78. La tercera entrega la terminó a la edad de 81, y la cuarta cuando tenía 89. En el último año de su vida solo pudo completar la mitad del quinto volumen, que sería finalizado a partir de las notas que dejó escritas. Cosmos pasaría a la historia con el subtítulo “Ensayo de una descripción física del mundo”.

Por su parte, mientras discurre su viaje, Hugo Scagnetti también está reuniendo todas sus experiencias con las que producirá una serie de documental que, sin lugar a dudas, también pasará a la historia.

Os recordamos que este proyecto tiene un fin solidario; obtener fondos para la investigación de la enfermedad de Perthes en niños. Os animamos a hacer una pequeña donación desde la web de Globalrider para que el esfuerzo de todos tenga el resultado esperado.

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

[Descargar texto]

Página siguiente »


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