SkyAlert es la única plataforma en el mundo que te indica qué hacer antes, durante y después de un sismo. se especializa en informar en tiempo real sobre temas sísmicos y volcánicos. Detecta, procesa y envía notificaciones masivas de alertas de sismos a través de sus propios dispositivos.

Pain point

Como un sistema de alerta sísmica, lo más importante es poder entregar a los usuarios las alertas de la forma más rápida posible, sin embargo, un valor agregado es el hecho de poder alertar con cierta precisión sobre la intensidad con la que se presentara el sismo y descartar zonas donde no se va a sentir.

Skyalert actualmente entrega las alertas de forma satelital, y se ve limitado por la cobertura que ofrece, siendo esta el centro del país (Mexico), la transmisión se hace en forma de broadcast y a veces llega a dispositivos que no deberían recibir la alerta, y tampoco se tiene confirmación de recibido, no existe una comunicación bidireccional.

Y como respaldo a las posibles reclamaciones de un usuario sobre una alerta que no llego, o un servicio que no se está ofreciendo era necesario tener un “keep alive” para saber en qué momento su dispositivo esta fuera de nuestro sistema por causas como una desconexión de la red o de la corriente eléctrica.

Solution

Se pensó en la implementación de un dispositivo inteligente con conexión a internet, con esto se es capaz de expandir la cobertura, además con la utilización de componentes en la nube para IoT se puede lograr una comunicación bidireccional, procesamiento de datos en tiempo real, análisis de la información y la implementación de modelos predictivos con machine learning, que convertirían a SkyAlert en el sistema de alerta sísmica más completo e inteligente del mundo.

Architecture

Architecture

Device data model

SkyAlert implementa una solución para dispositivos IoT de consumo, es por eso que los parámetros que identifican a un dispositivo cambian a lo que mayormente se usa en la industria, tenemos que agregar ciertos campos que nos hacen identificar a que usuario está asociado. Los metadatos que identifican a cada uno de los dispositivos son los siguientes:

  1. Propiedades del dipositivo
  2. Comandos
  3. Object type
  4. Iot hub properties

El primer campo involucra el ID único de dispositivo que lo identifica, datos como fecha de creación, estado del dispositivo, versión de firmware, tipo de conexión (LAN, WLAN), MAC address, dirección ip, modelo de hardware, usuario que se ha loggeado, estado de la suscipcion, lalitud, longitud, región a la que pertenece dentro de las zonas geográficas a alertar, el estado de conexión y un campo que nos ayuda a saber cuándo fue la última vez que se actualizaron los metadatos.

Los comandos son una forma de expresar mensajes que pueden incluir ciertos parámetros, para ser enviados a los dispositivos, cada dispositivo puede tener comandos diferentes, de acuerdo a las necesidades de los usuarios, sin embargo, todos comparten el de alertamiento, test y despliegue de mensajes. El Object type nos ayuda a procesar los datos en los stream processors, con esto podemos saber si se trata de un objeto de tipo metadatos, telemetría o alertas. Y de manera más específica nos ayuda a saber si se trata de un dispositivo de producción, de desarrollo o testing.

Las propiedades del IoT hub involucran datos que se crean con ayuda del registry manager, y se almacenan en el device data model con propósitos administrativos dentro de nuestro portal de dispositivos.

De tal manera que el modelo de datos luce de a siguiente forma:

{
  "DeviceProperties": {
    "DeviceID": "SAB0000019",
    "HubEnabledState": true,
    "CreatedTime": "2016-08-24T17:23:10.9749565Z",
    "DeviceState": "normal",
    "UpdatedTime": "2016-10-14T18:43:11.6277444Z",
    "DeviceModel": "530U3C/530U4C",
    "OsVersion": "10.0.14393.222",
    "FirmwareVersion": "1.2.17.0",
    "ConnectionType": "LAN",
    "WIFI_MAC": "wifi_mac",
    "EthernetMAC": "ethernet_MAC",
    "SubscriptionStatus": "status",
    "UserId": "emilio_ramos_v@hotmail.com",
    "Latitude": 19.183887597173452,
    "Longitude": -96.14198380149901,
    "Region": "Puebla Capital",
    "ConnState": "Connected"
  },
  "Commands": [],
  "id": "34c97b7f-c8bc-4cfd-abd0-96024d523b96",
  "ObjectType": "dev-DeviceInfo",
  "IoTHub": {
    "MessageId": null,
    "CorrelationId": null,
    "ConnectionDeviceId": "SAB0000019",
    "ConnectionDeviceGenerationId": "636076562383161122",
    "EnqueuedTime": "0001-01-01T00:00:00",
    "StreamId": null
  }
}

Data stream

Los dispositivos de skyalert envían diferentes tipos de paquetes, de acuerdo a los datos que necesitan ser reportados, están segmentados en cuatro:

  1. Metadata
  2. Streams
  3. Alerts
  4. Records


Datastreams


Cada uno de ellos son mensajes que se envían hacia la nube, sin embargo, tienen funciones separadas, los metadatos se envían cada vez que hay un cambio en las propiedades del dispositivo, es decir, cada que cambia de posición, cambia de red, se loggea un usuario, reinicia, apaga, etc.

El segundo parámetro es un paquete que se está enviando constantemente cada 5 minutos reportando la temperatura, presión y humedad que lee el dispositivo.

Las alertas son paquetes que se envían conforme son activadas, solo suceden cuando los sensores de gas o incendio detectan alguna fuga de gas o fuego, en este caso el paquete solo envía la notificación de la detección de un evento. Cada sensor está preconfigurado con ciertos niveles de umbral y una vez superados se lanza la alarma y se envía el paquete.

Los registros es información histórica recabada sobre un evento sísmico en particular, el acelerómetro solo se activa en el momento que se alerta al dispositivo sobre la posible llegada de un terremoto, en este momento el dispositivo comienza a guardar toda la información que se registre sobre el evento y al concluir se envía un paquete con los datos recabados sobre el mismo.

Los primeros tres pasan a los stream processors para tomar acciones en tiempo real sobre ellos y ayudarnos a conectarlos con otros servicios dentro de la arquitectura, donde serán procesados. Sin embargo, el ultimo al ser datos históricos solo nos interesa almacenarlo para darles un futuro uso en el análisis de datos.

Device connectivity

Device connectivity

Los dispositivos de SkyAlert están diseñados para conectarse por medio de una red WLAN, cada dispositivo tiene la capacidad de trabajar con el protocolo IP, y nos da muchas ventajas en cuanto a soluciones de conectividad porque no necesitamos hacer uso de un Gateway de campo y hacemos una conexión directa entre los dispositivos y el Gateway en la nube.

Dentro de los servicios de Azure encontramos muy adecuado el IoT Hub para nuestras necesidades, nos permite tener comunicación bidireccional de forma segura, además de la robustez para conectar millones de dispositivos.

El proceso de conexión lo hacemos con el uso de los Azure IoT device SDKs, particularmente para la plataforma de Windows. Establecemos la conexión con el protocolo AMQP, lo cual nos da muchas ventajas, como la comunicación segura, trabajar con anchos de banda pobres, y robusto, que nos permite enviar millones de mensajes.

Device provisioning, identity, registry, and state

El aprovisionamiento se hace desde nuestro portal de administración a través de la API y el SDK de Azure IoT Hub devices, los procesos involucrados en el aprovisionamiento, son el registro, eliminación, activación y desactivación de los dispositivos. Cuando se lleva a cabo el proceso de aprovisionamiento, el registro y la identidad de los dispositivos es administrado por Azure IoT Hub, permitiéndonos generar IDs personalizados y claves asignadas de forma automática. Nosotros solo nos preocupamos por guardar los metadatos de cada dispositivo en una colección de DocumentdDB donde guardamos la identidad de los dispositivos, con los metadatos que estan relacionados a cada uno de ellos. La forma en que lo almacenamos es en formato JSON, con el modelo de datos de dispositivo que se mostró anteriormente.

Para SkyAlert es muy importante guardar un log con todos los cambios que se puedan generar en el dispositivo, principalmente su estado de conexión respecto al IoT Hub. Aprovechando el device state store del IoT Hub, revisamos el estado de conexión de cada dispositivo habilitado, si existe algún cambio respecto al estado reportado con anterioridad se almacena.

Un WebJob es el encargado de realizar este proceso, está revisando constantemente el estado de conexión actual y lo compara a uno almacenado con anterioridad, si existe algún cambio se escribe el estado actual en su identidad en el documento de DocumentDB y se escribe una línea nueva en su respectivo log almacenado en Azure Blob Storage.

Data flow and stream processing

Azure Stream analytics es una herramienta que nos ayuda con el flujo de los datos, prácticamente toda la información que recolectamos pasa por un trabajo de stream analytics, la telemetría llega desde los dispositivos al IoT Hub y pasa a través del stream analytics para almacenarse en Azure Blob Storage.

Los metadatos pasan por el mismo proceso, sin embargo, su destino es un eventhub, que los lleva hacia un webjob el cual se encargara de actualizar el documento que le corresponde al dispositivo asociado con dichos metadatos.

Mientras que los registros pasan directamente desde cada dispositivo hacia un Blob Storage.

Todo esto es por parte de los dispositivos para usuarios, por otro lado, también recolectamos información de los sensores que se encarga de la detección de sismos, estos están sensando constantemente lo que pasa en su locación, toma lecturas de la actividad sísmica cada cierto periodo de tiempo, estos datos llegan hacia la red de detección sísmica SkyAlert, donde actualmente son procesados, pero a la vez, existe una bifurcación que hace que las lecturas sean enviadas a través de un Event Hub.

Los datos de los sensores que viajan a través del Event Hub, llegan a un trabajo de Stream Analytics que lo conecta con dos salidas bajo ciertas reglas de negocio. La primera de ellas es el almacenamiento, donde cada registro que llega es llevado hacia un archivo en Azure Blob Storage. La segunda es un trabajo de machine learning, aquí solo llegan datos que han rebasado los umbrales establecidos en las reglas del stream analytics.

Existe dentro de nuestra arquitectura otro canal de comunicación a través del Event Hub, REDSSA procesa los datos de los sensores y decide que dispositivos deben recibir un mensaje de alerta, estos mensajes preprocesados por REDSSA llegan a través de un Event Hub hacia un WebJob, donde se hace un query a los dispositivos que deben ser alertados y se les envía el mensaje.

Para hacer uso los dispositivos, cada usurio debe tener una cuenta dentro de la plataforma de SkyAlert, los datos proporcionados como el nombre de usuario, contraseña, otros datos personales, el dispositivo con el que esta asociado y su informacion de pago estan almacenados en una base de datos SQL dentro de los servicios de Microsoft Azure.

Solution UX

Existen dos partes dentro de la experiencia de usuario, la primera es una UWP app corriendo en Windows 10 IoT core, donde el usuario puede loggearse para recibir los servicios de la plataforma de skyalert, en la pantalla se pueden ver una predicción del clima por días y horas, lecturas de los sensores de dispositivo, logs de alertas sísmicas y volcanes.

Pantalla de inicio

Home screen


Pantalla de sismos

Sismos


Pantalla de clima

Storm


Pantalla de volcanes

Volcano


Luego está el portal de administración, que está basado en el App service de Azure. Un sitio web desarrollado en ASP.NET MVC 5, donde se hace el registro de usuarios, se administra el aprovisionamiento, mensajes, logs, y actividad de los dispositivos. Está constituido por cuatro elementos fundamentales:

  1. Device Monitoring
  2. Device Administration
  3. Telemetry
  4. Users

El monitoreo de los dispositivos es a través de un mapa, con puntos de colores que indica cuales dispositivos están conectados al IoT Hub y cuáles no; monitorear esto nos ayuda a contactar a nuestros clientes, comunicarles que puede existir un problema con su dispositivo o con su conexión de red.

Como el portal tiene dos niveles de acceso, administrador y usuarios, el dashboard despliega a los administradores todos los dispositivos por zona mientras que a los usuarios les despliega solos los dispositivos asociados a su cuenta.

Dashboard

La administración de los dispositivos es lo que permite crear, eliminar, habilitar o deshabilitar dispositivos, crear de forma masiva y de una forma personalizada para nuestra línea de producción, generar archivos con las llaves y encriptadas para incrustarse de forma directa en la aplicación de los dispositivos. La telemetría nos permite visualizar los datos de temperatura, presión y humedad por dispositivo, por región o en general de todos los datos que están llegando de los dispositivos.

Y la sección de usuarios nos deja administrar la parte de pagos así como la forma en que están asociados los dispositivos a los usuarios registrados.

Data analytics

Por otro lado, el análisis de datos lo realizamos a través de un dataset que diseñamos; este dataset consiste en cinco campos: lugar del sismo, intensidad del sismo en shindo, intensidad de la onda p en gales, intensidad a alertar, lugares a alertar.

Con la combinación de los clusters donde se ubican los sensores, el rango de intensidades que nos puede arrojar los sensores en shindo y gales para la onda P logramos un dataset fijo de aproximadamente 4000 filas.

El cual es evaluado por un modelo predictivo en Azure Machine Learning, soportado por un boosted decition tree. Se convierte en una solución temporal mientras crece el dataset de valores históricos, estos valores históricos que se planean evaluar en el futuro son sismos presentados con su respectiva intensidad y lugares que se vieron afectados.

Para el modelo predictivo pensado implementar tenemos dos datasets que lo componen, las lecturas de los sensores de SkyAlert almacenados en Blobs y los registros del acelerómetro de los dispositivos también almacenado en el mismo servicio, en conjunto hacen una relación entrada salida para el dataset a evaluar en el próximo modelo predictivo.

Device used and code artifacts

Toda la plataforma del dispositivo corre en una Raspberry Pi 2 con Windows 10 IoT core versión 14393, corre una aplicación universal de tipo headed. Utilizamos la conexión I2C para conectarnos a los siguientes sensores:

  1. Temperatura + presión + humedad
  2. Acelerometro
  3. Microcontrolador

Y comunicación serial para un módulo Zigbee que a su vez de forma inalámbrica se comunica con sensores de gas y de humo.

Se utiliza una pantalla táctil TFT de 7” capacitiva, un par de bocinas para la reproducción de las alertas. Todo se ensambla en una placa de circuito impreso donde se incluye una etapa de regulación de voltaje para alimentar el amplificador de audio, la raspberry y la pantalla.

Device

El dispositivo también es capaz de triangular su ubicación a través de una API para geolocalización utilizando las redes WIFI que hay a su alrededor, a su vez también consume una API del clima para dar resportes sobre la temperatura y humedad de su ciudad, forecast por días y hora, SkyAlert tiene servicios en la nube donde se almacenan imágenes del volcán Popocatépetl e Iztaccíhuatl y el volcán de colima, los recuperamoa a traves de una URL y se despliegan en la aplicación. Tambien se almacena el histórico de los últimos sismos y de la misma manera los recuperamos para ser desplegados.

Opportunities going forward

Con muchos dispositivos distribuidos geográficamente recolectando información sobre el clima, la intensidad de los sismos, la información se convierte en algo extremadamente valioso ya que puede ser la base de datos más extensa sobre datos de clima y sismos, permitiéndonos crear modelos predictivos para otorgar forecast más precisos y para hacer alertamientos de sismos de forma personalizada hacia cada dispositivo.

También puede ofrecer soluciones más completas de protección civil para edificios, naves industriales, escuelas, etc con sensores de incendio y gas distribuidos a lo largo de sus instalaciones, predicción de tormentas y alertas sísmicas.