Un primer contacto con IoT&Edge
- Onesait Platform
Tanto Internet of Things (IoT) como Edge Computing, son conceptos que se comenzaron a popularizar en la primera década de este siglo. Aunque hoy en día Edge Computing se suele presentar como una evolución de IoT, en su origen, recibe influencia de otras ramas de la computación industrial. Es conveniente entender este origen para comprender en profundidad cómo se han terminado por vincular IoT y Edge Computing, constituyendo hoy en día dos de las palancas más importantes para impulsar la transformación digital.
La evolución de Internet: el nacimiento del IoT.
Internet of Things es una fase natural en la evolución de la Web y así fue introducido en la primera mención al concepto de la que se tiene constancia.Fue en 1999 en el contexto de una conferencia durante el Foro Económico Mundial de Davos, allí Bill Joy (cofundador de Sun Microsystems) introdujo los distintos tipos de redes de comunicación que habilitaba la naciente Web, al hablar del tipo número 6, la describió como :
"Web.6. Device2Device. […]is the Internet of sensors deployed in meshes networks with embedded machine intelligence in ordinary, daily life things."
Los 6 tipos de Web descritos por Bill Joy no están hoy en día muy vigentes, aunque sí es común referirse a los 3 tipos de Web.
Web 1.0 .- La Web inicial, donde seres humanos producían contenidos (recursos) para que otros los consumieran. La interacción era muy limitada y el formato de los recursos se orienta al consumo humano.
Web 2.0 .- La Web avanzada entorno a los RIA (Rich Internet Applications), donde la interacción entre las personas se sustituye por la interacción de los usuarios (una representación como recurso), la tipología de los recursos aumenta de forma exponencial, surgen las redes sociales y el uso se populariza. Comienzan a surgir los primeros formatos orientados al proceso de máquinas (M2M) exclusivamente.
Web 3.0.- La Web donde agentes humanos y agentes artificiales interactúan directamente, se crean lenguajes de representación avanzados que permite el crecimiento exponencial de esta interacción.
La segunda mención al concepto y el momento en el que comenzaron a popularizar las tres siglas de IoT, fue una ponencia presentada en el MIT Auto-ID Center por Kevin Ashton ese mismo año, con el título: "That ‘Internet of Things’ Thing. In the real world, things matter more that ideas". En aquella ponencia se trataba del origen de la información almacenada en la Web en aquel momento, constatándose que casi la totalidad de los datos disponibles en los años 90 dentro del sistema habían sido capturados (tecleada) por primera vez por humanos. Esta información trataba principalmente de ideas/conceptos y no sobre hechos en el mundo físico. Si queríamos que la digitalización nos ayudara a enfrentar problemas como la sostenibilidad o la mejora en eficiencia, era necesario que las máquinas pudieran "sentir" el mundo, recabar información sobre él y procesarla sin la limitación de la operación humana. En palabras de Kevin Ashton:
"We need to empower computers with their own means of gathering information, so they can see, hear and smell the world for themselves, in all its random glory […]
technology enable computers to observe, identify and understand the world—without the limitations of human-entered data.".
Se iniciaba la carrera para la conexión de la realidad con la máquinas. Esta carrera se correría en el terreno de las tecnologías Web ya que es un entorno privilegiado de interacción entre seres humanos y máquinas. La arquitectura Web basada en los conceptos de productor, consumidor, recurso y servicio permite esquemas de interacción extremadamente ricos y multitud de protocolos de comunicación adaptados a cada necesidad. La consideración de todos los elementos implicados en la interacción como recursos, libera a su vez la potencia de la modelización y el tratamiento automatizado de la información sobre casi cualquier aspecto de la realidad. Sin embargo, esta carrera debía solventar distintos problemas fundamentales tales como:
Aumento cualitativo y abaratamiento de los sensores/actuadores disponibles. Las máquinas requerían nuevos sensores que pudieran medir gran cantidad de fenómenos físicos para extender y mejorar la forma humana de sentir el mundo físico.
Diversificación y reducción del coste de los sistemas de procesamiento. Los nuevos sensores y la adquisición masificada de información comenzó a requerir nuevas arquitecturas hardware de procesamiento, nuevos empaquetados y form-factors de los chips y equipos.
La mejora de ancho de banda y abaratamiento de las comunicaciones, especialmente las que se establecen máquina a máquina (M2M) para lograr una conectividad casi ubicua.
La mejora tanto del consumo energético de los dispositivos como la duración de las baterías. No en todos los rincones hay posibilidad de suministro energético, tanto el consumo energético del procesamiento como de las comunicaciones debían ser reducidos con dispositivos capaces de "dormirse" en fase de bajo proceso y minimizar el intercambio de información exprimiendo al máximo la significación de cada bit empleado en la comunicación.
Desarrollo de las tecnologías capaces de procesar de forma masiva toda la información producida. Analizarla, extraer insights significativos y mejorar finalmente los procesos tradicionales de los sistemas TI . Lo que se vino en llamar el tsunami de información IoT, no era fácilmente procesable con las ténicas habituales. Un caso paradigmático fueron los motores de bases de datos basados en SQL. Estos motores debían procesar ahora millones de registros raw de información procedente de eventos en dispositivos distribuidos.
Todas estas dificultades se han ido solventando y a día de hoy tenemos:
Un conjunto muy amplio de sensórica y actuadores a bajo precio que se pueden integrar de forma rápida y eficiente mediante un prototipado rápido de componentes. Los puntos Sensores y Actuadores de este marco proporciona una introducción a estos elementos.
El abanico de procesadores que se pueden emplear en la solución de los escenarios de IoT es muy variado y la implementación de aplicaciones sobre ellos es más abierta que nunca. Ya no es necesario emplear lenguajes muy pegados al hierro para programar microcontroladores pequeños o sistemas SoC. Es posible la programación con Micropython, JavaScript,Arduino o Go (lenguajes de alto nivel) en microprocesadores de 16bits o 32bits, con o sin OS de tiempo real. El capítulo del marco dedicado a dispositivos de bajo capacidad proporciona una visión sobre Arduino(Atmel), ESP32 o ARM-Cortex.
Tanto a nivel de protocolos de transporte como a nivel de protocolos de aplicación, el conjunto de comunicaciones disponibles a día de hoy para solventar los distintos escenarios de IoT ha aumentado considerablemente entorno a dos factores, el ancho de banda y las restricciones de consumo que se mencionó anteriormente. La proliferación de protocolos de transporte se ha producido tanto en banda licenciada como en banda libre. En banda licenciada (bajo la dirección de de 3GPP y GSM) a las tradicionales versión 2G, 3G y 4G se unen ahora normas de bajo consumo como LTE-CatM o NB-IoT. En banda libre, las comunicaciones de bajo consumo y largo alcance (LPWAN) más extendidas son Sigfox y LoRA/LoraWAN. El capítulo de marco dedicado a las comunicaciones en IoT&Edge proporciona una visión de detalle de estas tecnologías.
Un conjunto muy amplio de técnicas No-SQL que permiten tanto analizar inmensas colecciones de datos (Data Lakes) como detectar patrones, alarmas y anomalías en tiempo real con esquemas de Proceso de Streaming (SP) o Proceso Complejo de Eventos (CEP).
Plataformas IoT
La primera generación de plataformas IoT coincidieron con el auge de la virtualización de máquinas en entornos cloud. El "mantra" tras estos entornos aseguraba disponer de infraestructuras potentes rápidamente configurables y adaptables a la demanda de carga/uso donde poder desplegar los componentes de Big Data. De forma similar la inercia fue considerar que el lugar natural de despliegue de los nuevos elementos de analítica y proceso de IoT debía ser también el cloud mismo.
Bajo esta perspectiva, toda la información recogida por los dispositivos se concentraba en la nube donde era analiza, procesada y de la que se extraían el conjunto de insights que deberían permitir la mejora de los procesos, la identificación de patrones ocultos en el comportamiento de los clientes o la detección de fallos potenciales en los distintos activos. Tras este proceso la capacidad de cursar comandos y consignas a los dispositivos, permitiría lo que se comenzó a llamar la Empresa Predictiva/Reactiva.Las funcionalidades habituales que encontramos en estos sistemas iniciales de IoT son las siguientes:
Ingesta de información procedente de los dispositivos empleando distintas tecnologías de comunicación y protocolos de aplicación. Esta ingesta de información debe ser rápida, segura y altamente escable.
Envío de comando y operación sobre dispositivos, en el plano de negocio los comandos son las consignas que debemos ejecutar sobre los dispositivos, es necesario asegurar su correcto envío y ejecución, de forma aislada o sobre conjuntos agrupados de dispositivos.
Gestión de la seguridad y las comunicaciones, este grupo de funcionalidades son las responsables del onboarding de dispositivos, la atestación de los mismos, la protección de las credenciales, etc; así como la gestión de la conectividad lógica de los dispositivos de forma que se puede asegurar lo SLAs requeridos por el negocio.
Gestión de dispositivos, además de los comandos de negocio, la plataforma debe ser capaz de gestionar los comandos enviados a los dispositivos para gestionar su propio ciclo de vida, actualizaciones de firmware, parametrización remota, etc.
La arquitecturas IoT iniciales sólo consideraban un paso entre los dispositivos que enviaban la información y la nube, sin hacer una categorización detallada de los componentes que se desplegaban de forma distribuida.
La evolución de la automatización: de los CPS a los Digital Twins
Si volvemos ahora un momento sobre la afirmación de Kevin Alshton sobre la necesidad de conectar las máquinas con la realidad, podemos entrever que hay un aspecto importante en el cual esta afirmación estaba radicalmente errada. No era cierto que las máquinas (en general y no sólo aquellas conectadas con la Web) no estuvieran ya ayudándonos a controlar, comprender y gestionar nuestros procesos en el mundo físico. Desde los años 70 y en evolución desde entonces la informatización basada en la automatización de procesos (Industria 3.0) no había parado de progresar en una evolución que a principios de este siglo tenía en la arquitectura ANSI/ISA-95 el paradigma integrado y jerárquico gracias al cual venían operado gran cantidad de sectores.
Cada nivel de la pirámide ISA-95 define un nivel de responsabilidad y abstracción, desde los componentes más físicos como interruptores, baterías o sensores térmicos (Sensors&Signals) hasta la consideración y modelado de máquinas completas (PLC), su correcto comportamiento y sus alarmas (SCADA/HMI), la ejecución de operaciones de mantenimiento o producción (MES) o la integración de la planificación y la estrategia de negocio (ERP).Una ingente cantidad de tecnologías de control ya estaban desarrolladas para ser conectadas con el naciente terreno de juego de la Web y sus portentosas capacidades para virtualizar cada activo y la información asociada a él. Esta otra vertiente de la computación comenzó a adoptar rápidamente aspectos relacionados con las nuevas comunicaciones derivadas de Internet y la posibilidad de distribuir el procesamiento en elementos desagregados que permitieran tener sistemas más abiertos y resilientes.
Cyber-Physical-Systens (CPS)
El concepto inicial acuñado en el mundo de la automatización que ya hacía foco en la virtulización (digitalización) de las funciones analógicas de las máquinas fueron los Cyber-Physical-Systems (CPS). Es habitual citar a Helen Gill (NSF) como la creadora de este concepto entorno a 2006. Un sistema CPS está compuesto por dos partes que interactúan de forma continua (i ) parte analógica donde se puede medir, controlar y operar un determinado proceso físico; y (ii) parte cibernética que modela no sólo el proceso (establecer setpoint, alarmas, condiciones regulación, etc) si no la máquina o la parte analógica como tal en la que se produce el proceso a controlar. La capacidad de proceso de la parte cibernética ha ido evolucionando de forma muy rápida, dotándola también de capacidades de comunicación extendidas de forma que en el mundo de los CPS es posible hablar de comunidades de sistemas de colaborar en las ejecución de procesos más complejos. Por lo general el software requerido para los CPS tiene unos requerimiento de tiempo real y precisión muy superior al software tradicionalmente empleado en la tecnologías de Internet. Este software es llamado firmware o software embebido e inicialmente estaba diseñado para correr sobre procesadores muy especializados y de capacidades muy específicas al proceso físico que debían gestionar. Actualmente, la evolución de estos componentes y el abaratamiento de los mismos ya permiten la gestión de estos procesos con elementos de propósito general.
Digital Twins
Gracias a la representación virtualizada de los activos que permiten los CPS, la conexión de los mismos con arquitecturas mucho más abiertas como Internet ha seguido su camino natural, pasando de los CPS a la representación en Gemelos Digitales (Digital Twins).
El concepto Gemelo Digital fue acuñado en 2002 por Michael Grieves,en el contexto del PLM (Product Lifecycle Management) en el mundo industrial de la fabricación, haciendo referencia a la posibilidad de simular un activo o un producto mediante datos y algoritmos sin la necesidad real del recurso físico en sí. Aunque el término Gemelo Digital es el más empleado, algunos fabricantes usan también el de Modelo Digital (Digital Model) o Sombra Digital (Digital Shadow), graduando el nivel de integración que el Gemelo Digital tiene con los CPS o la parte analógica del mismo. Un Gemelo Digital es "puro bit", es completamente digital e incluye tanto el modelo de datos necesario para representar toda la información relativa a un activo físico o un CPS, como el conjunto de algoritmos que lo gobiernan. Estos algoritmos son muy variados y generalmente se centran en el uso que se quiera dar a ese Gemelo Digital: pueden ser sencillas reglas de umbrales entre las magnitudes consideradas (ejm.- en una bomba de impulsión, por ejemplo, su temperatura, nivel de vibración, consumo eléctrico, etc) que permitan controlar regímenes de operación no soportados por las máquina, o modelos de IA adaptativos que de forma continua, tratan de simular el funcionamiento de la máquina física concreta.
Gracias a la adición de potentes elementos de comunicaciones (cada vez más basados en protocolos abiertos basados en TCP/IP) que permiten trasladar medidas y mandos de forma deslocalizada y remota, los Gemelos Digitales pueden ser ejecutados junto a las máquinas mismas donde se ejecutan los procesos o aguas arriba en plataformas en nube. Las tecnologías ligadas al inicial IoT se han mostrado muy potentes para nutrir con datos reales los Gemelos Digitales cuando estos quieren representar el estado online de una máquina o para concentrar la información necesaria para crear modelos de simulación de los activos en los grandes Data Lakes mencionados con anterioridad.
Distintos grupos profesionales, sectoriales, cluster tecnológicos y iniciativas académicas, han intentando estandarizan el concepto de Gemelo Digital con muy diferente éxito. Onesait Platform Things emplea en el soporte a Gemelos Digitales la aproximación del W3C llamado Web of Things y que puede ser consultado en: W3.org WoT. Este estándar permite la definición de los Gemelos Digitales mediante descriptores JSON y la comunicación con los protocolos más extendidos en el mundo IoT.
Sistemas Edge Computing.
Como hemos ido viendo en este capítulo, las arquitecturas iniciales de IoT pueden dar cobertura técnica a gran cantidad de escenarios de negocio apoyándose en distintas formas de representar y gestionar la información adquirida desde los dispositivos en campo. Nutrir un Data Lake de información que procesarán los Data Scientists para crear modelos predictivos, cruzar datos con técnicas Big Data en busca de correlaciones no identificadas, o aislar perfiles y agrupaciones de usuarios por los wearables que visten; son casos de uso que no suelen requerir una respuesta inmediata ante los eventos que se producen y por lo general no implican la gestión de gran cantidad de información de forma individual. Sin embargo, y como hemos visto en el apartado de los CPS y los Gemelos Digitales, la industria en general, los sistemas de misión crítica o los sistemas autónomos, hay situaciones en las que los mencionados aspectos sí son realmente importantes. Para cubrir estas carencias y avanzar en la convergencia generalizada entre las tecnologías de operación/automatización y las procedentes de Internet y el OT; surgen los sistemas de Edge Computing.
La palabra Edge en este contexto significa literalmente, una distribución geográfica. Wikipedia define Edge Computing como aquella arquitectura que “empuja la frontera de las aplicaciones informáticas, los datos y los servicios de los nodos centralizados a los extremos lógicos de una red. Edge Computing permite que la recopilación y analítica de datos ocurran cerca de la fuente donde estos se producen ".
Las arquitecturas basadas en Edge Computing, intentan resolver cuatro importantes problemas bien conocidos que han surgido en el despliegue del IoT tradicional en los entornos más exigentes comentados:
problema del funcionamiento desatendido
problema del volumen de información
problema de latencia en la decisión asistida o automática
problema de la protección local de la información, que recientemente y debido a la consideración de la seguridad y privacidad en los datos de IoT intercambiados entre dispositivos y nube, ha ido adquiriendo notoriedad.
En un esquema tradicional de IoT, el procesamiento de la información para la toma de decisión se centraliza en la nube. Este es un elemento remoto dependiente de las comunicaciones. Aunque se pretenda el continuo online de los dispositivos, este no puede ser asegurado totalmente. Gran cantidad de casos de uso requieren que los dispositivos tengan capacidades locales para la toma de decisión.
En muchas industrias, la producción de datos ha crecido más rápidamente que el ancho de banda, y gran parte de estos datos tienen poco valor. La agregación local y el filtrado de datos permiten a los clientes enviar solo datos de alto valor a la nube para su almacenamiento y análisis reduciendo el coste de la comunicación. Adicionalmente, el ancho de banda de las instalaciones y sitios es siempre finito y aunque podemos aumentarlo (con su correspondiente incremento de costo), nunca tendremos la capacidad de hacerlo crecer tanto como el volumen total de información generada que se basa en el hecho físico según el cual, mover información siempre lleva un tiempo proporcional a la distancia entre emisor y receptor. En los nuevos escenarios de uso previstos por la ampliación de la red 5G, la capacidad de gestión en sistemas de misión crítica o autocontrolados con latencias inferiores a segundos, requieren una computación cercana que no pueda retrasar cálculos enviándolos a ser realizados en una infraestructura distante de donde se debe implementar la acción final.Los clientes desean crear aplicaciones que tomen las decisiones más interactivas y críticas a nivel local, como en el control crítico de la seguridad laboral. Esto está determinado por las leyes básicas de la física: lleva tiempo enviar datos a la nube y las redes no tienen una disponibilidad del 100%.
En algunas industrias, los clientes tienen requisitos reglamentarios o de cumplimiento para aislar o duplicar datos en ubicaciones particulares. Algunos gobiernos imponen restricciones de soberanía de datos sobre dónde se pueden almacenar y procesar los datos. La mejor forma de proteger la información es duplicarla/moverla lo menos posible de allí donde es producida.
Desde un punto de vista de conectividad entre la nube y los elementos distribuidos, Edge Computing emplea la división de la misma en capas de responsabilidad. Cada una de estas capas de responsabilidad (tiers) se asume parte del procesamiento, almacenamiento, control e interacciones humanas que antes se realizada de forma centralizada.
Se suele indicar que los sistemas y arquitecturas de Edge Computing extienden las arquitecturas tradicionales IoT con cuatro capacidades no presentes anteriormente. Estas capacidades afrentan los problemas planteados:
Distribución del procesamiento:en estos sistemas los elementos aguas abajo disponen de todas las capacidades necesarias para operar de forma autónoma sin conectividad con una infraestructura centralizada para llevar a cabo labores de control, optimización, etc. Esta configuración solventa tanto el problema de la operación autónoma como el delay en la decisión antes comentados.
Distribución del almacenamiento de datos jerárquizado: en estos sistemas sólo la información relevante para cada de nivel de responsabilidad es comunicada de forma habitual. La agregación tras un procesamiento inicial permite compartir la información que sí es relevante para niveles superiores de proceso. Esto no imposibilita el acceso a toda la información de forma global ya que todos los repositorios están disponibles en todo momento. Ejm.- la adquisición continua de información de vibración de un sensor en una máquina produce raw-data en fracciones de segundo, esta información debe quedar disponible para posteriores mejoras en el análisis, pero normalmente será procesa in-situ con un elemento de Edge Computing que identifique patrones de predicción de fallo. Serán estos eventos los que serán enviados aguas arriba para su correcta gestión. Esta configuración ayuda a minimizar tanto el problema del volumen de información como el de la protección de la misma.
Un entrega rápida del servicio allí donde es necesario: gracias a esta capacidad, el servicio requerido del sistema puede ser entregado (a otros sistemas o a humanos) de forma homogénea y más rápida allí donde es necesario.
Bloques Funcionales
Dentro de los sistemas de Edge Computing podemos distinguir claramente entre los módulos que deben ser desplegados en nube para proporcionar una visión conjunta de toda la infraestructura desplegada así como la localización de datos y algoritmos, de los módulos que se despliegan de forma distribuida entre las distintas capas de responsabilidad definidas. Los módulos desplegados en nube extienden los ya mencionados de IoT, siendo los más habituales:
Repositorio de eventos y metadata de infraestructuras: este módulo almacena generalmente los datos telemetría proporcionados por los distintos dispositivos desplegados, así como los metadatos describiendo la propia infraestructura.
Repositorio de Aplicaciones: dependiendo de las tecnologías de aplicación permitidas por el sistema este repositorio contiene las aplicaciones a desplegar en las capas con capacidades de procesamiento medio o alto. Debe entenderse como infraestructuras de capacidades medias o altas aquellas que permiten el despliegue de un OS tradicional IT y la implementaciones de aplicaciones basadas en los lenguajes de alto nivel más extendidos Java, Pyhton, Go, Javascript, etc.
Repositorio de Firmware: para la gestión del ciclo de vida de los dispositivos más pequeños y limitados, donde se emplean lenguajes de bajo nivel con o sin OS de tiempo real, es común disponer de un módulo específico para el firmware con capacidades de actualización y parametrización remota (FOTA).
Gestión de alarmas y notificaciones: este módulo contiene la analítica sobre la información de telemetría adquirida de la infraestructura para a gestión proactiva de la misma.