Manos a la obra con: IoT con Azure

Manos a la obra con: IoT en Azure Ver. 1.0.1

Bienvenidos Acerca de… ¡Hola! Gracias por leer “Manos a la
obra con: IoT en Azure”. Espero poder aportarte los conocimientos mínimos y necesarios para que puedas iniciarte en este apasionante mundo. Jose María Flores Zazo, autor

Licencia bajo… Creative Commons Atribución 4.0 Internacional ¡Esta es una
Licencia de Cultura Libre!

Apúntate a la comunidad AZURE IOT # ESP https://jmfloreszazo.com/azure-iot-esp/

Índice Resumen Sección 1 Introducción Historia, actualidad, conceptos, teoría, arquitecturas,
… Sección 2 Python Para C# Devs

Índice Resumen del curso Sección 4 IoT con Azure IoT
Hub, IoT Edge, IoT Central y Digital Twins. Sección 3 Prueba de Concepto Proyecto y hardware necesario Sección 5 Seguridad Como proteger sensores, certificados, Azure Defender for IoT. Despliegues.

Índice Resumen del curso Sección 7 Avanzado IoT Plug &
Play, Gateways, diagnostico remoto, IA 2.0, Blockchain, … Sección 8 Otras opciones Apache, AWS, IBM, procesador ESP32, ... Sección 6 Análisis de datos Protocolos y Redes de comunicación. Proceso ETL o ELT complejo clásicos. Streams Analytics, TSI, ...

Requisitos previos y herramientas Guión Conocimientos sobre codificación en C#
Entorno de desarrollo Visual Studio Code y cuenta de Azure Una Rapsberry Pi y algo de circuitería

Sección 1 Introducción

¿Qué es IoT? Introducción(1/8) Antes de que me despertara, han
pasado muchas cosas en el IoT que me rodea. Mi comportamiento del sueño ha sido monitorizado por un sensor en un colchón y almohada inteligente. Los datos se enviaron a un endpoint de un servicio en la nube donde podrás consultar informes y telemetría en mi teléfono móvil. Cuando me despierto a la ahora de siempre, el despertador se había sincronizado con mi calendario laboral, ha visto que hoy por teletrabajo y por tanto no tengo que coger el tren a las 7.15 horas de la mañana y ha mirado que no exista ningún tipo de incidencia con los trenes, si no, el despertador se había sincronizado para levantarme por ejemplo a las 5.00 horas. Me levanto y me pongo el café recién preparado. Mi reloj, se comunica vía IFTT (if this, then that) y mi cafetera con Wi-Fi, al igual que mi sistema de climatización, las cámaras de seguridad, alarma y el alimentador de comida de mi mascota. La verdad es que ya no tengo un PC para hacer esto, todo lo gestiono con una Tablet o teléfono y la aplicación SaaS correspondiente de centralización de mi Smart Home (hogar inteligente), e incluso puedo usar mi televisión, pero aún no he instalado la app, aunque me la lleva sugiriendo desde hace días. Gracias al 5G ya no tengo ninguna maraña de cables por toda la casa e incluso puedo gestionar mi casa del pueblo, ahora mismo estoy viendo cómo se activa el riego automático, lleva 2 días sin llover y la información meteorológica de mi estación personal, me indica que el ambiente es seco y las plantas necesitan un poco de riego; el huerto de mi casa del pueblo está a 500 KM. Todo esto está ocurriendo mientras me tomo el café y una tostada a mi gusto, la tostadora sabe que soy y le he confirmado que quiero el tostado de siempre. ¿Qué tal si os cuento una historia? – Usemos el storytelling

¿Qué es IoT? Introducción(2/8) Antes de que me despertara, han
pasado muchas cosas en el IoT que me rodea. Mi comportamiento del sueño ha sido monitorizado por un sensor en un colchón y almohada inteligente. Los datos se enviaron a un endpoint de un servicio en la nube donde podrás consultar informes y telemetría en mi teléfono móvil. Cuando me despierto a la ahora de siempre, el despertador se había sincronizado con mi calendario laboral, ha visto que hoy por teletrabajo y por tanto no tengo que coger el tren a las 7.15 horas de la mañana y a mirado que no exista ningún tipo de incidencia con los trenes, si no, el despertador se había sincronizado para levantarme por ejemplo a las 5.00 horas. Me levanto y me pongo el café recién preparado. Mi reloj, se comunica vía IFTT (if this, then that) y mi cafetera con Wi-Fi, al igual que mi sistema de climatización, las cámaras de seguridad, alarma y el alimentador de comida de mi mascota. La verdad es que ya no tengo un PC para hacer esto, todo lo gestiono con una Tablet o teléfono y la aplicación SaaS correspondiente de centralización de mi Smart Home (hogar inteligente), e incluso puedo usar mi televisión, pero aun no he instalado la app, aunque me la lleva sugiriendo desde hace días. Gracias al 5G ya no tengo ninguna maraña de cables por toda la casa e incluso puedo gestionar mi casa del pueblo, ahora mismo estoy viendo como se activa el riego automático, lleva 2 días sin llover y la información meteorológica de mi estación personal, me indica que el ambiente es seco y las plantas necesitan un poco de riego; el huerto de mi casa del pueblo esta a 500 KM. Todo esto esta ocurriendo mientras me tomo el café y una tostada a mi gusto, la tostadora sabe que soy y le he confirmado que quiero el tostado de siempre.

¿Qué es IoT? Introducción(3/8) a es hora de salir 30
minutos a correr antes de ponerme a trabajar y el nodo edge del sistema de alarma, me avisará si escucha algún ruido anómalo o alguna imagen que no concuerde con las personas autorizadas a estar en mi casa, mi familia sigue durmiendo. Recientemente he activado la detección de animales para que el gato no active falsos positivos en el sistema de alarma y los despierte. Ahora mismo mi reloj inteligente está monitorizando mi actividad. Estos datos los está pasando el reloj vía Bluetooth LE a mi teléfono. Al mismo tiempo estoy usando el Bluetooth para las noticias que tenía en la cocina mientras desayunaba, en mis cascos. Al llegar a cierto punto del barrio, el ayuntamiento a puesto unas nuevas farolas, concretamente 2 de ellas están siempre tapadas por árboles, por eso siempre tardan más en desconectarse que las que tengo en la puerta de mi casa. Esto de la Smart City (ciudad inteligente) es un acierto, está contribuyendo a mejorar el gasto energético de mi ciudad. Ya de vuelta a casa, duchado y vestido, voy a por el coche, pero mientras bajo al garaje el teléfono me avisa que hoy debo ir por una ruta alternativa por qué la habitual está bloqueada por un accidente. Conduzco hasta mi puesto de trabajo con un tráfico relativamente fluido y por desgracia hoy me toca aparcar alejado de la oficina, tampoco es un drama, está a 15 minutos andando, esto mejorará mi nivel de salud la aplicación de salud. Si antes lo pienso antes me avisa, el reloj me acaba de otorgar una insignia motivacional por qué hoy antes de las 9.00 horas he realizado el ejercicio mínimo. Estoy llegando a la cafería, aun me quedan 100 metros, justo al lado de la oficia y la aplicación me sugiere el café típico que tomo todos los días, le digo que sí y la pago. Cuando paso al lado, amablemente me ofrecen mi café y subo a la oficina.

¿Qué es IoT? Introducción(4/8) Paso la tarjeta de mi empresa
antes de entrar, como tengo muchas reuniones y puedo molestar, me dirige a una sala de individual con una ventana de luz natural (este sitio está muy cotizado, he tenido suerte); pienso en la tecnología que mi empresa a implementado para preparar un entorno de mínimas emisiones y ahorro energético, es un acierto que si hoy vamos a estar pocas personas en la oficina, no ponga tanta calefacción y nos mande cerca de las ventanas para aprovechar el calor del sol, aparte de bajar el nivel de iluminación en consonancia con el nivel de luz exterior. También me da por pensar en cómo se comunican: con 5G y Wi-Fi creando una LAN, que también vale para conectarme directamente a la red con mi portátil. Mientras pensaba en esto, me llega un aviso al correo indicándome que no llegará a tiempo a la reunión una de las principales figuras de la misma. Esta persona desde su terminal móvil, ha cancelado la reserva de la sala donde tendría lugar la principal presentación del día, en el panel de la sala, aparece ya libre en la franja que había reservado. A la hora de comer, mi compañera, me cuenta por qué tuvo que cancelar la reunión, y por qué hemos ido a comer más tarde de lo habitual, afortunadamente desde su aplicación móvil, modificó la reserva de la sala y la hora en los calendarios de los asistentes. Me cuenta que su nuevo coche (smart car) mandó un patrón de anomalías al fabricante, parece ser que el sistema de distribución eléctrico no va bien, gracias al 5G y GPS de su coche, le llegó un taxi la grúa cuando comenzó a ocurrir el problema, que tenía un 80% de probabilidad de tener una avería en las próximas 72 horas. También me dice, que el fabricante (logística inteligente) ya estaba mandando la pieza cuando llegó el taxi, así esta tarde podrá coger el coche de vuelta a casa, todo ello en menos de 6 horas. Me quedo pensado en aquel día de 5 años atrás, cuando me quedé tirado en la carretera buscando el número del seguro y localizando a la grúa.

¿Qué es IoT? Introducción(5/8) Es la hora de salir y
mi compañera se dirige a un parking cercano, el conductor del taller del fabricante le ha dejado el coche aparcado en la plaza 527 de la planta -2, todo esto lo sabe gracias a que el parking esta automatizado y emitiendo la información de los sensores de la plaza de aparcamiento: la lectura de la matricula y la posición donde dejo el coche el operario. Nos despedimos y me dirijo a por mi coche, pero me llega un aviso muy importante de la planta de producción, que está cerca de mi casa, soy el técnico más cualificado que podrá llegar en menos tiempo. Maldigo al sistema de IA y me dirijo a la planta (Industria 4.0), mientras estoy cogiendo algo para cenar, ya me lo estoy oliendo, miro la telemetría de lo sensores y el posible problema: vuelve a fallar el detector laser de las palmeras de chocolate, desde hace 2 lotes, que no sabemos si la masa tiene o no restos de metales, han tendido que tirar todo y ahora mismo están avisando a los mecánicos para que lo cambien. Cuando yo llegue podré revisar la programación y realizar una serie de test para ver que la masa ya sale con el control de calidad necesario y mañana por la mañana todos ustedes puedan comerse una palmera de chocolate recién horneada. Dentro de la fábrica, mi tarjeta ha detectado que no suelo ir mucho por allí, así que me mandan a alguien para que me lleve a la maquina estropeada. Veo que mis compañeros, todos unos profesionales, han terminado su labor y se quedan conmigo para que pase los test. Hemos terminado y la telemetría va perfecta, pero como es un chip de segunda generación, debo modificar a que gemelo digital pertenece. Ya hemos terminado. Por fin vuelvo a mi casa.

¿Qué es IoT? Introducción(6/8) Al llegar a casa, veo que
son las 11.00 horas, muy tarde, demasiado, he estado trabajando muchas horas. Pero afortunadamente la política de la empresa está muy bien definida y mañana no tendré que trabajar. Gracias a toda la información que se ha intercambiado en los procesos, automáticamente se han cancelado las reuniones de mañana y tendré el día libre para compensar las horas. También participo en un programa piloto y mi perfil de salud + horario personal están integrados con parte de mi domótica: el despertador esa programado para que me pueda despertar con mi mujer e hijo y poder desayunar tranquilamente con ellos, la cafetera esta vez se conectará más tarde. Por fin a terminado mi día puedo descansar tranquilamente en mi casa, las persianas hace mucho tiempo que se bajaron cuando la luz solar desapareció y la calefacción está regulada automáticamente para que tengamos una temperatura confortable mientras dormimos. Aun no os puedo dar las “buenas noches”, he visto un aviso en el móvil. La temperatura de la zona de las basuras es un poco alta, la calefacción está funcionando a tope, este invierno es duro, y como no han tirado la basura, no quiero ir mañana por la mañana a la cocina y tener el desagradable olor de comida en proceso de putrefacción. Me toca tirar la basura. O cuento un poco como funciona esto. Tengo una alarma que si la temperatura sobrepasa un límite y la basura no la han tirado (los cubos tienen una báscula) me mande un aviso al teléfono. Además, como soy muy torpe con el reciclando y los símbolos/colores no terminan por aclárame donde debo tirar ciertas cosas, también tengo una cámara que detecta el desperdicio: una botella vacía de pastico, restos de un plato de macarrones, etc. Me indica donde debo tirar el desperdicio.

¿Qué es IoT? Introducción(7/8) Como vivo en una Smart City,
el contenedor correspondiente a reconocido el color de la bolsa y automáticamente se abre para que no tire las cosas donde no tocan, lo mismo ocurrirá con el camión de la basura. Ya puedo volver a mi casa y ahora sí: ¡Hasta mañana! Indirectamente ayudaremos a personas con dicacidad visual, nuestros mayores, …

¿Qué es IoT? Introducción(8/8) Que este caso sea cierto no,
se acerca bastante a la realidad actual. La Wikipedia define IoT de esta forma: Internet de las cosas (IoT) es la interconexión de dispositivos físicos (también llamados dispositivos conectados o dispositivos inteligentes), vehículos, edificios, u otros objetos dotados de electrónica, software, sensores o actuadores, junto a la conectividad de red que permiten a estos objetos recoger e intercambiar datos. https://en.wikipedia.org/wiki/internet_of_thing

Evolución y previsión Historia(1/4) El término IoT puede ser atribuido
a Kevin Ashton en 1997 y su trabajo en Procter & Gamble utilizando etiquetas RFID para gestionar cadenas de suministro. Este trabajo le llevó al MIT en 1999, donde el y un grupo de personas con ideas afines crearon el consorcio de investigación Auto-ID Center. Permítanme un pequeño inciso y que hable sobre mi contacto con IoT: Continuemos con la breve introducción histórica. ¿Cómo llegamos al IoT? – Veamos un poco historia contemporánea Mi primer contacto con SCADA data del 1998 para sensores higrométricos y temperatura en secaderos de jamones con ensamblador (fue muy de refilón no sabía ni lo que era), en 2008 entro en contacto con la Domótica, pero no es hasta 2012 sobre una aplicación domótica basada en Raspberry Pi y Heroku cuando entro en el mundo IoT. En 2016/2017 comienza mi segundo proyecto profesional, usando RFID como tecnología fundamental. Se trata de Laundry ID, galardonado con el 2017 EESC Civil Society Prize. Posteriormente siento las bases para otros proyectos con IoT y aspectos sociales, esta vez para ayudar a nuestros mayores. Idea de la cual me siento especialmente orgulloso y que cedí sin coste alguno. Tras estos dos contactos más sociales, comienzo mi periplo con un IoT más empresarial que van desde uso de Blockchain hasta la industria 4.0 (más bien 5.0 por haber usado IA enlatada). Muchas personas que estén leyendo este documento es posible que tengan un sistema IoT en su hogar del cual he formado parte (no puedo dar detalles). En cualquier caso, nunca he dejado de estar relacionado de una u otra manera con IoT desde 2012.

Evolución y previsión Historia(2/4) Año Dispositivo Enlace 1973 Mario W.
Cardullo, primera patente de RFID. 1982 Carnegie Mellon máquina expendedora de refrescos. 1989 Tostadora conectada a Interops’89. 1990 HP introduce HP LaserJet IIISi. La primera impresora conectada a una red. 1993 A alguien en la universidad e Cambridge se le ocurre conectar una cafetera a internet. 1996 Generals Motors OnStart: primer instrumento IoT en un coche y continua en el mercado. 1998 Se forma el Bluetooth SIG (Special Internet Group), ya os podéis imaginar el gran hito. 1999 A la gente de LG se le ocurre conectar un frigorífico: LG Internet Digital DIOS. 2000 Otra vez HP lleva la punta de lanza: Cooltown, un concepto de computación omnipresente. 2001 Primer producto con Bluetooth: podría decirse que KDDI es el primer teléfono con bluetooth. 2005 ITU Reports, hacen futurología del IoT, y dan en el clavo de muchas cosas. 2008 La IPSO Alliance primera alianza centrada en IoT. Ahora llamada omaSpecWorks. 2009 Cisco reconoce el termino IoT, por tanto, podría decirse que IoT acaba de nacer. 2010 Se crea el concepto de iluminación inteligente, ligado al desarrollo de las bombillas LED. 2012 Nace la primera Raspberry Pi, que nos acompaña desde entonces en muchas PoC. 2013 Apple crea el concepto de iBeacons (ver mi articulo en 2016/2017).

Evolución y previsión Historia(3/4) Año Dispositivo Enlace 2014 SigFox construye
una red de datos de banda inalámbrica ultra estrecha 2016 Dublín se convierte en la primera Smart City oficial de la historia 2017 Nace Internet of Battlefield Things: IoBT, ¿estamos ante el inicio de Cyberdyne Systems? 2018 Comienza a llegar al mercado el 5G 2020 El COVID-19 impacta en la implantación del IoT: Smart Building,Cities & Transportations IoT no genera más que expectativas y patentes nuevas en US. Por ejemplo, podemos mirar el número de tendencia de búsqueda en Google y podemos ver que el crecimiento es casi exponencial, luego cambio (nota) la forma de medir y comenzaron las fluctuaciones, pero se puede ver que la tendencia.

Evolución y previsión Historia(4/4) Y por revisar más datos que
demuestran ese gran internes. En 2021, según IoT Analytics Research, se estima que más de 12,6 billones de dispositivos de IoT estén conectados. No obstante, este otro estudio de Cisco discrepa un poco, aunque esa tendencia tan alta de ambos estudios no desmiente este crecimiento: Al menos a mi, me asombran las cifras del estudio Cisco – The Internet of Things. How the next evolution of the internet is changing Everything. Cisco IBSG, Abril de 2021 Población mundial 6,3 billones 6,8 billones 7,2 billones 7,6 billones Dispositivos conectados 500 millones 12,5 billones 25 billones 50 billones Dispositivos por persona 0,08 1,84 3,47 6,58 2003 2010 2015 2020 ¡Más dispositivos que personas!

Impacto, revolución y coherencia Potencial(1/3) No miento si digo que
esta afectando a todos los segmentos de la industria, la empresa, la salud y los productos de consumo. Es importante comprender el impacto, así como por qué estos ámbitos tan dispares se verán ven obligadas a cambiar la forma en que construyen sus servicios o proporcionan sus servicios. Quizá tu perfil profesional te obligará a centrarte en un segmento en particular; sin embargo, es útil comprender la superposición con otros casos de uso, tal y como he mencionado en la historia que os he contado. Un dato imporante es el PIB en US que pasa en 2016 de $75,64 billones, a una estimación en 2021 de $85 billones. Esto nos muestra la escalada de objetos conectados cuantitativamente. Es un dato que para los analistas no tiene precedentes y no va a parar. Se estima en un reciente estudio que es que hasta 2035 la tasa interanual sea de un crecimiento de 20%. Esto nos muestra que el potencial desde Q4 de 2021, fecha en la que publico este documento, hasta el 2035 es grande, que aun quedan muchas cosas por conectar y que nuevamente aparecerán cosas que estarán conectadas. Solo tenemos que ver el numero de patentes relacionadas con IoT en US, que esta creciendo exponencialmente. Creo que estos números a simple vista impactan. Pero según esta la tasa de crecimiento poblacional, se estima que los objetos conectados con los humanos deben estabilizarse, y que los objetos M2M (maquina a maquina ) serán la mayoría de los dispositivos conectados a internet. La revolución – Estamos ante un nuevo punto de inflexión en la historia

Impacto, revolución y coherencia Potencial(2/3) He hablado antes de un
impacto economico en el PIB de US, pero no solo son ingresos económicos lo que proporciona el IoT. Tambien impacta en un cambio de mentalidad y en como se afrontará aspectos cotidianos de la vida. El impacto de cualquier tecnología siempre viene asociado a: • Generar nuevas fuentes de ingresos, por ejemplo, soluciones para todo lo que está relacionado con el concepto verde: energía verde, consumo verde, etc. • Reducción de costes, por ejemplo, en la salud publica, atención domiciliaria, etc. • Reducción de tiempo de comercialización. Por ejemplo, automatizaciones en fábricas o mediciones para maximizar producciones agrícolas. • Mejora en la logística de la cadena de suministro, por ejemplo, el seguimiento de activos en tiempo real. Seguro que ya lo ven con los envíos de empresa de mensajería y vendedores como Amazon. • Aumento de la productividad. Por ejemplo, aprendizaje automático y análisis de datos. • Canibalización. Por ejemplo, interruptores de luz, los interruptores de Phillips Hue, que reemplazan a los interruptores de luz tradicionales. Espero poder haberles mostrado que puede atacar a modelos ya implantados y en algunos casos, si son cosas muy novedosas tendrá su implantación si existe un beneficio claro. Esto es algo normal en el mundo de la tecnología, en el caso de IoT su comportamiento no es diferente, como ya he dicho. Algo de lo más coherente en el mundo de los negocios.

Adopción por países: Adopción por tipo de sector: Source: IoT
Signals Report | Microsoft Azure. October 2021. Impacto, revolución y coherencia Potencial(3/3) Global US UK FR DE SP IT BNLX CH JP AUS % de adopción IoT 90% 94% 91% 91% 88% 89% 95% 91% 85% 88% 96% % proyectos en fase productiva 25% 27% 25% 23% 25% 22% 26% 25% 25% 23% 18% Tiempo de uso (meses) 12 11 13 12 14 11 10 12 16 12 16 Planeado usar IoT en más de 2 años 66% 78% 69% 67% 53% 76% 69% 59% 65% 51% 56% Global Industria Energía Movilidad Smart Places % de adopción IoT 90% 91% 85% 91% 94% % proyectos en fase productiva 25% 26% 22% 23% 24% Tiempo de uso (meses) 12 13 15 14 13 Planeado usar IoT en más de 2 años 66% 68% 61% 61% 69%

IoT Mi definición formal(1/2) Mi sugerencia es que vean todo
esto con cierto escepticismo. Creo que es imposible cuantificar los dispositivos conectados a internet. Además, tenemos que separar aquellos dispositivos que están naturalmente conectados a internet como teléfonos, tabletas, PC, servidores, enrutadores e infraestructura IT. Tampoco deberíamos incluir en el ámbito del IoT aquellas máquinas que hayan tenido presencia durante décadas en oficinas, hogares y lugares de trabajo que esencialmente estaban conectadas a una red. No incluiría impresoras, fotocopiadoras o escáner como parte del espectro IoT. Vamos a examinar IoT desde la perspectiva de conectar dispositivos que no necesariamente tienen por que estar conectados a internet o entre si. Estos dispositivos pueden que históricamente nunca hayan tenido ninguna habilidad computacional o de comunicación. Tal y como hemos visto anteriormente en la historia del IoT, de dispositivos tradicionalmente no conectables como una expendedora de refrescos o una cafetera o mi ejemplo de los cubos de basura. Desde mi punto de vista, los requisitos básicos de un dispositivo para ser considerado parte del IoT son: • Computacionalmente capad de albergar un protocolo de conexión a internet. • Hardware que pueda usar un transporte de red como por ejemplo un 802.3. • Ser un dispositivo que tradicionalmente no este conectado a internet, descartando PC, teléfonos, servidores, maquinas de productividad, etc. Internet of Things – Mi propia definición de internet de las cosas

IoT Mi definición formal(2/2) Tambien vamos a incluir dispositivos edge
(borde) en este documento. Ya que los propios dispositivos perimetrales pueden ser dispositivos IoT o pueden albergar otros dispositivos IoT. Los dispositivos edge, como explicaré más adelante, generalmente se gestionan como nodos que están cerca de la fuente de datos. Por tanto, no son los típicos servidores o clústeres que se encuentran en centros de procesamiento de datos (CPD): estos además de computar llevan asociados gestores medioambientales para mantenerlos refrigerados, sistemas de alimentación ininterrumpida, están aislados y protegidos con sistemas de seguridad, etc. Sin embargo, los dispositivos edge, suelen estar fuera y expuestos a elementos climáticos, en áreas donde la energía sufre cortes, etc. En ocasiones, los dispositivos edge también pueden ser nodos de servidores tradicionales, pero fuera de los límites de un CPD. Si veis como he acotado la definición, habréis visto que el mercado de IoT es mucho más pequeño que los análisis anteriores que he puesto, como el de Cisco. Cuando separamos los dispositivos tradicionales de IT y los de IoT, la tasa de crecimiento es muy diferente. No voy a cuantificar cual es ese dato, por qué, como comprenderéis, carezco de la capacidad para ofreceros una cifra o un estudio oficial. Lo que, si que voy a recalcar, es que la mayoría de las instalaciones IoT no son un solo dispositivo que tenga la capacidad de ejecutar software y albergar hardware que conecte con Internet. La mayoría de lo sensores y dispositivos no la tienen de forma directa, por tanto, se conectan s otro que, si lo tiene, via comunicación non-IP como el bluetooth o ModBus o RS232 u otras conexiones aun más antiguas. Espero que con esto tengáis claro que es para mi IoT y Edge.

Industria y manufactura Casos de Uso(1/12) Es uno de los
segmentos más grandes y de más rapido crecimiento en IoT por la cantidad de cosas conectadas, por el valor que conlleva la fabricación y automatización de esos servicios. En este segmento es práctica común el OT (Operations Technology) donde se involucra hardware y software como herramienta de monitorización de los dispositivos físicos en tiempo real. Industrial IoT – IIoT Estos sistemas de OT históricamente han sido computadoras y servidores en la instalación del cliente para administrar el rendimiento de la planta y la producción. Estos sistemas son los denominados system supervisory control and data acquisition (SCADA). Este sector tradicionalmente tenia las dos secciones tecnologías separadas: • OT, se encarga de métricas de rendimiento, de medir el tiempo de actividad y los datos en tiempo real, cumplimento, etc. • IT se centra en la seguridad, en entrega de datos y funcionamiento de los servicios, entre otras cosas. A medida que IoT aparece en esta industria, ambos mundos se combinan, por ejemplo, con el mantenimiento predictivo de miles de dispositivos y maquinaria de producción. La característica principal de este segmento es proporcionar información casi en tiempo real para que OT. Es decir, que la latencia es un problema imporante en el IoT de una fabrica.

Industria y manufactura Casos de Uso(2/12) Y como las secundarías
más inmediatas: proporcionar tiempos de inactividad y control de la seguridad. Esto implica servicios redundantes, tanto en nubes privadas como en publicas. El sector industrial es el segmento con más rápido crecimiento. Pero por desgracia, existe lo que se conoce como brownfield: tecnologias de hardware y software obsoletas. Puedes encontrarte sistemas con comunicación RS485, en lugar de las modernas tecnologias inalámbricas. Casos de uso: • Mantenimiento preventivo de la maquinaria nueva y existente. • Aumento del rendimiento a través de la demanda en tiempo real. • Ahorro energético. • Sistemas de seguridad, como por ejemplo detección de fugas. • Sistemas expertos en planta.

Consumidor final Casos de Uso(3/12) Industria 1.0 • Factorías •
Vapor Industria 2.0 • Producción en masa • Petróleo y gas • Electricidad • Telégrafo Industria 3.0 • Cadenas de montaje • Microprocesador • Computadoras Industria 4.0 • Digitalización • PLC • IIoT • Robots Industria 5.0 • IA • Personalización masiva Evolución de la industria

Consumidor final Casos de Uso(4/12) El sector del consumidor final
fue uno de los primeros en adoptar la tecnología, como fue la maquina de café en la universidad que vimos en la parte de historia. Este sector floreció gracias al bluetooth, a principios de la década del año 2000. Ahora millones de hogares tienen desde bombillas Hue, hasta asistentes Alexa. Adopción temprana – De los primeros segmentos en adoptar IoT Las personas también estamos conectadas desde los Smart Watch de Garmin (con su ANT+ propietario y Bluetooth) o Apple, hasta otros dispositivos como los audífonos de Oticon (via bluetooth o IFTTT). Este mercado suele ser el primero en adoptar nuevas tecnologías. En este sector, los solemos llamar gadgets (dispositivos) que tienen una característica muy imporante: suelen ser completamente plug & play. Una de las limitaciones de este mercado es la bifurcación de estándares. Por ejemplo, vemos que existen diversos protocolos WPAN: Bluetooth, Zigbee, Z-Wave, ANT+, etc. que obligan a los productos a implementar 1 o varios protocolos que no son necesariamente compatibles entre si. Este segmento tiene un potencial muy grande en área de la salud. Los cuales los separo aquí, ya que los del hogar no son los mismos que los de cuidados médicos: los que tienen un Apple Watch saben que pueden hacer un electro e incluso durante un tiempo la FDA otorgó una certificación, ahora ya no, han visto que esto gadgets de andar por casa, no se acercan a los estándares necesarios en la medicina.

Consumidor final Casos de Uso(5/12) Si alguien lo esta pensado,
no podemos comparar un sistema de insulina IoT MiniMed 770G con un Apple Watch 6. El sector industrial es el segmento con más rápido crecimiento. Pero por desgracia, existe lo que se conoce como brownfield: tecnologias de hardware y software obsoletas. Puedes encontrarte sistemas con comunicación RS485, en lugar de las modernas tecnologias inalámbricas. Casos de uso: • Smart Home: sistemas de riego, cerraduras, luces, termostatos, persianas, ... • Wearables: monitorización de salud y movimiento, ropa inteligente, ... • Mascotas: sistemas de localización, puertas automáticas para perros y gatos, … Es fundamental que conozcas las diferencias fundamentales entre IoT e IIoT: Características IoT IIoT Descripción Orientación Consumo Industria IoT se centra en consumidor. IIoT se centra en industria y fabricas. Exactitud y precisión Baja Alta La precisión de IIoT es más alta que IoT debido a que la industria necesita niveles precisos de medidas y mayor tolerancia a fallos. Impacto y riesgo Bajo Alto IIoT funcionan en entornos como la aeronáutica, salud, etc. Donde el impacto y riesgo es muy alto Mientras que IoT funciona en entornos de consumo donde el impacto y riesgo es mucho menor.

Comercio minorista, finanzas y marketing Casos de Uso(6/12) Viene a
referirse a cualquier espacio donde se producen transacciones comerciales basadas en el consumidor. Puede ser por ejemplo una tienda física o una oficina bancaria. Van desde los tradicionales sistemas bancarios y de aseguradoras, hasta ocio y hostelería. El impacto en IoT en la cadena minorista ya esta en proceso, por ejemplo, intentando reducir el coste de ventas y mejorar la esperiencia de usuario gracias a las herramientas de IoT. Cliente & Vendedor– Mejora de la relación Para simplificar las agrupaciones, he incluido la publicidad y el marketing en esta categoría. Por ejemplo, puedes obtener publicidad personalizada, un descuento, en tu teléfono móvil via iBeacon cuando pasas por un quiosco de tu marca de perfume favorita en un gran almacén. Este sector va en la linea de medir transacciones inmediatas. Si la solución de IoT no esta dando respuesta, evidentemente debes revisarla. Esto impulsa nuevas formas desde mejorar ahorros hasta generar ingresos. Permite que los minoristas sean mas eficientes, ofrezcan una mejor experiencia de usuario al tiempo que se minimizan gastos y perdidas en las ventas. Casos de uso: • Publicidad dirigida para captar clientes potenciales y retener antiguos clientes. • Beacons, ya lo he comentado antes. Pero además permite mapear y analizar para tus campañas de marketing. • Seguimiento, monitorización de alimentos. Aplicar predicción a la cadena de suministro, etc. • Medición del riesgo en conductores. • Balizas en lugares de entretenimiento, conferencias, museos, etc.

Salud Casos de Uso(7/12) El impacto en IoT que genera
la industria de la salud compite al mismo nivel que el de la fabricación y la logística. En los países desarrollados todo lo que implique mejorar la calidad de vida y reducir los costes de salud, son una de las principales preocupaciones. Adopción temprana – De los primeros segmentos en adoptar IoT IoT esta esta preparado para permitir la monitorización remota y flexible de los pacientes en cualquier lugar. Las herramientas avanzadas de análisis y aprendizaje automático observarán a los pacientes de tal forma que lograrán diagnosticar enfermedades y prescribir tratamientos. Estos sistemas también serán los perros guardianes en caso de necesidad de cuidados críticos. Actualmente, existen alrededor de 500 millones de monitories de monitories portátiles de salud, con un crecimiento muy acuciado en los proximos años. Las limitaciones de los sistemas sanitarios son importantes: GDPR, seguridad de datos y red (no queremos que nadie entre en la red de un hospital o remotamente desconecte un marcapasos), que deben ayudar en la calidad de los hospitales y el equipo usado, que en campo deben tener comunicación, en domicilio deben funcionar 24/7, … Casos de uso: • Atención en hogar de paciente. • Modelos de IA: aprendizaje, predictivo y preventivo. • Atención y seguimiento de ancianos, una idea mía esta en el mercado y ayudando a la tercera edad. • Seguimiento de activos de suministros y equipo hospitalario.

Trasporte y logística Casos de Uso(8/12) Desde mi punto de
vista en el transporte y la logística el IoT es un factor muy importante, incluso me aventuro a decir que el más importante hoy en día. Los casos de uso implican a dispositivos que rastrean lo activos que se entregan, transportan o se envian, ya sea en camión, tren, barco o avión. Simbiosis perfecta – IoT el factor más importante de este sector en la actualidad Además, lo interesante es que los vehículos conectados serán quienes ofrezcan asistencia al conductor y a mantenimiento preventivo para que el conductor actúe. Según fuentes del sector del automóvil, actualmente la media son 100 sensores en cada vehículo. Logicamente se van a duplicar o quintuplicar, ya que habrá comunicación (en un futuro) entre la carretera y vehículo que revertirán en seguridad y comodidad. Más allá del sector del consumo esto es extensible a los sistemas más complejos como trenes, barcos o aviones. Como anécdota, uno de los primeros transportes en ciudad que llevaron IoT fue el transporte de dinero en vehículos blindados, y esto ya es una realidad en flotas de mensajería cuando llevan nuestra valiosa compra de Amazon. Logicamente estoy hablando de la geolocalizando con GPS. Casos de uso: • Seguimiento de flotas. • Planificaciones, enrutamientos y monitorización de vehículos. • Identificación y seguimiento de contenedores, activos y paquetes dentro de las flotas. • Mantenimiento predictivo de vehículos.

Agricultura y medioambiente Casos de Uso(8/12) El IoT en la
agricultura y medioambiente va desde la salud del ganado, la tierra y analisis de suelos, las predicciones microclimáticas, uso eficiente de agua hasta las predicciones de desastres geológicos y climáticos. Se prevé que en 2035 se duplique la producción de alimentos, por tanto, las hambrunas decaerán. Sector emergente – El sector con más retos y mayor reconocimiento en la sociedad El IoT agrícola será una de las razones fundamentales de ese dato tan esperanzador. Por ejemplo, usando eficientemente el agua, la iluminación, controlando los nutrientes del suelo, controlando la tasa de mortalidad de los activos (plantas, peces o animales), etc. El ahorro que se prevé es muy grande, por ejemplo, con la luz, se dice que bajar un millo de dólares al año: ¿menos agua que sale de una presa para generar electricidad?, ¿menos carbón quemado?, ¿menos combustión de gas?, … lo que sea, pero ya puedes apreciar que también incidirá en el impacto climático y en convertir el planeta en un mejor sitio. Gracias a los nuevos protocolos de comunicación de largo alcance podremos medir en áreas remotas y peligrosas como volcanes o en cafetales de alta montaña. Casos de uso: • Riego y fertilización para mejorar rendimientos. • Seguimiento de salud y población en activos como el ganado. • Mantenimiento preventivo de material agrícola. Agricultura robotizada. • Monitorización de volcanes y fallas o mareas para predecir desastres.

Energía Casos de Uso (9/12) El sector de la energía
incluye el seguimiento desde la producción hasta el consumo final. Muchos de ustedes tendrán ya lectura de contadores de forma remota. Básicamente todo el esfuerzo en este sector se basa en la monitorización comercial y de consumo, los dispositivos Smart Electric usan un protocolo de comunicación de baja potencia y largo alcance. Relación directa – Prácticamente se basa en Smart Operations Muchas instalaciones de producción energética se encuentras en entornos remotos y hostiles, regiones desérticas donde se sitúan paneles solares o laderas empinadas donde están los parques eólicos e incluso reactores nucleares. En estos ambientes los datos suelen requerirse casi en tiempo real, ya que una respuesta en ciertos casos debe ser inmediata, es una respuesta crítica. Los protocolos de comunicaciones de largo alcance que comenté antes en agricultura y medioambiente han venido de este sector. Casos de uso: • Analisis de plataformas petrolíferas donde existen miles de sensores que optimizan la producción y eficiencia. • Monitorización y mantenimiento de paneles solares y parques eólicos. • Ajustes y orientaciones en tiempo real de paneles solares y parques eólicos. • Analisis medioambientales de centrales nucleares. • Medidores de gas, agua y electricidad en los hogares, donde ayudan a balancear la demanda y ajustas las tarifas.

Smart City Casos de Uso(10/12) Es una denominación que se
usa para referirse a una infraestructura inteligente y conectada, ciudadanos y vehículos. Las ciudades inteligentes son uno de los segmentos de más rapido crecimiento y muestran una relación coste/beneficio muy importante, especialmente en lo que respecta a ingresos fiscales. Smart City – La ciudad inteligente Las ciudades inteligentes también inciden directamente en los ciudadanos (no solo en el bolsillo) con respecto a la seguridad y protección. Por ejemplo, varias ciudades como Seul han adoptado conectividad IoT para monitorizar los contenedores de basura y la recolección con respecto a la capacidad de los mismos. Y nosotros desarrollaremos un dispositivo para nuestra casa, así sabremos en que contenedor tirar el desperdicio, e indirectamente ayudando a personas con diversas discapacidades. Aunque hemos hablado antes de eficiencia energética en China con las cámaras y la seguridad, se requiere mucho ancho de banda y energía. Por otro lado, los ciudadanos podemos ayudar con sistemas como lo que yo tengo implantado para monitorizar la contaminación en mi barrio, lo que se conoce como Ciencia Ciudadana, que consume poco (observar Alemania, esta prácticamente toda controlada). Un punto a tener en cuenta que las regulaciones gubernamentales afectan mucho en las Smart Cities. Casos de uso: • Control contaminación, control energético y eficiencia en alumbrado, … • Predicciones de microclima con sensores repartidos por toda la ciudad (por ejemplo, el mío), …

Militar y Gubernamental Casos de Uso(11/12) Cada gobierno tendrá su
especial interés, licito o no dependerá de donde vivamos y nuestra cultura. Los gobiernos tanto municipales como estatales, tienen mucho internes en el IoT. Puede ir desde control de emisiones de CO2 hasta defensa contra ataques terroristas. Habrá algunos que nos parecerán buenos a todos, pero otros como el control ciudadano no. Un gran interés – Desde España hasta China pasando por USA A nivel de gobierno como ya he dicho puede medir para controlar emisiones de CO2, pero también el control de infraestructura de carreteras o puentes. A nivel militar va desde defensa hasta ataques terroristas en el suministro de agua. Esto implica que los gobiernos se reserven ciertos anchos de banda, tecnologias de baja frecuencia y consumo para ellos. Como ocurrió con el GPS hasta que llegó a los ciudadanos y a un así con ciertos recortes en la precisión, sin ir mas lejos. Casos de uso: • Cámaras en ciudades para buscar caras e identificar a delincuentes. • Control via balizas de ataques terroristas en agua, luz, o gases, por ejemplo. • Enjambres de drones para controlar eventos masivos. • Sensores en campos de batalla para monitorizar amenazas. • Sistema de seguimiento de activos gubernamentales: presas, carreteras, puentes, etc.

Top 10 Casos de Uso(12/12) Source: IoT Analytics Research 2021.
October 2021. Informe – https://iot-analytics.com/top-10-iot-use-cases/ Top Caso de Uso Tipo Adopción Global Tendencia 1 Monitorización remota de activos (solo lectura). Smart Operations 34% Medio-Alta 2 Automatización de procesos basados en IoT. Smart Operations 33% Alta 3 Monitorización remota y control de activos (lectura y escritura). Smart Operations 32% Mantiene 4 Gestión remota de flotas. Smart Supply Chain 31% Medio-Alta 5 Seguimiento y localización. Connected Products 31% Medio-Ata 6 IoT para la optimización del rendimiento de activos/plantas. Smart Operations 31% Muy Alta 7 Control y gestión de la calidad basado en IoT. Smart Operations 30% Medio-Alta 8 Monitorización de las condiciones de las mercancías en transito basado en IoT. Smart Supply Chain 29% Mantiene 9 Mantenimiento predictivo. Smart Opertions 29% Medio-Alta 10 Seguimiento y rastreo in situ. Smart Supply Chain 29% Medio-Alta

¿Qué es…? Definiciones en profundidad(1/4) Sensores, actuadores y sistemas físicos
Sistemas integrados, sistemas operativos en tiempo real, fuentes de captación de enérgica, sistemas microelectromecánicos (MEM) Sistemas de comunicación de redes de área personal inalámbricas (WPAN) Alcanzan de 0 cm a 100 m. Comunicaciones de baja velocidad y bajo consumo, a menudo no basados en IP que tienen lugar en las comunicaciones con los sensores. Redes de área local (LANs) Normalmente sistemas de comunicación basados en IP como Wi-Fi 802.11 utilizado para comunicaciones de radio, son rápidas y de alta volumetría, a menudo don peer-to-peer (punto a punto) o con topologías en estrella. Agregadores, routers, gateways Proveedores de sistemas integrados y bastante baratos. Nos permiten crear pasarelas y las comunicaciones de los dispositivitos conectados. Redes de área amplia (WANs) Proveedores de red movil que usan LTE o Cat M1, proveedores de satélites, rede de baja potencia (LPWAM) como SigFox o LoRa. Suelen usar protocolos de internet como MQTT, CoAP e incluso HTTP. Argot, jerga, … – Lo de siempre, vamos a aprender vocabulario y conceptos relacionados

¿Qué es…? Definiciones en profundidad(2/4) Edge Computing Computación en el
borde. Distribución de la informática desde los centros de datos locales y en la nube a las fuentes de datos (sensores y sistemas). Se eliminan problemas de latencia, mejora en tiempos de respuestas y acercan más el tiempo real y gestionan la falta de conectividad con redundancia. Edge Analytics Relación directa con el punto anterior. Pero como es un concepto que se maneja, lo separo. Se trata del analisis perimetral de datos que eliminar carga de trabajo en el computo de la nube. En lugar de enviar simple telemetría, se envia información procesada en el borde. Cloud Nube. Infraestructura del proveedor de servicios: es la plataforma de servicios, las bases de datos, el sistema de streaming, el proveedor del ML, etc. Muchos servicios que podemos llegar a usar para completar nuestra arquitectura de IoT. Analisis de datos A medida que la información se propaga en la nueve, debemos tratar con volúmenes de datos muy altos y complejos. Por tanto, una parte fundamental del IoT es el analisis de datos y convertir el posiblemente Big Data generado en algo manejable y del que podamos sacar desde analisis estadísticos hasta datos para generar ML.

¿Qué es…? Definiciones en profundidad(3/4) Digital Twins Un gemelo digital
es una representación virtual de un producto o proceso de producción de modo que los ingenieros puedan examinar su diseño, probar potenciales cambios y detectar errores antes de enviarlos a la vida real. Contenedor Es una forma de virtualización, salvando las distancias. Se usa para ejecuta cualquier cosa y contienen todo lo necesario para ejecutar el binario, a excepción de la virtualización, los contenedores no albergan el sistema operativo. Modulo En IoT es como un contenedor que se aloja en el Edge. Extendiendo Twins, un modulo puede tener un Module Twins, que cumple la funcionalidad del anterior gemelo descrito. Blockchain Permitirá crear redes más seguras, en las que los dispositivos IoT se interconectarán de forma confiable, evitando amenazas como la falsificación de dispositivos y la personificación. IA 2.0 Se trata de llevar la IA a los dispositivos. Gracias a la tecnología Cognitiva (Azure Cognitive Services, por ejemplo). Podemos dotar a los dispositivos del borde con cierta inteligencia.

¿Qué es…? Definiciones en profundidad(4/4) Smart ¿qué? En la actualidad
cualquier palabra que veas iniciada con Smart (inteligente), como Smart City (ciudad inteligente, que hemos visto como sector) o Smart Movility (movilidad inteligente). Es prácticamente sinónimo de IoT aplicado a: la ciudad, la movilidad, coches, etc.: • Smart City, ciudad inteligente. • Smart Movility, movilidad inteligente. • Smart Places, lugares inteligentes. • Smart Cars, coches inteligentes. • Smart Automation, automatizaciones inteligentes. • Smart Home, hogar inteligente. • Smart Retail, ventas minoristas inteligentes (la verdad es que suena mal, en ingles ya parece otra cosa). • Smart working, trabajo inteligente. • Smart Energy, energía inteligente. • Smart Care, cuidados inteligentes. Y así podríamos continuar, muchas de ellas ya se usan como estandar de facto y otros comienzan a escucharse.

IoT vs M2M vs SCADA Comparación de tecnologias(1/3) Existe una
confusión en el mundo de IoT con la tecnología máquina a maquina (M2M). Antes de que IoT fuera parte de de nuestro argot, fue el M2M quien dominaba nuestro vocabulario y antes que este SCADA (control de supervisión y adquisición de datos); la corriente principal de maquinas interconectadas para automatismos industriales. Es cierto que esto acrónimos se refieren a dispositivos interconectados y pueden utilizar tecnologías similares, pero existen diferencias. M2M Es un conceto general, un dispositivo autónomo que se comunica directamente con otro dispositivo autónomo. Autónomo se refiere a la capacidad del nodo para instanciar y comunicar información con otro nodo sin la intervención humana. La forma de comunicación es libre para la aplicación. Es muy posible que un dispositivo M2M no use ni topologías ni servicios inherentes para comunicarse. Esto deja fuera a los dispositivos típicos de internet que utilizan con regularidad servicios y almacenamiento en la nube. Un sistema M2M también puede comunicarse a través de canales no basados en IP, como un puerto serie o un protocolo personalizado. Una confusión común – Que vamos a solventar

IoT vs M2M vs SCADA Comparación de tecnologias(2/3) IoT Los
sistemas IoT pueden incorporar algunos nodos M2M (como bluetooth usando una malla no IP), pero agregan datos en algun sitio, como un Edge. Un Edge que nos puede servir como enrutador o puerta de enlace para entrada y salida a internet. Alternativamente, algunos sensores con más potencia de computación podrán mover datos a internet por si solos, el propio sensor envia datos a internet. Independientemente de donde este el punto de acceso, es decir, que tiene un vinculo directo con Internet, lo que define en esencia a IoT. SCADA Se refiere al control, supervisión y adquisición de datos. Estos sistemas de control industrial que se han usado en fabricas, instalaciones, automatizaciones ,etc. desde 1960. Típicamente están involucrados los PLC (controladores de lógicos programables) que monitorizan o controlan varios sensores y actuadores en una maquinaria. Los sistemas SCADA actualmente están conectándose a servicios de Internet. Y aquí es donde vemos esa Industrial 4.0, están dejando de ser SCADA para ser IoT. Por desgracia tienen sistemas de comunicación muy obsoletos: ModBus, BACnet y Profibus, que precisan de gateways, por eso, existe esa linea difusa entre IoT y SCADA en la revolución 4.0.

IoT vs M2M vs SCADA Comparación de tecnologias(3/3) Como puedes
observar si no fuese por: • Al mover datos los sensores a Internet , via Edge o dispositivos inteligentes, • El mundo que hemos heredado de lo servicios en la nube cuando se pueden aplicar en los dispositivos como estos. • Mejoras en las baterías. • Mejoras en los sistemas de comunicación. • La inclusión del aprendizaje automático. • Etc. Aun estaríamos en el M2M. Es decir, que toda la anterior tecnología heredada de otros ámbitos ha propiciado la evolución del M2M al IoT.

4 Pilares Como unos grandes bloques de construcción… Considera IoT
como un LEGO o bloques de construcción. Y estos son los cuatro pilares fundamentales, que dependiendo de los grandes sectores que hemos visto antes, tendrán mayor o menor peso: • IoT, ya hemos hablado de ello ampliamente y lo conocemos. • Tecnología en la nube, en nuestro caso usaremos Azure y veremos más adelante a partir de la Sección 4. • Analisis de datos, que podremos ver en la Sección 6. • Seguridad, donde lo trataremos ampliamente en la Sección 5. Es como un LEGO – IoT tiene 4 pilares fundamentales que debemos tener en cuenta IoT Nube Datos Seguridad

IoT Estándar vs Edge IoT Modelos de IoT IoT Estandar
o clásico ESP8266 Telemetría en RAW Telemetría Procesada IoT Estandar o clásico Rapsberry Pi Telemetría Raw Telemetría Procesada De una forma muy rústica pero simple, para que se entienda. Las primeras versiones de IoT y que se puede seguir usando hoy en día. Es la version estándar donde un dispositivo emite directamente la telemetría a la nube, aquí se procesa y se muestra la información, si quieres bajar la temperatura debe ser un proceso en la nube o el usuario, conlleva retardos entre la toma de decisiones. En el Edge, la Raspberry Pi puede tener la logica necesaria para regularla la temperatura en cuestión de milisegundos, por tanto, podrá o no llegar telemetría en bruto o simplemente lo que nosotros deseemos. Ejemplo burdo – Diferencia básica entre ambos modelos

Edge IoT IA/ML en el Edge Ya sabéis que la
IA ya implementa con éxito casos de uso en el campo de la visión, el procesamiento natural del lenguaje (NPL), reconocimiento del habla y seguridad. Pero todos esos casos de uso necesitan de un hardware muy potente que no es posible implementar en los humildes procesadores de los sensores. Pero que gracias a ML.NET, Tensorflow, etc. Podemos usar el modelo generado, que salvando las distancias es un pequeño fichero que ocupa muy poco, por ejemplo, 20KB o 5 MB, capad de ser procesado en un Broadcom BCM2711 de un Rapsberry Pi 4 e incluso en sus herramos menores, generando predicciones sobre los datos obtenidos por un sensor. En resumen, con la democratización de la IA y el bajo coste de procesamiento en el borde. El IoT están haciendo ese paso a la industria 5.0 y descentralizando el proceso, volviendo más reactivo y potencialmente con una perspectiva de futuro sin límite. IA/ML – Inteligencia Artificial y aprendizaje de máquina

Un modelo básico Estructura de una solución IoT

Un comentario para terminar Seguridad en IoT Debo enfatizar este
aspecto. Los dispositivos están conectados al mundo real y cualquier incidente de seguridad tiene el potencial de causar graves daños en el entorno inmediato, por no hablar de los delitos de ciberseguridad. Por tanto, siempre debe estar de lo primero de tu lista cuando diseñas cualquier componente hardware o software. Aunque la seguridad, merece un capitulo a parte y la trataremos más adelante, si que os enumero una serie de reglas de oro para cualquier dispositivo en el propio terreno: • Intentar proteger cualquier ataque sobre hardware y firmware. • Evitar que se manipulen físicamente los procesadores. No deberían estar a la vista. • Las claves, endpoint, etc. Deben estar almacenados de forma segura. • Usa comunicaciones cifradas, cambia las contraseñas por defecto, cierra puertos, … • Usa mecanismos de detección de anomalías y salud cuando sea posible. • Etc. Como desarrollador de IoT deberás adoptar los principios de un diseño seguro. Máxime cuando IoT tiene tantas piezas a controlar. Un sitio que te puede venir bien tener en cuenta es: https://www.iotsecurityfoundation.org/best-practice-guidelines/ Todo debe girar en todo a la seguridad – Es obvio

Sección 2 Python para C# devs

¿Por qué? Introducción ¿Por qué necesitas saber Python? Fundamentalmente por
qué es el lenguaje que vamos a usar para la PoC (prueba de concepto) relacionada con el reciclado y por qué la mayoría de los chips que debemos programar ya tienen las librerías para trabajar con Python (pasarlo a C3 suele ser más costoso que adaptarse), como Azure también tiene los SDK para trabajar con este lenguaje y por qué por ser un lenguaje muy pujante hoy en día en el mundo IoT. En resumen, en primer lugar, por necesidad para la PoC y, en segundo lugar, por ser el lenguaje de facto en el mundo IoT (que no el mejor, como os podrá mostrar más adelante). Si ya lo conoces, puedes saltarte este capitulo e ir a la Sección 3 directamente. Sin embargo, si sabes Python y no sabes C#, que usaremos para la parte backend de Azure, te recomiendo que busques un curso que sea similar a lo que aquí cuento: algo así como C# para Python devs. En gran parte esta sección tiene como misión que se pueda entender el codigo de la PoC que hemos realizado en Python. Python – https://www.python.org/

La base Características de Python La forma de abordar Python
desde el punto de vista de un desarrollador de C# es: • Presentar los conceptos básicos. • Enfrentar cada característica que ya conoces de C# (.NET) con las de Python. Antes de comenzar con lo importante, vamos a ver una serie de características de este lenguaje, sin abordar cual es mejor o peor. Trátalo como una herramienta más que debes tener en tu maleta. Python: • Es un lenguaje de programación de alto nivel. • Es interpretado (a veces compilado como JIT). • Es orientado a objetos, especialmente Python 3, el que vamos a ver. • Esta fuertemente tipado con semántica dinámica. • Centra la sintaxis esta enfatizada en la legibilidad. • Incluye una biblioteca muy grande como estandar. • Soporta muchos módulos y paquetes. Y lo vamos a ver con Visual Studio Code. Características principales – Alguno de los puntos de interés general

IDE Elementos necesarios (1/3) Instalar Python V3: https://www.python.org/downloads/ Configurar VS
Code – Vamos a preparar nuestro entorno

IDE Elementos necesarios (2/3) Instalar la extensión de Python para
VS Code: https://marketplace.visualstudio.com/items?itemName=ms-python.python

IDE Elementos necesarios (3/3) Creamos el programa Hello World! y
lo ejecutamos, para comprobar su correcto funcionamiento:

De C# a Python Breve traspaso de conocimiento (1/8) Suites
– Bloques de código Más información sobre el concepto Suite.

De C# a Python Breve traspaso de conocimiento (2/8) Todo
son objetos – Comparación C# vs Python Tambien podéis observar como se realizan los comentarios y los constructores en una clase. En este enlace puedes ver como se hace una interface en Python.

De C# a Python Breve traspaso de conocimiento (3/8) Propiedades
– Comparación C# vs Python Como añadimos propiedades a una clase. Obviar la utilidad del código, es para que se vea el funcionamiento.

De C# a Python Breve traspaso de conocimiento (4/8) Arrays
y bucles – Comparación C# vs Python En el siguiente enlace podrás obtener más información sobre arrays, listas, enumeraciones y sobre bucles:

De C# a Python Breve traspaso de conocimiento (5/8) Objetos
anónimos – Comparación C# vs Python

De C# a Python Breve traspaso de conocimiento(6/8) Lambda –
Comparación C# vs Python

De C# a Python Breve traspaso de conocimiento (7/8) LINQ
– Comparación C# vs Python

De C# a Python Breve traspaso de conocimiento(8/8) Paquetes –
Comparación C# vs Python Vamos a ver como se instalan los paquetes de Azure Service Bus en ambos entornos. https://pypi.org/project/azure-servicebus/ https://www.nuget.org/packages/Microsoft.Azure.ServiceBus/

Python Cheat Sheet(1/3) Switch – No existe en Python, una
de las cosas que me sorprendió Constantes INIT_YEAR = 1977 # no existen como tal Variables y Comentarios numeric = 10 # es in integer rating = 0.9 # es un float name = “Hello World” # es un string isReal = True # es un booleano Input y conversiones numeric = int(input(“Give me a number:”)) Strings Puedes usar (“) o (‘) testText = “hello” testText[1] # return 2º char testText[1:4] # return ell testText.title() # return Hello contains = “He” in testText Operaciones aritméticas +, -, * / # return float // # return int % # return remainder division ** # return exponentiation IF y operadores lógicos if has_A and has_B: #... elseif has_A or has_B: #... else: #... isReal = True isUnreal = not isReal Comparaciones a > b, a >= b, a < b, a <= b a == b # equal a != b # not equal

Python Cheat Sheet(2/3) Bucle While i = 1 while i
< 10: print(i) i += 1 # identation is a code suit Blucle For For i in range(1, 10): print(i) Listas numbers = [1, 2, 3, 4, 5] number[1] # return 2º item number[1] # return first item from the end .append(6) # add 6 to the end .insert(0,6) # add 6 in position 0 .remove(6) # remove 6 .pop() # remove las item .clear, .index(x), .reverse(), .copy() Tuplas coodinates = (1 ,1 ,1) x, y ,z = coordinates Diccionarios coordinates = { “x”: 1, “y”: 1, “z”: 1} coordinates(“x”) # return 1 Funciones def testFunction1(param): print(param) testFunction1(“Hi”) def testFunction2(param1, param2): return param1+param2 result = testFunction2(1,2) print (result)

Python Cheat Sheet(3/3) Excepciones try: result = 100/0 print (result)
except ZeroDivisionError: print(“Division error”) Clases class testClass: def __int__(self, value): self.value = value def printValue(self) print(self.x) test = testClass(10) Herencia class parent: def methodA(self): print (“MethodA) class child(parent): def methodB(self): print (“MethodA) testB = child() testB.methodA testB.methodB Modulos (fichero con codigo .py) import testModule testModule.someFunction(“Test”) from testModule import someFunction someFunction(“Test”) Paquetes (contiene uno o más modulos) form package import moduleA, moduleB moduleA.someFunction(“Test”) form Package.moduleA import someFunction someFunction(“Test”) With (gestor de contextos ≠ a namespaces de C#) from decimal import localcontext with localcontext() as ctx: ctx.prec = 2 s = calculateSomething() s = +s Pypi pip install azure-servicebus pip unistall azure-servicebus

No importa el lenguaje Complejidad ciclomática Indicadores – Medidas matemáticas
y no divagaciones filosóficas Que no exista un Switch, puede parecer algo anecdótico, pero no lo es. Creo que todo se debe, según me he documentado, a que no se ponían de acuerdo en como implementarlo. Pero más allá de este debate, existe una medida muy importante en el software: índice de mantenibilidad y complejidad ciclomática. En la siguiente imagen podéis ver la diferencia entre usarlo y no en C#. Sacar vuestras propias conclusiones.

Libros Python Existen infinidad de libros y cursos. Os voy
a recomendar 1 libro de la decena de libros que he leído y varios cursos que he podido ver en Pluralsight o Udemy. Particularmente me quedo con la opción de los libros, los cursos de videos no te permiten avanzar al ritmo que tu te marques. A partir de aquí: documentación oficial y foros como stackoverflow. Ampliar formación – Amplia conocimiento de forma ordenada

Ejemplo Modulo de Azure Debes leer primero el README.MD, donde
se muestra como crear un Azure Service Bus y obtener las keys de publicación que debes cambiar en el programa. Una vez cambiado podrás ejecutarlo y observarás que esta enviado información a la cola. Con este ejemplo, ya tienes la preparación mínima y necesaria para acometer el programa base de nuestra PoC, que veremos a continuación. pyAzureServiceBusTest – Probamos nuestro primer ejemplo en Azure https://github.com/jmfloreszazo/HandsOnIoTAzure

Ejemplo Llamada a un API(1/3) En este ejemplo vamos a
ver como llamar a un GET, obtener los datos en formato JSON y hace uso de una librería de gráficos. Lo primero que deberás hacer es crear los datos modelos que se explican a continuación. Una vez que tengas esos datos y pruebes por ti mismo los snippet de código que te dejar restdb.io, podrás ejecutar este ejemplo cambiando, obviamente, los endpoints y los Api-Key. pyApiRestCallTest – Probamos nuestro primer ejemplo en Azure https://github.com/jmfloreszazo/HandsOnIoTAzure

Ejemplo Llamada a un API(2/3) De una forma sencilla podrás
crear una base de datos on-line, tipo NoSQL que nos ayuda de forma muy fácil a crear un endpoint para los datos. Por ejemplo, para probar un GET de datos del ejemplo anterior, es sumamente útil, por que en 5 minutos lo tienes listo. 1. Crear cuenta si no la tienes. 2. Create New Database >> Usa el nombre: pyapirestcalltest. Luego te aparecerá: https://pyapirestcalltest-8082.restdb.io, El valor 8082 en tu caso será diferente. 3. Entra en la base de datos y en la parte superior derecha (en las ruedas) haces clic. Entras en el modo desarrollador. 4. Añades una nueva: Collections + (clic en el más). Crear un nuevo nombre: requests y lo guardas. 5. Entras en la tabla y vamos a llenarla de datos y campos. 6. Add Fields + >> name como texto y value como integer. https://restdb.io/ – Siempre me gusta mostrar alguna cosa más y ampliar conocimiento

Ejemplo Llamada a un API(3/3) 7. Haces clic en la
carpeta Test Data. Copia lo que ves en la imagen y genera los datos. 8. Podrás ver la información que a generado. Ahora volvemos a ejecutar el paso 3, clic en las ruedas. Desplegamos el triangulito izquierdo de la tabla Request y pulsamos en Settings. 9. Podrás ver una solapa donde poner API Docs, entras en Python y copias el código del GET. 10. Copias el código en un fichero de .py y ejecutas. 11. Cuando veas que funciona todo correctamente, podrás ir al fichero main.py, cambiar los endpoint y Api-Key para probar el ejemplo.

Sección 3 Prueba de Concepto

Respondiendo a las preguntas… Prueba de Concepto Simplemente aprender desde
la práctica y con un guión establecido, para que esta PoC (Prueba de Concepto) nos ayude de forma ordenada a adentrarnos en el mundo del IoT. Vamos a ver conceptualmente que resuelve esta aplicación de IoT: ¿Para qué? – Finalidad Yo soy muy malo reciclando, incluso poniendo etiquetas con el color en cada cubo de basura, a veces me asalta la duda si un tipo de desperdicio va a un cubo o al otro, si la botella de plástico del agua va al amarillo o al marrón… Lo siento, pero soy muy torpe. Como quiero contribuir a reciclar y no dejar un mundo peor a mi hijo, además que mi pareja tiene muy asumido esto del reciclado y ante mi torpeza al respecto. He decidido hacer una aplicación IoT que, al mostrar un tipo de desperdicio, me indique con un color a que cubo de basura va. Como también me interesa saber cuando tengo que llevar la basura al contenedor vamos a avisar cuando llegue a un peso especifico cada cubo (aquellos que no emiten metano). Y además el de residuos orgánicos llevará un indicador metano que, al alcanzar un nivel, nos avisará para bajar la basura, como suele estar relacionado con la temperatura, por tanto, también mediremos este valor. Por tanto, vamos a construir una PoC de un dispositivo IoT que estará “empotrado al cubo de basura”. Y con esto cumplimos la premisa principal de los que es IoT para mi, hace unas páginas os di la definición.

Respondiendo a las preguntas… Prueba de Concepto A continuación, os
muestro el material necesario para tener un dispositivo que a la vez nos sirva de modo clásico y de modo edge. ¿Con qué? – Material necesario para nuestra PoC Hardware: 1 Raspberry Pi 4 8GB Model B 1 Carcasa de aluminio + masilla disipadora para los chips 1 Booster Header 1 Raspberry Pi Camera Module 2 + cable alargador de 50cm 1 Enviro o Enviro + de Pimoroni 1 Tarjeta de memoria SD de 64 GB 1 Altavoz Jack 3.5 Y con un coste aproximado de: 125,00€ Software: • Raspberry Pi OS, con Python instalado • Visual Studio Code • Libarías Enviro +, sigue los pasos del tutorial • Cuenta de Azure, no lo incluyo en el coste Si estas pensado en adquirir el hardware que aquí menciono, te sugiero que esperes a que publique la Sección 4. Puede que varíe el material presentado para la PoC de la Sección 3 por algun tipo de incompatibilidad.

Raspberry Pi + Python + IDE Elementos necesarios (1/2) 1.
Lo primero de todo es generar una imagen del SO de Raspberry Pi OS e instalarlo como se indica. 2. En segundo lugar, conectar el hardware periférico: la cámara y Enviro +. 3. En tercer lugar y no es necesario, configurar el acceso via Real VNC la Raspberry Pi. 4. Actualizar el SO de la Raspberry Pi: sudo apt-get update && sudo apt-get upgrade 5. Reiniciamos la Raspberry Pi: sudo reboot 6. Actualizar el firmware de la Raspberry Pi: 1) Ejecutamos: sudo apt-get install rpi-eeprom-update 2) Ejecutamos: sudo reboot. 3) Y: sudo rpi-eeprom-update. Si tenemos algo que instalar: sudo rpi-eeprom-update –a 4) Reiniciamos de nuevo y ya esta listo. Revisa con sudo rpi-eeprom-update si deseas ver el estado. 7. Revisamos que version de Python 3 tenemos, python3 -–version. Si no lo tienes, sigue estos pasos para instalar Python en Linux. Necesitamos la versión 3.5 o superior. En mi caso tengo la 3.7. Configurar Raspberry Pi – Vamos a preparar nuestro entorno

Raspberry Pi + Python + IDE Elementos necesarios (2/2) 8.
Instalamos Enviro + desde GitHub: curl -sSL https://get.pimoroni.com/enviroplus | bash, sigue las instrucciones. 9. Probamos un ejemplo: 10. Ahora vamos con la cámara siguiendo las instrucciones. Y ejecuta una captura de imagen, revisa que este correcta. 11. Le toca el turno a VS Code. Y revisamos el fichero combined.py en VS Code, si ves datos en el LCD, ya tienes todo correctamente instalado en tu Raspberry. Si has podido llegar sin problemas al podido ejecutar el punto 10 y 11 sin problemas, ya estas listo para continuar.

Ejecución de Script automáticamente Un poco más sobre…(1/2) Si conoces
Linux, obviamente conoces el comando anterior. Si no, apúntatelo por que es quien nos ayuda. En cualquier caso, no venia a hablar del comando man, si no de lo que debes hacer para que un script se ejecute al iniciar Linux: 1. Escribe en un terminal: crontab –e 2. Selecciona el editor nano. 3. Desplázate hasta el final del archivo con las flechas. 4. Añade la siguiente linea: @reboot sudo python3 /home/test/examples.py & 5. Donde el Path y fichero Python es el que tu elijas. 6. Presiona control-x, después y finalmente enter, para salir y guardar el nuevo crontab. 7. Reinicia con: sudo shutdown –h now 8. Y observa si se ejecuta el fichero Python tal y como deseas. Linux – man [comando]

Los sensores y la cámara no funcionan Un poco más
sobre… (2/2) Si estas teniendo problemas para acceder a la cámara o los sensores, te recomiendo que le des una vuelta a esta parte. Pongo una captura de mi configuración por si te puede ayudar. Preferencias >> Configuración de la Raspberry Pi: GPIO – Posiblemente tengas algo que falta por habilitar

Caso de uso Arquitectura IoT Estandar (1/5) Veamos a grandes
rasgos el funcionamiento: Sin edge – Un modelo que no tiene por qué estar obsoleto. Tambien llamado clásico Reciclado de vidrio Ciudadano responsable Botella de vidrio

Caso de uso Arquitectura IoT Estandar (2/5) ¿Qué a ocurrido?
• Una persona responsable con el medioambiente quiere reciclar, pero le cuesta mucho discernir en que contenedor va el desperdicio. • Al reconocer via Deep Learning usando la cámara + procesador + aplicación backend en el cloud el objeto a tirar, automáticamente se abre la tapa del contenedor de basura. ¿Cómo lo vamos a simplificar nosotros? Como es muy complejo tener un hardware que pueda levantar una tapa o usar software de Deep Learning. Vamos a evita levantar la tapa mostrando un color en el display del Enviro + y en vez de usar Deep Learning, vamos a usar ML donde mostramos lo que queremos tirar y reconocerá el desperdicio. Para simplificar el modelo de ML, vamos a usar botella de cristal con tapón, para que nos advierta que debemos separar el metal y una botella de plástico. Es decir, tendremos 4 objetos: tapa de metal de la botella de cristal, botella de cristal, botella de plástico y tapón de plástico correspondiente de la botella de plástico. Algo más sencillo Por extensión esta herramienta ayuda a personas con una discapacidad visual si ponemos un micro, intelectual usando la pantalla con los colores, a alguien que no quiere reciclar impidiéndole poner el residuo donde quiera, etc.

Caso de uso Arquitectura IoT Estandar (3/5) Reciclado organico Ciudadano
responsable Restos de carne

Caso de uso Arquitectura IoT Estandar (4/5) ¿Qué a ocurrido?
• En esta ocasión queremos deshacernos de los restos de una comida, son orgánicos, un resto de carne, pescado una cascara de plátano. • Al reconocer via Deep Learning usando la cámara + procesador + aplicación backend en el cloud el objeto a tirar, automáticamente se abre la tapa del contenedor de basura. • Si el contenedor marrón que tiene sensores de olor (para detecta gas metano), temperatura y peso, nos alertará cuando debemos tirar la basura. Esta alerta puede ir directamente a un display en el cubo o bien una alerta a un dispositivo móvil (lo cual es más lógico). ¿Cómo lo vamos a simplificar nosotros? Siguiendo el ejemplo anterior, solamente vamos a usar ML para saber donde vamos a tirar una cascara de plátano, es lo que vamos a mirar a entrenar. Sin embargo, el cubo de basura tendrá dos sensores: temperatura y sensor de metano (Enviro + puede medir también amoniaco, etanol, dióxido de nitrógeno, monóxido de carbono, propano e iso-butano, gracias al chip MiCS-6814). La báscula la dejaremos de lado, aunque en Seul es junto a la temperatura el sensor que tienen los contenedores. En este caso esos sensores nos servirán en base a unas medidas que tiremos la basura al contenedor de la calle. Ya se que nadie mantendría 24h en su casa residuos orgánicos, es solo una vuelta de tuerca más a nuestra PoC y que entre en juego algo más.

Caso de uso Arquitectura Estandar (5/5) Diagrama de secuencia –
No es que sea exactamente UML pero algo se parece El mundo del IoT es un mundo prácticamente asíncrono. CaptureImage::OnPrem classififyImage::OnCloud GetClassification GetAlarms alarmGeneration::OnCloud telemetryAggregator::OnCloud telemetryViewer::OnCloud GetTempPerSecond GetAlarm GetAlarm GetMethanePerSecond GetImagePerSecond GetClassification GetAlarm GetClassification GetTelemetry

Caso de uso Arquitectura IoT Edge (1/5) Veamos a grandes
rasgos el funcionamiento: Con Edge – Un modelo más actual y que necesita un hardware más potente y caro Reciclado de vidrio Ciudadano responsable Botella de vidrio

Caso de uso Arquitectura IoT Edge (2/5) ¿Qué a ocurrido?
• Una persona responsable con el medioambiente quiere reciclar, pero le cuesta mucho discernir en que contenedor va el desperdicio. • Al reconocer via Deep Learning usando la cámara + procesador el objeto a tirar, automáticamente se abre la tapa del contenedor de basura. La información no viaja al Cloud, solamente podemos enviar telemetría y datos procesado, por ejemplo, podemos confirmar que realmente es lo que queremos tirar y donde, de esa forma retroalimentamos al ML que tengamos en el Modulo ML de Edge. ¿Cómo lo vamos a simplificar nosotros? El proceso es el mismo que tenemos en el sistema estandar, pero esta vez vamos a usar Edge. Con todo lo que conlleva: desplegar una nueva version del modulo, configurar la Raspberry Pi como dispositivo Edge, encapsular el codigo para que este en el edge y por tanto mantener solo la telemetría en el backend (por ejemplo, contar cuantas veces se tira vidrio o plástico), etc. No es poco trabajo. No existe retardo en la comunicación, ya que instantáneamente podemos tener la información en el display. No viaja la información del sensor a la Rapsberry Pi y luego al backend del Cloud. Directamente la Raspberry Pi tiene inteligencia de proceso capad de dar el resultado al instante.

Caso de uso Arquitectura IoT Edge (3/5) Reciclado organico Ciudadano
responsable Restos de carne

Salidas Arquitectura IoT Edge & Estandar Ahora que ya conoces
como va más o menos la prueba de conceto a muy alto nivel. Mostramos como vamos a usar a grandes rasgos el hardware que hemos comprado: Output – Salida común en ambas arquitecturas 1. Pantalla LCD. 2. Sensor de temperatura. 3. Salida audio Jack 3.5 mm 4. Altavoz. 5. Sensor de gas.

Caso de uso Arquitectura IoT Edge (4/5) ¿Qué a ocurrido?
• En esta ocasión queremos deshacernos de los restos de una comida, son orgánicos, un resto de carne, pescado una cascara de plátano. • Al reconocer via Deep Learning usando la cámara + procesador el objeto a tirar, automáticamente se abre la tapa del contenedor de basura. No hemos pasado por el Cloud. Al Cloud le enviamos telemetría. • Si el contenedor marrón que tiene sensores de olor (para detecta gas metano), temperatura y peso, nos alertará cuando debemos tirar la basura. Esta alerta puede ir directamente a un display en el cubo o bien una alerta a un dispositivo móvil (lo cual es más lógico), todo ello sin pasar por un backend en Cloud. ¿Cómo lo vamos a simplificar nosotros? Es exactamente el mismo ejemplo, pero en esta ocasión, como la anterior, nos tocará generar un Modulo de Edge para cada sensor que se comunica con un Modulo Edge analizador. A veces a esto se le conoce como Edge Analytics. Como veis vamos a reutilizar mucho codigo, pero es en los conceptos de IoT de Azure, donde radica parte de la diferencia fundamental entre las PoC.

Caso de uso Arquitectura Edge (5/5) Diagrama de secuencia –
No es que sea exactamente UML pero se parece CaptureImage::OnPrem classififyImage::OnPrem GetClassification alarmGeneration::OnPrem GetAlarms telemetryAggregator::OnCloud GetNewClassificationModule GetNewAlarmModule telemetryViewer::OnCloud GetImagePerSecond GetTempPerSecond GetMethanePerSecond GetClassification SetClassification GetAlarm GetAlarm SetTelemetry GetTelemetry Insisto, el mundo del IoT es un mundo prácticamente asíncrono. Los retrasos pueden afectar en una decisión importante. Pero gracias al Edge, podemos ser más reactivos.

Tratarlo como aplicación de logística Otras aproximaciones(1/2) El funcionamiento grosso
modo: Trazabilidad – Salvando las distancias y via códigos de barra Reciclado de vidrio Ciudadano responsable Botella de vidrio

¿Qué a ocurrido? • Una persona responsable con el medioambiente
quiere reciclar, pero le cuesta mucho discernir en que contenedor va el desperdicio. • Al reconocer via lector de codigo de barras + petición al servicio (ya sea clásico o edge), el objeto a tirar, automáticamente se abre la tapa del contenedor de basura. ¿Qué problemas veo a esto? En la actualidad existen contenedores en la calle que son capaces de leer el codigo de barras y abrir la ranura para que puedas poner el objeto adecuadamente. Pero esto por desgracia tiene un gran fallo, ya que muchas cadenas tienen productos que pueden separar (es más te lo piden) lo que es el plástico del papel, para que lo realices en casa. ¿Qué ocurre cuando vas a tirar el plástico totalmente desnudo? o ¿si eres como yo que compactas los briks de leche?. Pues sí, esto están producción y evidentemente nadie lo usa… por desgracia no es un prototipo esta implantado en España, como no podía ser en otro sitio. Logicamente esta aproximación admite modo clásico o edge. Con inminente implantación del 5G esto será mucho más práctico, pero en la actualidad, en el Edge si decides tener una base de datos de códigos de barra deberías acotarla por zona de comercios y que es lo que ofrecen, si no, la capacidad de computo afecta a tu dispositivo Edge y la actualización sería un gran problema por el tamaño de la base de datos. Tratarlo como aplicación de logística Otras aproximaciones(2/3)

¿Qué ocurre con los desechos orgánicos? • Magnifica pregunta para
un sistema en casa basado en un lector de codigo de barras. Para alguien con una discapacidad, ¿cómo lo tratas?, para alguien que no sabe reciclar, ¿qué haces?. Como veis sencillamente la IA en el área de la visión es un ganador en toda regla. Trazabilidad • Por si acaso, esto que veis a la derecha si que es trazabilidad. Ahora podéis entender que básicamente la idea anterior se basa un caso de uso de la trazabilidad y por tanto logística. Tras este inciso, del por qué una cosa y no la otra, no demos más vueltas a esto, ya que se trata de una PoC y lo que se decida a nivel funcional dependerá mucho de muchas cosas. Tratarlo como aplicación de logística Otras aproximaciones(3/3) Ganadería Factoria Logística Retail Trazabilidad del ciclo de vida de la ternera

La base ya la tienes, ahora toca ponerlo en práctica
Manos a la obra … 3, 2, 1, Launch – Nos hemos estado preparando. Ya es hora del lanzamiento. Para resumir: • Hemos visto la historia de IoT y su potencial. • Hemos aprendido algo de Python para poder sacar adelante la PoC. • Y hemos visto en que consistirá nuestra PoC de IoT. Ahora es el momento de entrar en el mundo de Azure, donde veremos las herramientas que tenemos a disposición para poder poner en práctica este proyecto. Además de las herramientas, vamos la arquitectura de la aplicaicón estandar o clásica, que no se os olvide que ambos sinónimos se usan constantemente y la arquitectura edge.

Proyecto en Stand By Tras la publicación de la versión
1.0.0, continuaré en: https://github.com/jmfloreszazo/HandsOnIoTAzure/iotbookproject No compre los materiales. Con toda la teoría y prácticas que muestro en los próximo capítulos tendrá más que de sobra para conocer IoT en Azure en profundidad. El proyecto es una puesta en práctica a todos los conocimientos adquiridos aquí con un proyecto real.

Sección 4 IoT con Azure

Azure IoT ¿Qué vamos a ver?(1/2) Existe dos opciones bien
diferenciadas en Azure: Servicios de plataforma, lo que vendría a ser un PaaS Son aquellos que proporcionan los recursos que permiten construir soluciones personalizadas a escenarios IoT complejos. Esta solución es ideal para aquellos que quieren tener: control total, administración completa de los servicios subyacentes y ajustar los precios. Por ejemplo, son Azure IoT Hub, Azure IoT Edge y Azure Digital Twins. Plataforma de aplicaciones administradas, logicamente, un modelo SaaS Permiten crear aplicaciones rápidamente y totalmente administrada. Es ideal para empresas que no quieren dedicar muchos recursos a la arquitectura y sistemas. Prefieren que la administración sea sencilla gracias a las herramientas que me da la plataforma administrada, que el control sea el mínimo sin siquiera saber la tecnología subyacente, y que los precios no me den un susto como puede ser en un servicio de plataforma, donde te obligas a tener un control fino de los recursos y por tanto los precios. En este caso existe Azure IoT Central y unas plantillas de escenarios comunes (IoT Solution Accelerator). Alrededor de estos grandes recursos, Azure nos ofrece otros recursos simbióticos del ecosistema, como son: Time Series Insight, Azure Sphere, Windows IoT Core, Azure RTOS y .Net NanoFramework. Algunos los veremos en la sección 6. Plataformas – Dos tipos de orientaciones a tu alcance

Azure IoT ¿Qué vamos a ver?(2/2) Azure IoT admite la
comunicación bidireccional entre dispositivos y la nube; es decir, comunicación de dispositivo a nube cuando un dispositivo envia telemetría de datos a la nube y de nube a dispositivo cuando la nueve envia acciones y comandos al dispositivo: Por eso en la Sección 3 el diagrama de secuencia no era un diagrama UML al uso, ya que principalmente debe cumplirse el funcionamiento del anterior diagrama. Azure IoT Solution Accelerator Azure IoT Hub Azure IoT Central Telemetría Acciones/Comandos

Teoría y conceptos principales Azure IoT Hub (1/37) Arquitectura –
Primer contacto con Azure Conectividad Dispositivo Dispositivo IP Conectividad Dispositivo Dispositivo IP Conectividad Dispositivo Dispositivo accesible IP Librería Dispositivo IoT Dispositivo IP Conectividad Dispositivo Dispositivo IP Conectividad Dispositivo Dispositivo IoT Existente Librería Dispositivo IoT Dispositivo IP Conectividad Dispositivo Dispositivo IP Conectividad Dispositivo Dispositivo Baja-Potencia Azure IoT Hub Análisis y procesado de datos Protocolo IoT Gateway Librería Dispositivo IoT IoT Gateway en campo IoT Edge AMQP MQTT o presonalizado AMQP, MQTT o HTTPS AMQP Backend Solución IoT Ingesta basada en eventos: Device To Cloud (D2C) Mensaje confiable: Cloud To Device (C2D) Autenticación y conectividad segura por dispositivo Local

Teoría y conceptos principales Azure IoT Hub (2/37) Es un
servicio totalmente administrado que permite el uso bidireccional confiable y seguro de las comunicaciones entre una gran cantidad de dispositivos IoT y una solución Backend. El anterior dibujo es una arquitectura os ayudará a resolver las múltiples preguntas que tuvierais anteriormente en las Secciones 1 y 2. Tener en cuenta que los objetos en lineas discontinua son componentes opcionales y aquellos que tienen un color rojo sólido, son los componentes de la solución IoT. De otro modo, IoT Hub, es el servicio principal de Azure para las soluciones IoT e IoT Edge. Soporta mensajes originados por dispositivos a la nube (D2C) como la telemétrica y mensaje de la nube destinado a un dispositivo (C2D), mensajes de control y comando. Cuando construimos y diseñamos soluciones IoT, la ingesta de mensajes en la nube es sencilla en comparación con el envío de mensajes desde la nube al dispositivo. Los mensajes originados en el dispositivo pueden ser ciento de miles de millones, escalar los servicios para manejar millones de mensajes es un patrón conocido y resuelto que no debe preocuparte, para esto esta IoT Hub que lo hace muy bien. Sin embargo, lo que debe preocuparte son cosa en las que tus tomas la decisión arquitectónica y que en mayor o menor medida IoT Hub te deja herramientas para ir por un lado u otro: Azure IoT Hub

Teoría y conceptos principales Azure IoT Hub (3/37) • ¿Cómo
verificamos la identidad (confianza) del servicio que envía los mensajes al dispositivo? • ¿Cómo se envian los mensajes al dispositivo si éste está desconectado? • Si el dispositivo no esta nunca conectado, ¿debe escuchar continuamente los mensajes entrantes de la nube? • ¿Cómo evitamos que los hackers intenten saturar nuestros dispositivos con mensajes falsificados? • ¿Cómo enviamos las actualizaciones de configuración al dispositivo? • ¿Cómo se maneja un mensaje o un comando debe ser ejecutado en el dispositivo? Azure IoT Hub ayudará a resolver muchos de estos problemas, proporcionará herramientas para ello, pero deberás ser tu coger una u otra opción dependiendo de tu arquitectura. Por ejemplo, proporciona una forma segura para que los dispositivos se comuniquen via D2C y C2D. Además, nos provee de un conjunto de APIs REST que permite a los usuarios gestionar, mantener y supervisar dispositivos. Estas APIs se pueden usar para alimentar Dashboard personalizados o de control de operaciones. Tambien gestiona fácilmente las claves de seguridad de los dispositivos. Una vez que las credenciales del dispositivo se han verificado, los mensajes del dispositivo comienzan a fluir a la instancia de IoT Hub, estos mensajes podrán dirigirse a recurso tales como: BLOB, Tables, Data Lakes, colas, Service bus, Event Hub y Stream Analytics. Todas estas funcionalidades son validas tanto para un dispositivo IoT clásico (Device) como para un dispositivo IoT Edge. Podrás ver que en el Blade de Azure IoT Hub existe una separación entre ambos.

Teoría y conceptos principales Azure IoT Hub (4/37) Para poder
ver esto, hemos tenido que crear un Azure IoT Hub. Soy partidario de usar el Azure CLI, todo esto lo puedes hacer de forma visual, pero prefiero que tengáis un comando (la razón la podéis leer en esta publicación que he realizado). Veamos que pasos hemos seguido, usa un prefijo único para tus recursos: 1. Lanzar el Cloud Shell, con un enviroment tipo Bash. 2. Añade la extensión IoT a tu Azure CLI: az extension add --name azure-iot 3. Ejecuta: az extension add --name azure-iot 4. Crea un grupo de recursos: az group create --name [prefix]IoTRG --location westeurope 5. Crea el recurso gratuito (solo puedes tener 1 subscription): az iot hub create --resource-group [prefix]IoTRG --name [prefix]IotHub --location westeurope --sku F1 --partition-count 2

Teoría y conceptos principales Azure IoT Hub (5/37) Toda la
funcionalidad específica de Device e IoT Edge esta contenida bajo su propia entrada de gestión en el portal. A continuación, puedes ver una captura de la gestión de un Device y la de IoT Edge:

Teoría y conceptos principales Azure IoT Hub (6/37) En ambas
secciones tenemos las siguientes opciones: 1. Añadir un dispositivo. Esta opción crear un dispositivo virtual en el IoT Hub, crea las claves de seguridad asociadas y la identidad del dispositivo necesaria para configurar y asegurar el dispositivo. 2. Consultar los gemelos (Twins) del dispositivo. Esto permite a los administradores filtrar la lista de dispositivos para ver el subconjunto requerido. 3. Lista de devices o edges. Aquí se muestra un listado de dispositivo basados en los criterios de selección. Si no se especifica ninguna consulta, se muestran todos. 4. Gestión de despliegue de Edge, no existe esta opción para devices. Tal y como podrás apreciar en la anterior imagen. Se usa para crear y gestionar despliegues. Los despliegues se utilizan para gestionar versiones de modulos que estarán disponibles para un subconjunto de dispositivos. Lo veremos más adelante. Esta opción no existe en device.

Teoría y conceptos principales Azure IoT Hub (7/37) Si seleccionas
un dispositivo de la lista y entra en el haciendo clic, verás una página de administración. Diferente dependiendo del recurso:

Teoría y conceptos principales Azure IoT Hub (8/37) La imagen
anterior y sobre la que tratan las siguientes líneas, es de un Device. En la barra superior, existen diversas opciones para un dispositivo, incluyendo la opción para regenerar claves o revisar el dispositivo gemelo. Siendo las más importantes para un device, la opción de enviar un mensaje o invocar a un método. Un mensaje simplemente es añadir un contenido a un cuerpo de mensaje (un JSON o XML, por ejemplo) o enviar unas propiedades via par Key-Value del cual no tenemos respuesta. Sin embargo, invocar a un método se trata de una interacción solicitud-respuesta con un dispositivo, es similar a una llamada HTTP. El uso de métodos es útil cuando se trata de un enfoque en el que el escenario implica una acción inmediata en función de si el dispositivo pudo o no responder. La siguiente imagen trata sobre un IoT Edge. Como podrás observar ciertas entradas del menú de la barra superior la comparte con un dispositivo Device, aunque en diversos casos tendrá una diferencia, mínima, pero lo habrá.

Teoría y conceptos principales Azure IoT Hub (9/37)

Teoría y conceptos principales Azure IoT Hub (10/37) La acción
más importante sobre un dispositivo IoT Edge es la capacidad que tiene de asignar módulos a un dispositivo. Los modulos (que lo explicaré más adelante) contienen lógica real para el dispositivo. Así que, en efecto, cuando estableces y configuras modulos a un dispositivo, estas asignando a ese dispositivo un rol específico. En nuestro ejemplo tendremos un módulo que se encargará de reconocer la imagen y dar un resultado de inmediato. Esta pieza o demás piezas que conformen la solución en el edge, definen el papel que debe desempeñar el dispositivo.

Teoría y conceptos principales Azure IoT Hub (11/37) En la
gestion de modulos, existen dos secciones: Modules Donde se introducen las credenciales para acceder al registro del contenedor. Aquí ponemos la información de configuración, llamada gemelo (Twin), para el módulo relacionado. Se puede configurar más de un registro de contenedores o usar modulos públicos desde un Marketplace (botón + Add). Entra en Marketplace y busca Simulated Temperature Sensor y lo añades. Para que puedas ver la telemetría que genera:

Teoría y conceptos principales Azure IoT Hub (12/37) Routes Aunque
lo veremos más adelante, las rutas sirven para la comunicación de los modulos de un dispositivo IoT Edge.

Teoría y conceptos principales Azure IoT Hub (13/37) Estoy seguro
de que el concepto contenedor lo conoces, es algo que lleva unos años arrasando en el mercado. Aunque los conceptos básicos que sustentan un modelo de contenedores (virtualización y aislamiento) existen desde principios del año 2000, es en estos últimos 5 años (estamos en 2021) cuando han sufrido un punto de inflexión, ya que es la corriente principal en los desarrollos, en resumen, están de moda. Ahora mismo en arquitectura, en mi caso, es habitual que tenga que justificar por qué NO necesitas contenedores en lugar de justificar por qué debes usarlos. No son piezas exclusivas de ecosistema IoT, pero sí que tienen una estrecha relación entre los módulos de un IoT Device y como funcionan estos mismo. Lo que comenzó como un simple paso evolutivo de la virtualización se ha convertido en la forma de facto de garantizar ejecuciones consistentes de un runtime. Los contenedores son muy flexibles, como te demostraré ahora. Uno de los muchos beneficios que tiene un contenedor es que puedes distribuir pequeños entornos de ejecución sin tener que enviar la máquina virtual completa (VM). Las imágenes de una VM pueden pesar 50GB o más, mientras que un contenedor en contadas ocasiones no supera el 1,5GB. Por tanto, no debe sorprenderte que sea el núcleo de ejecución de un IoT Edge (en estos casos apenas superan los 150MB). Adoptar un enfoque basado en contenedores nos obliga a tener en cuenta ciertos componentes arquitectónicos. Si no fuera por IoT Hub tendríamos que gestionar muchas cosas y se convertiría en algo extremadamente complejo. Azure Containers Registry

Teoría y conceptos principales Azure IoT Hub (14/37) En primer
lugar, se necesita un runtime para interactuar y gestionar los contenedores en la máquina de destino. Docker es el más conocido. Sin embargo, para un dispositivo IoT Edge es necesario usar otro llamado Moby, que usa la misma tecnología subyacente que Docker, ya que incluso permite la ejecución de una imagen Docker en un dispositivo IoT Edge, claro esta: siempre que el dispositivo tenga la potencia de CPU, RAM y almacenamiento necesario para correr la imagen. En segundo lugar, se necesitan contenedores reales. En el mundo de IoT Edge, los contenedores encapsulan varios segmentos de funcionalidad que están desacoplados (llamado Modulos de ahora en adelante) y se comunican a través de un bus de mensaje (alojados en un contenedor llamado edgeHub). Dado que cada contenedor esta desacoplado y no conoce los otros contenedores que ese ejecutan en el edge, permite una gran flexibilidad en como puedo configurar los contenedores y como han de interactuar entre sí. A medida que la solución IoT comienzan a crecer y por tanto los contenedores edge disponibles, nos permite crear soluciones personalizadas mucho más rápido, es decir que son piezas que podemos ir engranando para conseguir un producto mas grande u otro completamente diferente. Existe una diferencia muy grande entre contenedor y una imagen. Como ejemplo, podríamos extrapolar la diferencia entre una clase y una instancia del mundo de la programación orientada a objetos. La imagen del contenedor define como se construyen los contenedores (la clase) y un contenedor es una instancia de una definición de la imagen.

Teoría y conceptos principales Azure IoT Hub (15/37) Y, en
tercer lugar, un componente necesario cuando se trabaja con contenedores es el registro de contenedores, en nuestro caso Azure Container Registry que viene a ser lo mismo que Docker Hub. Podríamos decir que se trata de una estantería donde se recuperan las imágenes de contenedores (libros). A medida que construyes imágenes estas deben ser almacenadas en algun lugar para que sean accesibles. El funcionamiento es el siguiente: el runtime dará instrucciones sobre que imágenes se deben ejecutar (incluyendo la version de la imagen) y luego obtiene una copia local de esa imagen (si no existiera) e inicia el contenedor basado en la imagen (si aun no existe). Para habilitar y automatizar estas interacciones entre el registro y el runtime, debe existir un conjunto bien definido de APIs que nos permitan interactuar con los contenedores. Y esto es lo que proporciona un registro de contendores, tal y como se muestra en la siguiente imagen: Registro de Contenedores Runtime Agente de Runtime Contenedor Imagen Contenedor Imagen

Teoría y conceptos principales Azure IoT Hub (16/37) Uno de
los términos que más veremos será Module (módulos). Un modulo es como una imagen de un contenedor, pero un módulo edge es más que una imagen de un contenedor. Un modulo edge incluye una identidad de modulo y la información de configuración del módulo, que también se almacena como información gemela. La identidad de un modulo es una forma de rastrear la instancia específica de un módulo. Imagina que necesitas desplegar el mismo modulo más de una vez en un determinado dispositivo IoT Edge. La identidad el módulo se utiliza para rastrear las distintas instancias. Ese concepto se usa principalmente en el enrutamiento de mensajes, que se verá más adelante. Otro concepto específico de un módulo Edge es un modulo gemelo, que lo explicaré más adelante, por ahora debes saber que además del dispositivo gemelo, cada modulo de una solución IoT Edge tiene su propio gemelo de módulo. Edge Agent y Edge Hub Antes hemos hablado de contenedores y me referí en diversas ocasiones al runtime (tiempo de ejecución) del contenedor (ver imagen anterior). Y también, a propositivo, os deje sin explicar que era el agente de tiempo de ejecución, agente de runtime. Ambos conceptos se relacionan en tiempo de ejecución en el edge gracias a dos modulos separados y que suministra la infraestructura de Azure IoT Edge. Estos son los modulos edgeAgent y edgeHub. Module

Teoría y conceptos principales Azure IoT Hub (17/37) El módulo
edgeAgent es responsable de recuperar las imágenes del modulo especificadas desde el registro de contenedores, iniciar el módulo y monitorizarlo. Si uno de los módulos se detiene por la razón que sea, este agente lo reiniciará. Si el módulo se reinicia continuamente, tiene errores o se bloquea, usará un enfoque de retroceso exponencial (reintentos) para que los recursos no se consuman constantemente en ese dispositivo edge. Esto es útil cuando se utiliza un dispositivo de baja potencia que puede ser fácilmente desbordado por picos de CPU. Otra de las tareas que realiza edgeAgent es informar del estado del modulo al IoT Hub. Estos mensajes de estado o heartbeats, se utilizan para informar del ultimo estado conocido. Los códigos de estado son: • 200: OK • 400: La configuración de despliegue es incorrecta. • 406: El disipativo edge esta offline y no esta emitiendo informes. • 412: El esquema de configuración de la version desplegada es incorrecto. • 417: El dispositivo no tiene establecida la configuración. • 500: Error de runtime en el dispositivo.

Teoría y conceptos principales Azure IoT Hub (18/37) El módulo
edgeAgent es responsable de recuperar las imágenes del modulo especificadas desde el registro de contenedores, iniciar el módulo y monitorizarlo. Si uno de los módulos se detiene por la razón que sea, este agente lo reiniciará. Si el módulo se reinicia continuamente, tiene errores o se bloquea, usará un enfoque de retroceso exponencial (reintentos) para que los recursos no se consuman constantemente en ese dispositivo edge. Esto es útil cuando se utiliza un dispositivo de baja potencia que puede ser fácilmente desbordado por picos de CPU. Otra de las tareas que realiza edgeAgent es informar del estado del modulo al IoT Hub. Estos mensajes de estado o heartbeats, se utilizan para informar del ultimo estado conocido. Los códigos de estado son: • 200: OK • 400: La configuración de despliegue es incorrecta. • 406: El disipativo edge esta offline y no esta emitiendo informes. • 412: El esquema de configuración de la version desplegada es incorrecto. • 417: El dispositivo no tiene establecida la configuración. • 500: Error de runtime en el dispositivo.

Teoría y conceptos principales Azure IoT Hub (19/37) Para resumir,
edgeAgent, aunque no es lo único que hace, sería la pieza que gestiona los módulos. El modulo edgeHub se encarga principalmente de la mensajería entre los módulos del dispositivo edge y entre el dispositivo edge e IoT Hub. Esto incluye mensajes de intercambio D2C y C2D. Ya es de sobra conocido que un IoT Edge se basa en módulos. Esto difiere de los IoT clásicos. Mientras que en un IoT clásico, el dispositivo se conecta directamente a un endpoint IoT Hub utilizando un agente de dispositivo, y cualquier mensaje que genere y transmita solo se envía al IoT Hub, un escenario Edge, el código que necesita conectarse al IoT Hub no solo se ejecuta dentro de un contenedor, si no que está aislado de IoT Hub durante el runtime del Edge. Para simplificar esto que puede ser tan complejo y que además debe ser consistente, edgeHub expone un API que es similar al de IoT Hub. En realidad, sirve como un Proxy de IoT Hub para los dispositivos edge. Como proxy, expone los endpoints de los protocolos que soporta IoT Hub, que son MQTTT y AMQP, pero no HTTP. Tenga en cuenta que lo que ves en estas pantallas puede tener un retardo de segundos a minutos. Que también los tiempos se ven afectados por reinicios, etc. Lo que debe quedarte claro es no es real-time lo que ves en esa sección de IoT Edge.

Teoría y conceptos principales Azure IoT Hub (20/37) Otra responsabilidad
de edgeHub es autenticar el dispositivo con IoT Hub. IoT Hub solo permite conexiones seguras desde dispositivos IoT Devices e IoT Edge. Cuando un dispositivo se conecta por primera vez, IoT Hub, debe autenticase utilizando la información de seguridad que coincida con el dispositivo virtual que ya existe en IoT Hub. Una vez establecida la conexión inicial, la información de seguridad se almacena en caché en el dispositivo edge y el IoT Hub no requerirá autenticación para futuros intentos de conexión. Todas las solicitudes e intercambios de autenticación son transparentes para ti. Simplemente se emite una solicitud de conexión desde el código del módulo (que parece casi idéntica a la solicitud de conexión de un dispositivo clásico) y el módulo edgeHub se encargará de la intermediación de ese intercambio. Otra responsabilidad principal de edgeHub es la intermediación de la mensajería intra-módulo. Cuando se crea y se despliega un módulo, son por diseño independientes y aislados de cualquier otro módulo. Si no lo fuera, no podrían ser contenedores desplegados de forma independiente (ya te veo venir con los microservicios, salvando las distancias sí). Este aislamiento conlleva un reto: ¿cómo se comunican los módulos entre sí?, ¿cómo puedo consumir mensajes de modulos que no tengo visibilidad? y ¿cómo puedo enviar mis mensajes a otros módulos que no tienen visibilidad con mi módulo? La respuesta es usando un bus de mensajes.

Teoría y conceptos principales Azure IoT Hub (21/37) El patrón
de bus de mensajes existe desde hace mucho tiempo y simplemente proporciona una forma para que dos entidades que no se conocen puedan comunicarse. Esto se hace mediante abstracciones. Una de las piedras angulares del patrón es la abstracción de la dirección “enviar a” o “recibir de”. En arquitecturas orientadas a mensajes, los editores de mensajes tienen que publicar un mensaje en una dirección o una bandeja de salida. Cuando se utilizan colas de mensajes la dirección es la ubicación de la cola. Cuando se usa HTTP, la dirección es la URL. En ambos casos, hay un acuerdo entre el emisor y el consumidor. Sin un acuerdo del canal es imposible la comunicación. Publicador del mensaje Consumidor del mensaje Bus de mensajería No se conocen Dirección Enviar a Dirección Recibir de Dirección

Teoría y conceptos principales Azure IoT Hub (22/37) Disculparme si
ya lo conoces, pero quiero que sea una explicación para todos los públicos. El diagrama anterior, el editor envia un mensaje a la dirección llamada “dirección 1”. El editor no sabe quien lo consumirá (si es que lo consume alguien). Y el receptor, de haberlo, leerá de la “dirección 1”. En ningun momento del proceso ni el emisor y receptor se han llegado a conocer. Este patrón es el que se implementa en edgeHub. Proporciona un API para que los módulos puedan enviar y recibir mensajes de una dirección genérica. Los módulos no necesitan saber cual es el mecanismo de persistencia subyacente o quienes es el módulo o módulos desencadenantes de la cadena de comunicación. Gracias a esta abstracción, los módulos pueden realizar distintas combinaciones de workflow. Y, para terminar, otra ventaja de este patrón es la forma en la que se ocultan los detalles de entrega de mensajes. Un módulo publica a “dirección 1”, pero no existe ningun consumidor o el consumidor registrado no esta funcionando. El bus de mensajes tiene la responsabilidad de entregar solamente cuando exista un consumidor activo. Este buffering de mensajes es complejo y gracias a edgeHub, nos abstraemos de toda esta problemática.

Teoría y conceptos principales Azure IoT Hub (23/37) Un gemelo
de un dispositivo es un documento JSON, creado y gestionado por IoT Hub. Este documento almacena las propiedades sobre el dispositivo, así como otros metadatos e información de configuración. Las propiedades almacenadas en los gemelos son tantas propiedades deseadas que se enviarán al dispositivo, como propiedades recogidas del dispositivo, conocidas como informadas. Ambos conjuntos de propiedades no tienes un esquema forzado. Debido a la naturaleza asíncrona de las actualizaciones de gemelo/dispositivo no se puede garantizar que el gemelo siempre este actualizado, pero siempre tendrá el último estado reportado por el dispositivo y será eventualmente consistente con las propiedades del dispositivo. Los gemelos permiten interactuar con ellos via API de IoT Hub. A través de estas APIs, los metadatos del documento gemelo podrán ser consultados, lo que puede permitir crear dashboard de información. Es dificil de implementar por qué requiere de una solicitud en tiempo real a cada dispositivo. Con Twins, las consultas se realizan en milisegundos obteniendo el último estatus reportado del dispositivo. No te queda más remedio que aceptar esta latencia. El contenido de un JSON de un gemelo se divide en cuatro áreas: • Información de identidad. Aproximadamente el ID del device. • Etiquetas. Metadatos creados por el backend y que nos permite clasificar y categorizar devices. Por ejemplo, la localización (ciudad, dirección, etc.) o sensores acoplados (temperatura, humedad, gas, …). • Propiedades deseadas. Es decir, propiedades creadas o actualizadas por el backend. Cuando se cambian no se envian de inmediato, se inicia un proceso asíncrono de actualización via IoT Hub. • Propiedades reportadas. Ultimo estado conocido. Solo son de lectura y consultables por el backend. Device Twin

Teoría y conceptos principales Azure IoT Hub (24/37) IoT Hub
Device Twin Identidad (solo lectura) Etiquetas (metadatos) Propiedades Deseadas Reportadas Device API Servicio Backend Lectura/Escritura Lectura/Escritura Lectura Servicio Backend Lectura Lectura/Escritura

Teoría y conceptos principales Azure IoT Hub (25/37) Device Twin
Identidad (solo lectura) Etiquetas (metadatos) Propiedades Deseadas Reportadas

Teoría y conceptos principales Azure IoT Hub (26/37) El concepto
de gemelo no solo se aplica al dispositivo, si no también al módulo que se ejecuta en ese dispositivo. El dispositivo edge tiene un gemelo gemelo y por cada modulo existirá un gemelo. Dado que todo el código y la configuración se realizan a nivel de módulo de los dispositivos edge, existe muy poca interacción, pero debes saber que existe. Todo lo que te he contado para el device, es válido para el modulo. Y además de tener las mismas secciones y restricciones del JSON anterior, también tienen el mismo modelo de API. Se accede por: Y la única entrada obligatoria en el JSON es: Module Twin

Teoría y conceptos principales Azure IoT Hub (27/37) El concepto
de definir rutas de mensajes es algo inherente a IoT Hub, existe desde casi el principio de este servicio. Ahora bien, este concepto donde mejor se ve es en Azure IoT Edge. Ya has visto que edgeHub proporciona de forma genérica y abstracta un mecanismo para que los módulos se comuniquen entre sí, sin tener conocimiento uno de otro. Esas conexiones abstractas entre módulos se producen a través de una ruta de mensajes definida en el módulo edgeHub, por tanto, entra en el twin correspondiente al modulo y podrás ver: Enrutamiento de mensajes en Edge

Teoría y conceptos principales Azure IoT Hub (28/37) Esto a
un nivel conceptual se puede definir de la siguiente forma: IoT Edge Hub (message broker) Modulo A Modulo B Input Output Input Output Route A Route B Output Route C

Teoría y conceptos principales Azure IoT Hub (29/37) Desarrollando el
anterior dibujo: • Route A: Crea un camino desde el origen “Output 1” del Módulo A y hasta el “Input 1” del Módulo B • Route B: Crea un camino desde el origen “Output 1” del Módulo B y hasta el “Input 1” del Módulo A. Las direcciones en un IoT Edge Hub Message Broker pueden actuar de entrada/salida indistintamente. • Route C: Crea un segundo camino desde el origen “Output 2” del Módulo B hasta el “Input 1” del Módulo A. Las rutas como puedes observar se pueden definir múltiples direcciones de entrada y salida. Este ejemplo muestra interacciones entre 2 módulos. Cuando se aplican esos mismos conceptos en un despliegue de 10 o 12 módulos, se puede comenzar a ver escenarios verdaderamente complejos y es donde ponemos a prueba el conocimiento que hemos adquirido con el enrutamiento. Antes hemos definido un edge y os he puesto en amarillo lo que viene a ser en lenguaje de IoT Hub el diagrama anterior: Como apunte, todas las rutas siguen el patrón: FROM <source> WHERE <condition> INTO <sink> Podríamos traducirlo como: DE <origen> CUANDO <condición> EN <cae>, es decir, cuando se cumpla una condición de un origen llévalo a un destino.

Teoría y conceptos principales Azure IoT Hub (30/37) SOURCE El
modulo edgeHub utiliza el origen de los mensajes de cualquier ruta para determinar dónde se originan los mensajes para esa ruta. El origen puede contener cualquier mezcla de los siguientes componentes, siempre que se representen en el orden requerido: • El carácter comodín [*]. Representa todos lo mensajes de ese nodo descriptor. • [Nombre Modulo]. Es el nombre del módulo, que se utiliza para restringir la fuente a sólo un determinado subconjunto de mensajes de un módulo específico. • [Nombre Salida]. El nombre de una salida específica utilizada en un módulo. Se utiliza para restringir los mensajes de un determinado módulo a sólo una de las salidas del módulo. Esos tres componentes se combinan de diversas formas para describir el mensaje de las rutas. Por ejemplo: • /messages/*. Todos los mensajes de cualquier módulo o dispositivo, independientemente de la salida. • /messages/modules/*. Todos los mensajes de cualquier módulo, independientemente de la salida. • /messages/modules/[Nombre Modulo]/*. Todos los mensajes del modulo indicado. • /messages/modules/[Nombre Modulo]/output/*. Todos los mensajes de todas las salidas del modulo indicado. • /messages/modules/[Nombre Modulo]/output/[Nombre Salida]/*. Todos los mensajes de la salida nombrada.

Teoría y conceptos principales Azure IoT Hub (31/37) Quizá te
preguntes porqué un edge necesita la clausula WHERE si el origen puede gestionar con flexibilidad la forma que tiene de filtrar mensajes. En realidad, es posible que no necesites esta clausula. Es posible que la fuente pueda filtrará lo suficiente como para no necesitarla. Pero piensa que la diferencia entre declarar que mensajes quieres mirar, frente a la decisión de filtrar en tiempo de ejecución, una carga así puede mermar la capacidad de computo en un dispositivo tan pequeño. CONDITION La condición de la ruta del mensaje es opcional. Pero, si decides que la necesitas, declara la condición usando el lenguaje de consultas de IoT Hub (más información aquí). Esta sintaxis admite operaciones sobre las appProperties, las systemProperties y el body: • System properties. $<propertieName>. $messageId, por ejemplo. Definidos out-the-box por el fabricante, en este caso por IoT Edge. • App properties. <propertieName>. messageStatus, por ejemplo. Son valores que se añaden via codigo y personalizados para Edge. • Body properties. $body<propertieName>. $body.TemperatureValue, por ejemplo. Son mensajes personalizados por el Edge, son del payload.

Teoría y conceptos principales Azure IoT Hub (32/37) Tambien puede
usar funciones y operadores de la sintaxis que antes os he referenciado. Por ejemplo: • IS_DEFINED(propiedad). Booleano que nos da verdadero si existe la propiedad. • AS_NUMBER(propiedad). Convierte la cadena a un numero para luego trabajar con operaciones matemáticas. • LENGTH(propiedad). Devuelve la longitud de la cadena de valores de la propiedad. Finalmente, un ejemplo de todo esto: FROM /messages/modules/temperatureSensor/* WHERE IS_DEFINED(alertStatus) INTO $upstream Esto lo que hace es filtrar aquello mensajes procedentes del modulo temperatureSensor que tengan la propiedad alertStatus a true y lo enrutará a $upstream. SINK Sumidero, fregadero, donde cae la información, destino de la ruta. Existen dos opciones para los destinos. Una que tienen todos y se llama $upstream. Cualquiera que ponga esto llevará la información a IoT Hub. Y la otra opción:

Teoría y conceptos principales Azure IoT Hub (33/37) BrokeredEnpoint(“module/[nombre modulo]/inpunts/[input1]”)
Es decir que llevará la información modulo que digamos. Los mensajes resultantes del origen y cualquier clausula se enviará a ese modulo destino para que lo procese. Si el nombre de entrada especificado no existe en el módulo, los mensajes no podrán ser entregados. En este caso, es edgeHub quien almacena los mensajes durante un TTL (time to live) especificado en la propiedad storeAndForwardConfiguration.timeToLiveSecs de la sección edgeHub de desieredProperties del twin. Por tanto, cuando el TTL expira, el mensaje de borra de la cola.

Teoría y conceptos principales Azure IoT Hub (34/37) Como ya
hemos dicho antes, IoT Hub es un servicio totalmente administrado que permite la comunicación bidireccional confiable y segura entre millones de dispositivos y una solución backend. El envio de mensajes de un dispositivo a la nube se realiza mediante un punto de conexión integrado que podemos usar en el backend, es decir, que necesitamos una pieza que lea la telemetría. Esto punto de conexión es compatible con Event Hubs y el SDK de IoT Hub es capad de realizarlo sin ningun esfuerzo. Tambien se admiten puntos de conexión personalizados que los usuarios podrán definir para enviar eventos y datos de telemetría del dispositivo a los servicios de Azure mediante enrutamiento de mensajes. Para un dispositivo IoT clásico como podemos ver es mucho más simple la forma que tenemos de comunicarnos, así como la capacidad de interacción: M2D – Message to Device

Teoría y conceptos principales Azure IoT Hub (35/37) IoT Hub
permite invocar métodos directos en los dispositivos desde la nube. Los métodos directos representan una interacción solicitud-respuesta con un dispositivo, similar a la llamada HTTP en la cual se completan correctamente o generar un error de inmediato (tras un tiempo de espera que especifica el usuario). Este enfoque es útil en escenarios donde el curso de una acción inmediata es distinto en función de si el dispositivo pudo o no responder. En esta imagen podrás intuir como funciona, te recordará mucho a herramientas tipo Postman: Direct Method

Teoría y conceptos principales Azure IoT Hub (36/37) Lo veremos
de forma práctica en nuestra PoC. Por tanto, aquí solamente vais a ver una breve explicación. Cuando empezamos a gestionar un parque grande dispositivos, la implementación de cambios se convierte en un reto. IoT Hub ofrece una función llamada deployment que nos ayuda a gestionar esta tarea de forma más sencilla. Aunque esta funcionalidad no es específica de Azure IoT Edge, hay algunas características específicas de IoT Edge que debes conocer. Esencialmente, los despliegues son una forma de agrupar dispositivos y aplicar un manifiesto de configuración común (ajustes de configuración y lista de módulos) a ese grupo y entregar esa carga de trabajo de orquestación a IoT Hub. Los despliegues se crean en IoT Hub, ya sea via interface como CLI o incluso API. Una vez definido el despliegue, la instancia de IoT Hub gestionará cada dispositivo evaluando si el destino tiene o no la configuración especificada, así se asegura que tenga siempre la configuración y software adecuado. Edge Deployment Para el caso de un dispositivo IoT clásico, la cosa se complica un poco más, ya que lo normal es que se actualicen firmware y eso se escapa de este curso. Aunque es posible que en las técnicas avanzadas os muestre donde podéis documentarios y que comprendáis como funciona en este tipo de caso concreto.

Teoría y conceptos principales Azure IoT Hub (37/37) Si entras
en la opción de añadir despliegue, entrarás en una nueva sección con varios pasos a completar. Como algunos conceptos ya los tienes y aun faltan algunos que se reservan para verlos en la PoC, no entraré en detalle, solamente explicaré unos conceptos para que te suene cuando llegue el momento: • Nombre y etiqueta. Logicamente nombre del despliegue y etiqueta de metadatos asociado al mismo. • Añadir módulos. Lista de módulos que deben ser asignados a un dispositivo en concreto y cualquier dato asociado al contenedor donde se encuentra el modulo, así como credenciales para acceder a los que son privados. • Especificar rutas. Los enrutamientos anteriormente explicados. • Especificar métricas. Es decir, listas pares nombre-valor personalizados asociados al despliegue. Puede ser una consulta a los metadatos del dispositivo, por ejemplo, ver cuales de ellos tiene aplicado el despliegue. • Dispositivos de destino. Una condición (clausula) para identificar los dispositivos a los que debemos aplicar el despliegue. • Prioridad determinada de aplicación. En que orden debe desplegarse este deploy y sus modulos.

Preparando nuestro … Entorno (1/5) Proceso delicado – Te recomiendo
usar un entorno limpio La plataforma IoT Hub cuenta con un conjunto de herramientas que proporciona a los desarrolladores una experiencia similar a lo que estamos acostumbrados, a pesar de que la configuración es mas complicada, un poco más cuando se trata de IoT Edge. Las herramientas se basan en Visual Studio, VS Code, Docker/Moby, .Net Core para aplicación .Net, Python, extensión IoT Hub y un registro de contenedores en nuestro caso Azure Container Registry (ACR). A continuación, vamos a instalar, configurar y conectar todas esas tecnologías para crear una experiencia de desarrollo cohesiva. Lo primero es que, en tu máquina principal, no en la Raspberry Pi, tengas instalado VS Code, si quieres trabajar con Visual Studio también puedes, pero tendrás que buscar las herramientas similares a las que use en VS Code. Configurar VS Code para IoT Edge Debemos instalar la extensión: Azure IoT Edge. Necesitas tener Docker, Python y Pip. Una vez cumplido esto requisitos ejecuta: pip install --upgrade iotedgehubdev Te recomiendo que leas bien toda la información de esta extensión.

Preparando nuestro … Entorno (2/5) Moby + IoT Edge –
Montando tu Rapsberry Pi como un dispositivo IoT Edge Paso 1 Instalar las ultimas runtimes. curl https://packages.microsoft.com/config/debian/stretch/multiarch/prod.list > ./microsoft-prod.list sudo cp ./microsoft-prod.list /etc/apt/sources.list.d/ curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg sudo cp ./microsoft.gpg /etc/apt/trusted.gpg.d/ Paso 2 Instalar Moby sudo apt-get update sudo apt-get install moby-engine && sudo apt-get install moby-engine moby-cli

Preparando nuestro … Entorno (3/5) Paso 3 Instalar Azure IoT
Edge Security Daemon sudo apt-get update sudo apt-get install iotedge Paso 4 Configurar el Daemon. Pero antes debes crear un dispositivo IoT Edge en Azure llamado raspberrypi4 sudo nano /etc/iotedge/config.yaml

Preparando nuestro … Entorno (4/5) Pegas la cadena de conexión
copiada desde Azure IoT Edge sudo systemctl restart iotedge Paso 5 Comprobar que efectivamente esta enlazado el dispositivo físico con IoT Edge

Preparando nuestro … Entorno (5/5) .Net Core 3.1 – Montado
en tu Rapsberry Pi A continuación, vamos a seguir estos pasos para poder instalar .Net Core 3.1 en tu Rapsberry Pi y así poder ejecutar un módulo desarrollado en C#. Descargar el paquete de: https://dotnet.microsoft.com/download/dotnet/3.1 Ejecutar desde la carpeta donde descargaste el tar: sudo mkdir -p $HOME/dotnet sudo tar zxf dotnet-sdk-3.1.415-linux-arm.tar.gz -C $HOME/dotnet export DOTNET_ROOT=$HOME/dotnet export PATH=$PATH:$HOME/dotnet Probar: Dotnet run

Ejemplo Hello IoT Edge(1/20) Vamos a probar directamente un ejemplo
más complejo, usando IoT Edge. Donde simplemente vamos a ir mandando una telemetría cada 1 sg. Que desplegaremos en la Raspberry Pi. Carga el proyecto en VS Code y comencemos. pyHelloIoTEdge – Probamos nuestro primer ejemplo en Azure IoT Hub https://github.com/jmfloreszazo/HandsOnIoTAzure

Ejemplo Hello IoT Edge(2/20) Escribimos “edge” en la ventana de
comandos: Y buscamos: Azure IoT Edge: New Azure IoT Edge Solution, establecemos la carpeta que deseemos. Creamos el nombre que nos da por defecto: “EdgeSolution”, usamos C# o podríamos haber usado Python, creamos el primer modulo llamado “SampleModule”, dejamos lo que propone para Docker y finalizamos. Os cuento que ficheros se han creado: • deployment.template.json, la plantilla basada en JSON que contiene toda la información necesaria para que el runtime de edge descargue las imágenes de Docker, crear los módulos contenedores en el edge e iniciarlo. Contiene información sobe cada módulo del edge que debe ser desplegado, incluido el registro de contenedores y las credenciales de registro si fueran necesarias. Además, para cualquier contenedor Docker también se enumeran las opciones de creación de los contenedores Docker. Por último, cualquier configuración específica del módulo IoT Edge que forma parte del gemelo del módulo. Ten en cuenta que este archivo se utiliza simplemente para generar el archivo delployment.json (que aun no hemos visto), que en realidad es el fichero de instrucciones de despliegue real.

Ejemplo Hello IoT Edge(3/20) • Dockerfile.*, si has usado Docker
ya conocerás el Dockerfiles. La estructura de la solución incluye varios de ellos: - Dockerfile.amd64, para procesadores Linux-based x86/x64 - Dockerfile.amd64.debug, lo mismo, pero con información para depuración. - Dockerfile.arm32v7, para procesadores Linux-based ARM - Dockerfile.windows-amd64, para Windows IoT Core basado en x86/x64 • SampleModule.csproj, fichero de un proyecto basado en .Net Core. • Module.json, fichero que simplifica la interacción en el entorn de desarrollo edge y el entorno Docker/Build. Este archivo enumera las opciones de compilación disponibles y el plugin IoT Edge de VS Code inspecciona el archivo. Es para hacer una build del proyecto y luego llamar al Docker build (para hacer un push). • program.cs, la logica de cualquier programa C#. Por defecto incluye ya algunas cosas básicas como el registro de los manejadores de eventos para el runtime de edge.

Ejemplo Hello IoT Edge(4/20) IoT Hub Connection String En VS
Code tenemos una serie de acciones que nos ayudan sobremanera, como poner la nueva cadena de conexión de la instancia de IoT Hub estaremos viendo el recurso que deseemos. Recuerda que existen 2 tipo de cadenas: la de la instancia y la del device. az iot hub connection-string show -n jmfzIotHub Si necesitas cambiar de tenant de Azure: Ctrl + Shift + p luego escribe Azure: Sing Out y para entrar Azure: Sing In

Ejemplo Hello IoT Edge(5/20) Ahora que tienes una comprensión general
de los artefactos del proyecto principal y la estructura, vamos a ver en más detalle cada uno de los archivos más importantes y explicaré como nos basamos en la plantilla para crear una solución personalizada. Todos los artefactos que hemos visto se pueden agrupar en tres acciones: desarrollar, construir o implementar. Desarrollar, evidentemente, incluye todo tu codigo en C# o el lenguaje que escogieras. La compilación incluye los archivos Docker y otros que nos permitan crear imágenes de Docker. Y la implementación incluye los archivos utilizados para las imágenes de Docker, describen las interacciones de mensajes entre contenedores e implementa este manifiesto en un edge. Desarrollar .csproj .cs .config Build Dockerfiles module.js Deploy Deployment.template.json Deployment.json Las acciones de la solución – Son tres

Ejemplo Hello IoT Edge(6/20) Comenzamos revisando el fichero program.cs y
el Main: Es responsable de invocar el método asíncrono Init(), registrar el evento de cancelación y esperar a es evento. Acción: Desarrollar – 1/3

Ejemplo Hello IoT Edge(7/20) ModuleClient es la API principal y
es donde conectamos con CreateFormEnvironmentAsync o Create o CreateFromConnectionString. Las opciones de transporte que tenemos en IoT Hub son: Una vez creado la instancia de ModuleClient, revisa los métodos de la documentación, por ejemplo: • OpenAsync, abre la capa de transporte. CloseAsync, la cierra. • GetTwinAsync, obtiene la información del gemelo. UpdateReportedPropertiesAsync, actualiza la información del ultimo reporte.

Ejemplo Hello IoT Edge(8/20) Habrás observado que muchos constructores aceptan
un parámetro llamado authenticationMethod. Viene de Microsoft.Azure.Devices. Tenemos varias opciones entre las que elegir y es útil entender las diferencias, para asegurarte que estas eligiendo la implementación adecuada. Como la seguridad es un punto que trataremos más adelante, solamente voy a daros unas pinceladas. En IoT Hub existen tres tipos de seguridad principales: • Claves simétricas que tienen dos tipos: generadas a nivel de dispositivo y claves de políticas SAS. • Certificados X.509. • Chips TPM (modulos de plataforma confiables). Que logicamente no vamos a ver en este curso de forma real, solo teoría. Nunca he tenido un chip de este tipo para IoT en las manos. Los 2 anteriores son los que vemos más adelante, y explicaremos para las claves simétricas los distintos roles: Iothubowner, RegistryReadWrite, etc. Mientras que para X.509 realizaremos un proceso completo para obtener certificados. Aunque antes hemos visto una lista de transportes, debo deciros que se traducen en tres básicamente: AMQP, MQTT y HTTP (es la versión 1).

Ejemplo Hello IoT Edge(9/20) Si entramos en PipeMessage estaremos entrando
en el controlador de eventos. Lo que estamos haciendo es que en tiempo de ejecución el edge proporciona un mensaje al controlador de eventos que crea una copia del mensaje y luego la publica con output1. Las salidas nombradas no tienen que estar definidas en cualquier sitio (esto es un ejemplo), piensa que este nombre debe coincidir con la ruta que pretendes publicar en la entrada. Conviene recordar que desarrollar software IoT Edge principalmente se basa en eventos. Existen caso que no será así, pero la mayoría si. De nuevo, revisa la clase ModuleClient.

Ejemplo Hello IoT Edge(10/20) Estas aplicaciones son un tanto diferentes,
no vale con ejecutar dentro el IDE y listo. Como esta basada en contenedores, lo primero es compilar y enviarlo a un registro de contenedores. Supongo que habrás entrado en las distintas variaciones del fichero Dockerfile y que no sea nuevo para ti, ya que seguramente algo de Docker habrás visto. Pero, excepto que sepa de IoT, el fichero module.json es nuevo. Este fichero, module.json, es un envoltorio alrededor de cualquier fichero Dockerfile. Si haces clic derecho sobre el fichero verás que pasa: Una vez seleccionada la opción te pedirá la plataforma sobre la que vas a ejecutarlo, como queremos usar nuestro Windows 10, escoge amd64. Podrás observar la cantidad de acciones y tareas para preparar la build, debes esperar. Acción: Build – 2/3

Ejemplo Hello IoT Edge(11/20) Si todo fue bien, entra en
el Dashboard de Docker:

Ejemplo Hello IoT Edge(12/20) Por último, queremos implementar el codigo
en un dispositivo Edge. Recapitulando, hemos desarrollador nuestra aplicación y empujado nuestra imagen a un registro de contenedores. Ahora es el momento de asignar el manifiesto de implementación para el dispositivo. Para ello, desde deployment.template.json, botón derecho del ratón: Como resultado, obtendremos un deployment.amd64.json en el directorio config de la solución. Como puedes revisar el contenido de deployment.template.json y puede que no lo entiendas a simple vista, permíteme que en el siguiente diagrama aclare esto de forma más visual, siempre ayuda más. Después debes hacer la build: “Build IoT Module Image”. Acción: Desplegar – 3/3

Ejemplo Hello IoT Edge(13/20) $edgeAgent y $edgeHub, son los únicos
requeridos. Tanto $edgeAgent como $edgeHub deben tener las propierties.desired. Las propiedades $edgeAgent son la información para el pull de las imágenes Docker. Las propiedades $edgeHub son la información para crear el enrutado de los mensajes. Las propiedades que puedas generar en tu módulo y que tu necesites crear. modulesContent $edgeHub $edgeAgent SampleModule properties.desired properties.desired properties.desired runtime systemModules modules routes Custom properties specific to the modules

Ejemplo Hello IoT Edge(14/20) Tanto $edgeAgent y $edgeHub tienen secciones
especializadas en el manifiesto que deberías conocer un poco: $edgeAgent $edgeHub Nombre de la propiedad Descripción runtime.Type Siempre debe “docker . runtime.settings.minDockerVersion Version mínima de Docker. runtime.settings.loggingOptions Acceso para Docker runtime.settings.registryCredentials Credenciales para el registro de contendores. De 1 a N. systemModules.edgeAgent Ver tabla sobre la información de la estructura del JSON systemModules.edgeHub Ver tabla sobre la información de la estructura del JSON Nombre de la propiedad Descripción routes Par nombre-valor de las rutas. El nombre puedes poner el que quieras pero las rutas deben cumplir con las especificaciones que vimos anteriormente.

Ejemplo Hello IoT Edge(15/20) Tabla de la estructura del JSON
Nombre de la propiedad Descripción type Siempre debe “docker . status Para los modulos de sistema (Hub y Agent), siempre debe estar en “running . Para los modulos personalizados, puede ser: • stopped. Después de desplegar, el modulo puede estar idle durante un tiempo. • running. Opción por defecto. El modulo debería estar en esta situación tras desplegarse. restartPolicy Para los modulos de sistema, siempre debe estar en “always . Para los modulos personalizados, puede ser: • never. Nunca debe reiniciarse si se hace un shut down. • on-failed. Debe reiniciarse si se rompe, pero no si es un shut down. • on-unhealthy. Si falla o esta inestable se podrá reiniciar. Cada modulo debe implementar su propia medida de salud. setting.image URI de la imagen settings.creatOptions Cadena en JSON de creación del contenedor.

Ejemplo Hello IoT Edge(16/20) Si entras a ver el fichero
module.json, ahora lo podrás entender mejor, aun más si vas a la sección correspondiente de deployment.template.json: Vamos a desplegar y para ello, como os pedí que usarais vuestro Windows 10, nos tocará hacer una serie de pasos que detallo a continuación:

Ejemplo Hello IoT Edge(17/20) • Instalar IoT en tu máquina
de Windows 10, para ello debes seguir los siguientes pasos: - Crear un nuevo IoT Device llamado windows10 y obtener la cadena de conexión. - Seguir los pasos correspondientes a este proceso definido por Microsoft. - Si al final de proceso tienes un “Deployment successful”, ya podrás trabajar. - Ejecuta el ultimo comando con la cadena de conexión y habrás conectado tu equipo. • Ahora podrás ver que tienes un error 417, que no has implementado ningun módulo. • Refresca la sección de VS Code Azure IoT Hub. • Si haces clic derecho sobre windows10, podrás ver la opción correspondiente para crear un deploy:

Ejemplo Hello IoT Edge(18/20) • Pulsa en “Create Deployment for
Single Device”. • En el panel que nos muestra, debes escoger, la configuración dentro de “Config” llamada deployment.amd4.json. • Repite el mismo proceso para raspberrypi4. • Observa en el portal cada uno de los dispositivos IoT Edge esta en 500. Entramos en el modulo para ver que sale: Debido a que no es posible encontrar el contenedor en localhost, para ello debemos comenzar a trabar con ACR.

Ejemplo Hello IoT Edge(19/20) • Creamos un ARC (Azure Container
Registry) az acr create --name [prefijo]IoIACR --resource-group [prefijo]IoTRG --sku Basic • Añadimos las credenciales, usa un .env de VS Code. • Realiza un login en ACR: az acr login --name [prefijo]IoIACR • Cambia la linea 5 de module.js con tu ACR. Y prepara una build & push desde deployment.template.json.

Ejemplo Hello IoT Edge(20/20) • Revisa que este la imagen
en ACR. • Y desplegamos contra el IoT Device de VS Code, recuerda: Create Deployment for a Single Device

Ejemplo Depuración en IoT Edge(1/6) Vamos a ir un poco
más a fondo con el tema del desarrollo y la depuración. Nuestro ciclo de desarrollo podría resumirse en: Debugging – Ahora que ya estas más cómodo/a trabajando con IoT Edge Desarrollar un módulo de Edge Construir un contenedor Subirlo al registro Desplegar al dispositivo

Ejemplo Depuración en IoT Edge(2/6) Es la primera herramienta que
vemos para depurar IoT Edge. En realidad, es un simulador de Edge en un entorno local, sin la necesidad de una conexión activa a una instancia de IoT Hub, por tanto, también nos quita el requisito de tener que publicar a una instancia. Manos a la obra con el comando iotedgehubdev del CLI: 1. Evidentemente tener instalado Python 3.5 o superior e instalar iotedgehubdev 2. Establecer la conexión con el dispositivo: iotedgehubdev setup --connection-string “edge- connection-string”. Si todo fue con éxito debe aparecer “Setup IoT Edge Simulator successfully”. 3. Ejecutas la simulación con iotedgehubdev start -d “PathTo/deployment.json”. Esperas un ratito y si todo fue bien tendrás el mensaje “IoT Edge Simulator has been started in solution mode”. Azure IoT EdgeHub Dev Tool – pip install --upgrade iotedgehubdev No pretendo desgranar completamente como se depura con la utilidad iotedgehubdev, pero si que vamos a ver a grandes rasgos para que sirve, lo que me interesa que se vea bien es el trabajo con VS Code, que más o menos es extensible (como la parte anterior del ciclo: desarrollar, build y deploy) a Visual Studio + la extensión de IoT Edge, salvando las pequeñas distancias que impone en IDE.

Ejemplo Depuración en IoT Edge(3/6) 4. Ahora mismo tenemos corriendo
edgeHubDev. 5. Vamos a lanzar el modulo de SampleModule: iotedgehubdev start -i "input1“ 6. Lanzamos el comando curl que nos indica o bien usamos Postman. O te haces un proyecto de testing para probar las cosas. La opción que más te guste. 7. A veces deberás establecer uno valores por defecto al módulo antes de ejecutarlo: iotedgehubdev modulecred -m "SampleModule“ 8. Usa: iotedgehubdev -h, para obtener ayuda. 9. Y finalmente paramos el simulador: iotedgehubdev stop, cuando termine verás: “IoT Edge Simulator has been stopped successfully”. Lógicamente podría ampliar más información sobre este comando, pero esa investigación te corresponde a ti, yo ya he te he puesto sobre la base para que amplies el conocimiento.

Ejemplo Depuración en IoT Edge(4/6) Es otra herramienta del ambiente
Python que es capad de realizar gran parte de las funciones anteriormente descritas, pero desde el CLI. Con esta herramienta, puedes crear y administrar todos los recursos de una solución edge (a veces a edge se le llama también solución perimetral), incluido el runtime de Docker, el simulador y los recursos de Azure IoT Hub. Os muestro de forma rápida que funcionalidades admite: • Añadir nuevos módulos. • Monitorizar mensajes enviados desde el edge a IoT Hub. • Desplegar. • Administrar IoT Hub. • Administrar el entorno Docker local. • Administrar el simulador. Si ejecutas: mkdir c:\temp\iotedge docker run -ti -v /var/run/docker.sock:/var/run/docker.sock -v c:/temp/iotedge:/home/iotedge mcr.microsoft.com/iotedge/iotedgedev Azure IoT Edge Dev Tool – iotedgedev

Ejemplo Depuración en IoT Edge(5/6) Podrás tener todo el contenedor
con las cosas necesarias, que son muchas, listo para usar. El proyecto se encuentra en GitHub. Sigue las instrucciones paso a paso. Esta herramienta la dejo para tu estudio personal, no debe supone ningun misterio aprender los comandos necesarios para trabajar con este CLI. Pruébalo y si no te convence siempre podrás limpiar los contenedores sin afectar a nada de tu equipo.

Ejemplo Depuración en IoT Edge(6/6) Tampoco hacía falta tener las
otras herramientas, pero es una opción que puede ayudarte. De todas formas, vamos a la forma más sencilla y que seguramente uséis. Una vez ejecutada la acción, podrás ver en el terminal que se pone a realizar muchos pasos. Cuando termine solamente debes usar: VS Code Debugging – La forma más sencilla de depurar

Ejemplo Hello IoT Device(1/5) Si has asimilado todo lo anterior
de Edge, el modo clásico lo vas a ver como un paseo. Manos a la obra. Vamos a crear este sencillo ejemplo que lanzaremos desde VS Code de la Raspberry Pi y podremos ver como interactúa con IoT Hub y genera un sencillo Hello World. Carga el proyecto en VS Code y comencemos. pyHelloIoTDevice – Probamos un device en modo clásico https://github.com/jmfloreszazo/HandsOnIoTAzure

Ejemplo Hello IoT Device(2/5) Como veréis estamos usando la interface
gráfica para ciertas acciones. En algun ejemplo he puesto imágenes y en los readme.md principalmente lineas de comando. Pero con la anterior frase (leer el ensayo si tenéis oportunidad) os estoy diciendo que la potencia de trabajo con CLI es superior a la UI. En este caso los pasos de crear un IoT Device por UI son: In the beginning... was the command line – Neal Stephenson (1999)

Ejemplo Hello IoT Device(3/5) Mientras que por CLI: Intenta en
la medida de lo posible abstraerte en UI, en un futuro me lo agradecerás.

Ejemplo Hello IoT Device(4/5) Establecer la linea de comando y
ejecutar el programa de Python: De momento quedaros que eso mensajes han sido enviados de la forma C2D, como podéis observar en la telemetría de Azure IoT Hub. Intenta en la medida de lo posible abstraerte en UI, en un futuro me lo agradecerás.

Ejemplo Hello IoT Device(5/5) Vuelve a lanzar el programa y
vamos a ejecutar la siguiente acción en el CLI: az iot device c2d-message send -d {device_id} -n {iothub_name} --data ‘Testing C2D’ O bien desde: Podéis observar que se esta escribiendo el mensaje:

Ejemplo Enviro + IoT Device(1/4) Vamos a generar la correspondiente
telemetría de Enviro+ y vamos a consumir esa información en una Azure Function pintando el resultado en la consola. Aquí vamos a trabajar con ambos lenguajes, el anterior ejemplo fácilmente se puede desarrollar en C#, pero para algo he creado la Sección 2, para ir avanzando en paralelo y ampliar más tus conocimientos. Entra dentro de enviroPlusIoTDevice y luego en pyEnviroPlusIoTDevice. Lanza VS Code y comencemos. enviroPlusIoTDevice – Un device real en modo clásico https://github.com/jmfloreszazo/HandsOnIoTAzure

Ejemplo Enviro + IoT Device(2/4) En esta ocasión la cadena
de conexión es la de tu IoT Hub, ya que vamos a registrar un dispositivo si no existe: az iot hub connection-string show -n {iothub_name} Aquí podemos ver el codigo que registra un dispositivo (1), como se conecta de otra forma diferente a un dispositivo (2) con respecto al ejemplo anterior y la telemetría que estamos enviando (3), dejemos de lado cualquier carencia técnica en el código ya que no se trata de eso en estos momentos:

Ejemplo Enviro + IoT Device(2/4) Creamos una Azure Function que
este suscrito a la telemetría, con Python. Para ello primero vamos a obtener la cadena de conexión del Event Hub:

Ejemplo Enviro + IoT Device(4/4) Cargar pyEnviroPlusIoTDevice y bakend, lo
ejecutas. Para backend debes modificar la cadena de conexión que se encuentra en local.settings.json, cuidado no pongas en la cadena de conexión la parte de EntityPath ya que es la misma que debes poner en el eventHubName. Ejecuta la Function y podrás observar como esta recogiendo la telemetría, con esto acabo de mostraros un backend de IoT Hub.

Ejemplo Twins(1/5) Este ejemplo con Python y C# vamos a
ver como funciona un gemelo. Para ello vamos a trabajar desde el UI del portal de Azure y con código. Como ya comenté antes, ya realizo el trabajo indistintamente con Az CLI o el UI, la cuestión es entender los conceptos. Lanza VS Code y comencemos. pyTwinIoTHub – Vamos a ver en la práctica que es un gemelo https://github.com/jmfloreszazo/HandsOnIoTAzure

Ejemplo Twins(2/5) Tiempo atrás expliqué que era un gemelo (twin),
ahora vuelvo a retomarlo para que quede claro y no se confundan conceptos con lo que es Digital Twins. Tal y como se explicó anteriormente, los dispositivos gemelos son documentos JSON que almacenan información del estado del dispositivo, incluido metadatos, configuraciones y condiciones. Azure IoT Hub mantiene un dispositivo gemelo para cada dispositivo que se conecta a IoT Hub. Para ello vamos a modificar la frecuencia con la que informa el dispositivo.

Ejemplo Twins(3/5) Una vez guardado los cambios, observar como se
modifica el JSON gemelo creando nuevas entradas y cambiado la versión de las propiedades deseadas. Nuestra prueba será la siguiente: 1. El backend establecerá la propiedad deseada, con la configuración correspondiente. En nuestro caso cambiamos el JSON manualmente desde el portal y lo guardamos. 2. La aplicación del dispositivo recibirá una notificación de cambio cuando esta conectada o cuando vuelva a conectarse. E informará en la parte reportada. 3. Posteriormente podremos llevar un registro de dispositivos a través de las consultas.

Ejemplo Twins(4/5) Cambia el valor en el portal de Azure
y observa el comportamiento de tu aplicación: Podrás observar que el dispositivo automáticamente ya tiene la información deseada cambiada. Con esta información ya puedes jugar con ella para establecer propiedades reportadas y deseadas. Esto tiene mucho sentido cuando tenemos cientos de dispositivos y queremos cambiar (desde backend) aquellos que cumplan una condición. De forma automática cuando se autorregistran dispositivitos podrían mandar propiedades deseadas como: ciudad, coordenadas de geolocalización, etc. Por tanto, solo te queda ver como filtrar por aquellos dispositivos que nos interesan, si tenemos que pasar un parche de propiedades. Y esto se puede hacer gracias al lenguaje de consultas que nos ofrece IoT Hub: https://docs.microsoft.com/es-es/azure/iot-hub/iot-hub-devguide-query-language

Ejemplo Twins(5/5) Podemos integrar en codigo este tipo de consultas
y aplicar desde backend unas nuevas propiedades deseadas a los dispositivos que nos interesan. Pero en esta ocasión os muestro como filtrar desde el portal: A partir de aquí y con lo que ya conoces de Twins Devices y Twins Modules, podrás entender por que es importante que conozcas y entiendas bien esta parte antes de lanzarte a Digital Twins.

Teoría y conceptos principales Azure IoT Central(1/3) Azure IoT Central
Tal y como pone en la web de Microsoft: IoT Central es una plataforma de aplicaciones de IoT que reduce la carga y el costo del desarrollo, la administración y el mantenimiento de soluciones de IoT de nivel empresarial. La elección de compilar con IoT Central ofrece la oportunidad de centrar el tiempo, el dinero y la energía en transformar su negocio con datos de IoT, en lugar de simplemente mantener y actualizar una infraestructura de IoT compleja y continuamente en constante evolución. La interfaz de usuario web le permite conectar rápidamente dispositivos, supervisar sus condiciones, crear reglas y administrar millones de dispositivos y sus datos a lo largo de su ciclo de vida. Además, le permite actuar sobre la información del dispositivo mediante la extensión de IoT Intelligence en aplicaciones de línea de negocio. En resumen: Es una plataforma de IoT con gestion completa, 360º. Que nos permite gestionar complejas soluciones IoT con menos esfuerzo, focalizada en los datos y 100% orientada al negocio. Donde una interface web nos permite desde crear aplicaciones, administrar dispositivos, analizar datos. Además, es un producto destinado al cliente final y a partners. Con las siguientes ventajas: precio es un valor predictivo, alejado de las sorpresas; puede escalar según tus necesidades, con plantillas orientadas a negocios que nos permite acelerar el proceso; añade una facilidad de uso gracias a dispositivos certificados y plug & play; y por supuesto con soporte a IoT Edge. Como no, con diversas herramientas que nos ayudan a trabajar: portal, Azure CLI, SDKs y REST APIs.

La tecnología principal subyacente: Tanto Azure Device Provisioning Service (DPS)
como Azure Time Series Insights (TSI) lo veremos en secciones futuras y se tratará en profundidad. Teoría y conceptos principales Azure IoT Central(2/3) Devices & Twins Analisis Provisioning

A grandes rasgos las fases de Azure IoT Central son:
1. Crear Aplicación • Personalizado • Plantilla de negocio 2. Conectar Dispositivos • Personalizados • Dispositivo certificado del catálogo 3. Administrar • Configurar y actualizar 4. Escalar y Reutilizar • Exportar y personalizar aplicaciones 5. Extender • Usar conectores y APIs para integrar servicios 6. Monetizar • Publicar tu aplicación en el cliente final • Publicar tu aplicación en el marketplace Teoría y conceptos principales Azure IoT Central(3/3)

Ejemplo paso a paso Azure IoT Central(1/14) El funcionamiento de
la aplicación será el siguiente: Vamos a crear el recurso, insisto, todo lo que ves con imágenes se puede hacer con Azure CLI: az iot central app create -n {your iot central} -g {your resource group} -s {your iot sub domain} -l westeurope -p ST0 Conexión Telemetría Propiedades reportadas Telemetría Propiedades deseadas csharpIoTCentral – Veamos como trabajar con esta solución SaaS

Ejemplo paso a paso Azure IoT Central(2/14) Desde el recurso,
pulsar sobre la url: Llegaremos a este portal:

Ejemplo paso a paso Azure IoT Central(3/14) Creamos un template
para el dispositivo (te recomiendo que para que sigas los mismos pasos sin equivocaciones, pongas todo en inglés): 1. Dashboard App settings Device templates New 2. Create custom device template IoT device Next: Customize enviroplus Next: Review Create 3. Custom model Y vamos añadiendo capability como se muestra en la imagen. 4. Save Publish

Ejemplo paso a paso Azure IoT Central(4/14) Añadimos un dispositivo:
1. Dashboard Device Create a device 2. Cambiamos Device name y Device ID por testiotcentraldevice Seleccionamos un template: enviroplus Create Entramos en el device testiotcentraldevice: 1. Connect Guarda el valor ID Scope y el valor de la Primary Key 2. Close Generamos una vista para los devices: 1. Dashboard App settings Device templates Selecciona enviroplus 2. Views Editing device and cloud data 3. Pones un nombre al form sampleform Page layout 1 Añade las dos propiedades que tienes 4. Save Publish

Ejemplo paso a paso Azure IoT Central(5/14) Generamos una visualización
para los devices: 1. Dashboard App settings Device templates Selecciona enviroplus 2. Views Visualizing the device 3. Pones un nombre a la view sampleview Page layout 3 columna layout 4. Start with device Telemetry temperature Add tile 5. Repite con las propiedades que quieras ver Save 6. Back 7. Publish 8. Dashboard Device testingiotcentraldevice sampleform y smapleview Creamos un Dashboard principal: 1. Dashboard New Dashboard dashboardtest para toda la organización Create 2. Edit Start with devices enviroplus – All devices 3. Marcas el único device que tienes seleccionas temperature Add tile 4. Añade los que quieras Save

Ejemplo paso a paso Azure IoT Central(6/14) Creamos una regla
para la temperatura: 1. Dashboard Rules Create a rule añades el nombre high_temperature 2. Seleccionas el Device template enviroplus 3. Añades la condición 4. Save. Si lo deseas puedes añadir una acción: enviar un mail, un Webhook, una Azure Logic App, …

Ejemplo paso a paso Azure IoT Central(7/14) ¿Qué es un
Job? Permiten realizar actualizaciones masivas de las propiedades de los dispositivos y la nube, además de ejecutar comandos. Llega el momento de generar un Job: 1. Dashboard Jobs Create a job añades el nombre test_job y una descripción 2. Seleccionas Device Group enviroplus – All devices 3. Job type Command testcommand 4. Next Next Schedule On One-Time (debes pone algo que puedas probar) Next >> Review >> Schedule

Ejemplo paso a paso Azure IoT Central(8/14) La aplicación de
emulación que simula el trabajo con una placa Enviro+, de este modo podrás trabajar sin problemas si no tienes la placa. Para ello entra en la solución y en el proyecto IoTCentralDevice, que simula los valores que hemos puesto antes en la configuración. Cambia la configuración correspondiente y ejecuta el programa, comenzará a enviar telemetría, espera unos 30 segundos y luego entra en IoT Central. Aquí podéis ver las propiedades deseadas:

Ejemplo paso a paso Azure IoT Central(9/14) Las graficas de
los valores enviados:

Ejemplo paso a paso Azure IoT Central(10/14) La ejecución de
comandos y la vista de datos en bruto:

Ejemplo paso a paso Azure IoT Central(11/14) Y solo te
queda explorar las opciones que tenemos en el menú, como, por ejemplo: A partir de aquí te toca explorar más. Entra en este enlace y explora por tu cuenta.

Ejemplo paso a paso Azure IoT Central(12/14) IoT Plug and
Play mobile, si has trasteado quizá habrá descubierto que a parte del Key puedes generar un QR para conectar un device. Deberás esperar a la Sección 7: Avanzado, para verlo.

Ejemplo paso a paso Azure IoT Central(13/14) Ya solo nos
queda como atacar al API para poder realizar acciones que necesitemos enganchar a un backend y UI diferente al producto SaaS, por ejemplo, si queremos mostrar la ubicación de nuestro teléfono o coche dotado con GPS en la pantalla de administración de la ficha de un comercial. Entra en el proyecto IoTCentralRestApi y cambia la información correspondiente: Toda la información la puedes obtener desde este enlace: Device – Get Telemetry Value

Ejemplo paso a paso Azure IoT Central(14/14) Tenemos que crear
un token en IoT Central: Establece un nombre que quieras y añade el rol de “App Operator”. Cambia los valores correspondientes en la restUriGet y ejecuta el ejemplo. https://github.com/jmfloreszazo/HandsOnIoTAzure

Teoría y conceptos principales Azure IoT Solution Accelerator(1/) Azure IoT
Solution Accelerator En vez de hacerlo todo tu mismo, como en el ejemplo anterior, puedes partir de una plantilla predefinida. Estas plantillas genéricas las podrás adaptar según tus requisitos. Si quieres más información sobre las plantillas, sigue el enlace.

Ejemplo paso a paso Azure IoT Solution Accelerator(1/2) En este
ejemplo paso a paso lo que quiero mostraros es como crear una plantilla, cambiar un valor rápidamente y los pasos que tendrías que realizar para publicar esto en un cliente. Tambien podría haber optado por la personalización del ejemplo anterior, pero de este modo hacemos dos cosas en un mismo ejemplo. Entramos en la Url: https://apps.azureiotcentral.com/ Y creamos una aplicación para Goverment: Water Consumption Monitoring. En modo Estándar 0, por que, si no, puede que tengas problemas al exportar. Supongo que lo habrás podido ver antes cuando has visto los precios. Existe una opción Free de 7 días que una vez usado se borra automáticamente. También habrás observado que poco o nada había hablado de precios. Los precios cambian para mejor, más baratos cada vez, como fluctúan y existe la calculadora de Azure, no he entrado en ello, eso te lo dejo a ti. Entretente un rato en revisarlo todo y sobre todo si como deberes puedes revisar la parte de Data Export para exportar la telemetría. World Wide Water Quality Control – Ejemplo acelerado

Ejemplo paso a paso Azure IoT Solution Accelerator(2/2) Modificamos la
visualización para los devices: 1. Dashboard App settings Device templates Selecciona Smart Valve Y cambia el formato a una columna 2. Save Back Publish De esta forma tan sencilla ya has personalizado el template que has desplegado desde Accelerator. Ahora toca exportar todo esto al otro IoT Central que habíamos creado: Dashboard Administration Your Application Copy

Teoría y conceptos principales Azure Digital Twins(1/11) Azure Digital Twins
Azure Digital Twins (ADT) permite crear gráficos gemelos basados en modelos digitales. El objetivo principal de un dispositivo gemelo digital es proporciona la misma o incluso más y mejor información de la que podría ser obtenida mediante un dispositivo gemelo físico. Es un contraste entre un gemelo físico y simulado. Los dispositivos gemelos de IoT Hub se pueden conectar a Azure Digital Twins como parte de una solución global que representan los dispositivos entre los servicios. Quizá todo lo que he dicho hasta ahora no tenga mucho sentido para ti, pero si continuo con esta explicación angostica, vale para cualquier fabricante, podrás comprender mucho mejor de que trata todo esto, para que sirve y cual es su misión. Los gemelos digitales de Azure Digital Twins son diferentes de los dispositivos gemelos de IoT Hub. Los dispositivos gemelos de IoT Hub a menudo se centran en describir los aspectos y funcionalidades de un dispositivo, mientras que los gemelos de Azure Digital Twins son representaciones conceptuales que pueden almacenar información definida por el usuario sobre un dispositivo o muchos dispositivos relacionados.

Teoría y conceptos principales Azure Digital Twins(2/11) Un poco de
historia. El concepto de Digital Twin fue por primera vez descrito por Dr. Michael Grieves de la Universidad de Michigan en The Society Manufacturing Engineering de 2002. Lo llamó originalmente Modelo de espacios reflejados (Mirrored Spaces Model, MSM), pero el nombre evolucionó y el termino final de Digital Twins, se le atribuye a John Vickers de la NASA. Ambos observaron que los avances tecnológicos en productos y activos físicos estaban haciendo que los sistemas fueran más complejos. Las nuevas tecnologías también trajeron nuevas capacidades, como la comunicación, que no podrían tener cabida en los espacios físicos (mecánicos y electrónicos). Estas capacidades aumentaron la complejidad de los sistemas y requerimientos, que además que requirieron mecanismos para mitigar la complejidad del sistema proporcionando información mejoras sobre el producto físico o entidad: Datos Información Gemelo físico Gemelo digital

Teoría y conceptos principales Azure Digital Twins(3/11) MSM proporciona información
sobre el enfoque de Grieves para tener un gemelo digital (espejo) de un gemelo físico a través del flujo de datos, desde el producto físico a la instancia digital, y luego como esta información se intercambia y se envia de regreso al dispositivo físico. El gemelo digital es la construcción de la información del gemelo físico. La intención del gemelo digital es que pueda proporcionar la misma o mejor información que la que podría obtenerse estando en posesión física del gemelo físico. El supuesto clave es que el tipo, la granularidad, y cantidad de información contenida en el gemelo digital es impulsada por los casos de uso. Traducción libre de Virtually Intelligent Product Systems: Digital and Physical Twins. De Michael Grieves. Existen tres conceptos claves que caracterizaron a los primeros gemelos digitales: • DTP, prototipo de gemelo digital. Es el tipo o modelo de representación del gemelo físico. Tambien se le conoció como versión de diseño con todas sus variantes. Es decir, un molino de viento, por ejemplo, es un modelo único de descripción e información para el modelo específico de molino de viento. Solo hay un DTP o modelo, pero varias bombas pueden usar la misma descripción de modelo. Es decir, la instancia en programación orientada a objetos.

Teoría y conceptos principales Azure Digital Twins(4/11) MSM proporciona información
sobre el enfoque de Grieves para tener un gemelo digital (espejo) de un gemelo físico a través del flujo de datos, desde el producto físico a la instancia digital, y luego como esta información se intercambia y se envia de regreso al dispositivo físico. El gemelo digital es la construcción de la información del gemelo físico. La intención del gemelo digital es que pueda proporcionar la misma o mejor información que la que podría obtenerse estando en posesión física del gemelo físico. El supuesto clave es que el tipo, la granularidad, y cantidad de información contenida en el gemelo digital es impulsada por los casos de uso. Traducción libre de Virtually Intelligent Product Systems: Digital and Physical Twins. De Michael Grieves. Existen teres conceptos claves que caracterizaron a los primeros gemelos digitales: • DTP, prototipo de gemelo digital. Es el tipo o modelo de representación del gemelo físico. Tambien se le conoció como versión de diseño con todas sus variantes. Es decir, un molino de viento, por ejemplo, es un modelo único de descripción e información para el modelo específico de molino de viento. Solo hay un DTP o modelo, pero varias bombas pueden usar la misma descripción de modelo. Es decir, la instancia en programación orientada a objetos.

Teoría y conceptos principales Azure Digital Twins(5/11) • DTI, instancia
de gemelo digital. Es cada instancia de cada entidad física, basada en el DTS. Podemos tener 10 molinos de viento, y cada molino puede tener representar una única instancia, que se basa en el DTP común y específico para ese modelo de molino de viento. Es posible tener solo una instancia basa en un solo modelo (1 a 1), por ejemplo, sería un edificio, solo habrá un DTI y un DTP. Por si acaso, si re realiza un cambio en un DTP será necesario actualizar el DTI para mantener la fidelidad con la instancia del prototipo. Para evitar tener un modelo 1 a 1, Grieves introducir la agregación de instancias (si veis todo muy OOP). DTP (JSON) Entidad Física DTI DTA

Teoría y conceptos principales Azure Digital Twins(6/11) • DTA, agregado
de gemelo digital. Es una colección agregada de DTI y otros DTA. Los DTI pueden existir independientemente de otras instancias, pero los DTA no. Un DTA puede proporcionar información adicional sobre el comportamiento del agregado, que nos de puede lograr con una vista a nivel de instancia. Por ejemplo, si monitorizamos la temperatura de una sala que consta de varios sensores de temperatura, el DTA nos dará la media de la sala completa. Por tanto, nos dará una vista completamente diferente. En 2012, la NASA describe el gemelo digital multi-físico, multi-escala, probabilístico, simulación de ultra alta fidelidad, que refleja el estado del gemelo correspondiente basado en datos históricos, datos de sensores en tiempo real y un modelo físico. A raíz de estos tres conceptos básicos, han surgido otros gracias a proveedores, investigadores y analistas. ¿Qué es un gemelo digital? Según el proveedor tendrás una definición, por eso puse la de Microsoft y posiblemente te quedaste igual o peor de lo que estabas, pero gracias al ejemplo histórico anterior, ya habrás entendido que es un gemelo digital. Pero la importante es la definición del Digital Twin Consortium:

Teoría y conceptos principales Azure Digital Twins(7/11) Un gemelo digital
es una representación virtual de entidades del mundo real y procesos, sincronizadas a una frecuencia y fidelidad específicas. Los gemelos digitales pueden representar el pasado, presente y simular el futuro previsto. Los sistemas de gemelos digitales transforman el negocio acelerando lo comprensión holística, toma de decisiones óptima y acción eficacia. Los gemelos digitales están motivados por los resultados, se adapta a los casos de uso, se basa en integración, se basan en datos y se implementan por sistemas de IT/OT. Y yo propongo la mía, para que se entienda mejor con Azure Digital Twins: Un gemelo digital es una instancia sincronizada de una plantilla o modelo digital que representa una entidad en todo su ciclo de vida y es suficiente para cumplir con los requisitos de un conjunto de casos de uso dado. Como veis mi definición hace uso de la entidad, ya que no tiene por qué ser algo físico. Sin embargo, tanto Grieves y Vickers solo se centraban en un modelo físico.

Teoría y conceptos principales Azure Digital Twins(8/11) Como no pretendo
dar una clase magistral sobre producción, solo quiero hacer mención de la diferencia entre ciclo de vida de una entidad y ciclo de vida del desarrollo de un gemelo digital: Las entidades físicas, productos, activos, tienen un ciclo de vida que va desde la planificación, pasando por diseño, fabricación, mantenimiento, hasta la retirada (y más paso que me he saltado). Mientras que le ciclo de vida del desarrollo comprende el desarrollo físico del gemelo y su correspondiente digitalización. Tipos de gemelos digitales. Fundamentalmente con o discretos o compuestos. Discreto Entidad única o atómica Composición atómica Composición de elementos discretos Compuesto Composición de elementos compuestos

Teoría y conceptos principales Azure Digital Twins(9/11) Características de un
gemelo digital. Estado: operaciones físico Gemelo físico Proceso físico Entorno físico Sincronización Datos Entorno Virtual Estado: información digital Proceso virtual Gemelo Digital

Teoría y conceptos principales Azure Digital Twins(10/11) ¿Por qué un
gemelo digital? Los sistemas digitales transformar las empresas al acelerar la comprensión holística: optima toma de decisiones y acciones eficaces. Se reduce la complejidad para mejorar la comprensión. Objetivo inicial. Pero además la sincronización entre entidades físicas y virtuales, proporcionan más información a problemas específicos con una mayor perspectiva mayor, nos proporciona conciencia. Un mayor conocimiento del comportamiento simulado y el tiempo real que nos ayuda a tomar decisiones más rápido. Los conocimientos adquiridos por los gemelos digitales suelen ser más fiables que ellos enfoques tradicionales: la integración de datos y la consolidación del enfoque del gemelo digital, nos aporta información más completa, confiable y mejora la calidad de las decisiones tomadas sobre los datos. Esto también nos permite automatizar esta toma de decisiones. Las empresas cada vez más están obligadas a trabajar en tiempo real (casi tiempo real), ya que están cada vez más expuesta a eventos internos y externos que les obliga a responder inmediatamente. Estos eventos pueden provenir de diversas fuentes: acciones de personas, de competidores, de legislaciones, averías, fallos, eventos meteorológicos o naturales, la información proveniente de IoT, entre otras muchas.

Teoría y conceptos principales Azure Digital Twins(11/11) Por extensión los
gemelos digitales mejoran los resultados comerciales desde varios frentes: • Industrial. Mejoras en una planta eólica o calidad de fabricación en las baterías de almacenamiento, … • Procesos. Optimización de la distribución de la energía. • Reducción de costes. • Mejora en la esperiencia de clientes. • Mejoras de cumplimiento y riesgo. Por qué puede afectar y afectan en la transformación empresarial, mejorando la digitalizando, aportando valor añadido habilitando nuevos modelos de negocio e identificando oportunidades. Claro esta que por si mismo no hacen dada de esto, lo hacen mediante el análisis y estudio de los datos. Esta parte dedicada a Azure Digital Twins, no podré entrar tanto en profundidad. Con los encales a la documentación, la introducción histórica y el ejemplo, te habré puesto en la linea de salida para que puedas entender el potencial de este recurso y sus posibles implicaciones en un proyecto de IoT.

Ejemplo paso a paso Azure Digital Twins(1/12) En este caso
vamos a representar una planta eólica de un país y las regiones correspondientes, para ver como se representaría todo esto en Azure Digital Twins. Los datos generados debemos pasarlos por alto, ya que no se pretende simular un entorno 100% real. Microsoft nos proporciona una gran cantidad de información que debes explorar, como por ejemplo el SDK y el lenguaje de definición de modelos digitales (DTDL). csharpDigitalTwins – Pongámonos manos a la obra

Ejemplo paso a paso Azure Digital Twins(2/12) Creamos el recurso:
az dt create --dt-name {name digital Twins} -g {name resource group} -l westeurope Si tienes problemas con el usuario debes tener en cuenta que el usuario debe estar asignado, una opción sencilla es crear el recurso Digital Twin desde el portal y marcar la casilla, si no puedes, es por problemas de AAD. Cogemos la URL y nos la guardamos para cambiar el fichero appsetting.json de CreateDTScenario:

Ejemplo paso a paso Azure Digital Twins(3/12) Ejecutamos el proyecto
CreateDTScenario, genera:

Ejemplo paso a paso Azure Digital Twins(4/12) Que esta basado
en: Modeling and Control of Wind Turbine Wind Farm 1 Wind Turbine 1 Tower 1 Rotor 1 Nacelle 1 Gear 1 Generator 1 Wind Turbine 2 Wind Turbine 3

Ejemplo paso a paso Azure Digital Twins(5/12) Pasa un tiempo
probando los menú y acciones del diseñador visual para que te familiarices, por ejemplo, añadiendo relaciones a mano o lanzando consultas:

Ejemplo paso a paso Azure Digital Twins(6/12) Arquitectura de la
solución: Physical device Gearbox 11 (BearingTemp telemetry) IoT Hub Gearbox 11 (Temperature telemetry) Azure Function ProcessIoTHub2DTEvents (Process Telemetry) Telemetry messages Azure Digital Twins Gearbox gearbox11 Nabelle nabelle11 Digital Twin gearbox11 (BearingTemp telemetry) PartOf Event Gird Filter events going to gearbox11 and ProcessDTRoutedData Property change notifications Telemetry events Azure Function ProcessDTRoutedData Set temperature to navelle11 function-event-subscription

Ejemplo paso a paso Azure Digital Twins(7/12) Para ello debemos
crear los siguientes recursos: 1. az eventgrid topic create -g {name resource group} --name windfarmeventgrid -l westeurope 2. az storage account create -n windfarmsa -g {name resource group} -l westeurope --sku Standard_LRS 3. az functionapp create --consumption-plan-location westeurope --name windfarmfa --resource-group {name resource group} --storage-account windfarmsa 4. az functionapp identity assign --resource-group {name resource group} --name windfarmfa 5. az dt role-assignment create --dt-name {name digital Twins} --assignee “Principal ID" --role "Azure Digital Twins Data Owner" 6. az functionapp config appsettings set --resource-group {name resource group} --name windfarmfa - -settings "ADT_SERVICE_URL=https://{your Azure Digital Twins instance host name}"

Ejemplo paso a paso Azure Digital Twins(8/12) Despliega de AdtBackend
la Function que hemos creado antes:

Ejemplo paso a paso Azure Digital Twins(9/12) Conectamos un evento
en IoT Hub:

Ejemplo paso a paso Azure Digital Twins(10/12) Conectamos: 1. az
dt endpoint create eventgrid --dt-name {name digital Twins} --eventgrid-resource-group {name resource group} --eventgrid-topic windfarmeventgrid --endpoint-name endpoint 2. az dt endpoint show --dt-name {name digital Twins} --endpoint-name endpoint 3. az dt route create --dt-name {name digital Twins} --endpoint-name endpoint --route-name route Enviamos la información del Event Grid Topic windfarmeventgrid a la function: 1. Entrar en windfarmeventgrid 2. Añadimos una nueva suscripción 3. En tipo de endpoint seleccionas una Azure Function. 4. Seleccionas ProcessDTRoutedData. 5. Confirmas y guardas.

Ejemplo paso a paso Azure Digital Twins(11/12) Conectamos: 1. az
dt endpoint create eventgrid --dt-name {name digital Twins} --eventgrid-resource-group {name resource group} --eventgrid-topic windfarmeventgrid --endpoint-name endpoint 2. az dt endpoint show --dt-name {name digital Twins} --endpoint-name endpoint 3. az dt route create --dt-name {name digital Twins} --endpoint-name endpoint --route-name route Lanzamos el simulador, entramos en la solución simulator, cambiamos las configuraciones y ejecutamos: 1. Crear en IoT Hub un Device llamado: gearbox11 y coger la cadena de conexión. 2. Modificar la cadena en el proyecto. 3. Ejecutar. Ejecuta ObserveDTScenario y mira como se va actualizando el valor del dispositivo en Digital Twin. Si necesitas depurar el Azure EventGrid en local puedes seguir este tutorial. A continuación, se muestran unas capturas donde se puede observar que el valor va cambiando en el UI de Azure Digital Twins.

Ejemplo paso a paso Azure Digital Twins(12/12) Os dejo un
ejemplo muy completo que os podrá servir de ayuda por la gran cantidad de código que tiene. Y el anterior ejemplo es un caso de uso de este otro, si tuvieras algun problema, nada más fácil como seguir estos enlaces: uno y dos (importante script de deploy). Dispositivo simula un cambio de temperatura en el rodamiento Llega a IoT Hub y un evento genera una llamada a la function La Function IoT2DtEvent, manda la información del IoTHub a un evento de Digital Twins: esto es lo imporante, ya hemos llegado a Azure Digital Twin. Una nueva función enlazada con el evento anterior podría cambiar propiedades o asignar telemetría del Digital Twin, para que lo veas en la visualización de DT. Con los eventos de DT puede lanzar la información a un Event Hub, Event Grid o Service Bus. En este codigo que gestiona esta parte podrás hacer tu logica de negocio: establecer alertas como BearingAlert en el componente DT superior.

Ejemplo paso a paso Azure Digital Twins e IoT Central(1/9)
A través de una canalización vamos a proveer datos a Digital Twins y nuestro proveedor será IoT Central. Con este ejemplo vamos a ver como integrar con un mínimo código ambos recursos. La arquitectura necesaria será la siguiente: La conexión entre Azure Service Bus e IoT Central se basa en una cadena de conexión generada por una política de acceso compartido. Una política de acceso compartido es una firma que permite a una aplicación conectarse a un servicio específico de Azure durante un tiempo y permisos definidos. La exportación de Azure Function se usará para leer los mensajes del Service Bus y dejarlos en la instancia conectada de Digital Twins. csharpDigitalTwinsIoTCentral – Jugando con las dos aplicaciones SaaS Azure Pipeline Physical device Temperature IoT Central Digital Twin Service Bus Azure Function

Creamos un Azure IoT Central:

Creamos un Service Bus y una cola:

Establecemos una shared access policies al service bus:

Volvemos a IoT Central para añadir una nueva Data Export:

Observamos en Azure Service Bus que los datos empiezan a llegar:

Creamos un Azure Data Twins que pueda procesar esa información:

Entramos en la carpeta modelDTBase y cargamos el modelo creado con DTDL en Digital Twins, quiero que este ejemplo sea con el mínimo de codigo posible: { "@id": "dtmi:com:patientRoom:Sensor;1", "@type": "Interface", "@context": "dtmi:dtdl:context;2", "displayName": "Sensor", "contents": [ { "@type": "Property", "name": “DeviceTemperature", "schema": "float", "writable": true } ] }

Ejecutamos la Function en local llamada sendTemeletryIoTCentral2DT: Recuerda que debes hacer login desde el CMD con Az Login. Y establecer la suscripción.

Si deseas saber más – Solo tienes ponerte manos a
la obra Workshop… Leveraging Azure Digital Twins in a supply chain Os dejo un enlace a un workshop de Microsoft que os muestra como crear una solución de Digital Twins de extremo a extremo. https://github.com/microsoft/MCW-Leveraging-Azure-Digital-Twins-in-a-supply-chain El repositorio original y es el que os recomiendo usar para el workshop, podéis usar el fork que he realizado en mi cuenta de GitHub, por si en algun momento deja de estar disponible.

Observa como el valor de la telemetría está cambiando en el gemelo digital:

Windows 10 IoT Core Un sistema 100% Windows(1/3) Windows IoT
Core es una versión de Windows 10 optimizada para dispositivos pequeños con o sin pantalla, y que podrás ejecutar en procesadores con arquitectura ARM, x86 o x64. La documentación de Windows IoT Core, la tienes disponible en este enlace. Aquí se explica como instalar Windows IoT Core y en este otro enlace, como instalar una aplicación. Tendrás que investigar como acceder al GPIO y para ello nada mejor que un ejemplo. Y todo lo referente a Windows IoT Core, esta página era para que tengas en el radar este recurso. Prototipos en Windows – Si no te apetece usar Linux, tienes otra opción

Logicamente es la evolución de Windows IoT (no existe la
coletilla 10 en la versión enterprise hasta ahora). La diferencia fundamental que tiene con un sistema operativo estandar es que muchos modulos innecesarios se pueden eliminar como son los packs de lenguajes, aplicaciones de medios, drivers de pantallas, la calculadora, salvapantallas, … que permiten hacer los pasos necesarios para dejar este sistema operativo personalizado en nuestras implantaciones. Ya que debes seguir siempre estos pasos: • Configurar. • Personalizar. • Construir. • Desplegar. Como novedades: • Lleva asociado un subsistema Linux GUI • Soporte USB 4.0 y Wi-Fi 6E • La nueva interface de Windows 11. Este tipo de sistema operativo nos permite un control mayor en acciones remotas, es LTSC (es decir soporte de unos 10 años) y es más económico que una visión estándar. Como recomendación para todos estos sistemas operativos, es que siguas la pagina de actualización del ciclo de vida. Basado en IoT 10 Enterprise – La evolución Windows IoT Enterprise ahora en versión 11 Un sistema 100% Windows(2/3)

Aproximadamente sigue el mismo patrón que la versión Windows IoT
11 Enterprise: • Soporte para 10 años, aprox. • Permite una personalización y despliegue personalizado. • Es más económico. • Etc. En este caso, el uso debería diferir un poco con respecto al anterior, el anterior debería usarse para conectar actuadores, establecer las rutinas de Edge, etc. Y conectar con el Server. Es decir, un Server debería actuar como concentrador. Es decir: • Capacidad extendida de administración. • Actuar de router de Azure IoT. • Actuar como capa segura gracias al secured-core server y protocolos. • Permitir el uso de Azure Arc para conectarse a entornos híbridos. • Compresión SMB para hacer más ligeras las transacciones. Y tal y como sucede en su hermano menor solo podrás licenciarlo en el canal OEM. Que sepáis que existen estas dos versiones, pero casi con seguridad usareis la version Core para vuestras pruebas, las otras si llegáis a usarlas, es por qué realmente estáis metidos en un proyecto de verdad. Capacidad empresarial – Más o menos lo mismo que Windows IoT Enterprise Windows Server IoT 2022 Un sistema 100% Windows(3/3)

Sistema operativo en tiempo real de Azure foro RTOS Azure
RTOS Otra de las herramientas a tener en el radar es esta. Ya que nos permite simplificar el desarrollo y conectividad del IoT. Toda la información la tienes en este enlace. Y a modo informativo es: En sistema operativo en tiempo real par IoT y perimetral con tecnología de microcontroladores diseñado para dispositivos altamente restringidos (con batería y menos de 64kB). Y certificado por normas IEC e ISO. La plataforma es un compendio de componentes RTOS: ThreadX, FileX, GUIX, NetX, … Una serie de siglas que en los enlaces anteriores explica muy bien y no esta demás que sepas que existe. Además, tenemos de nuestro propio estudio de desarrollo:

Un hardware de Microsoft Azure Sphere y Percept Hardware dedicado
Simplemente os pongo dos enlaces al hardware dedicado de Microsoft que nos permite trabajar con IoT de forma más simplificada. Azure Spehere, para uso exclusivo de IoT Azure Percept, que nos permite trabajar con servicios IA

Facilitando C# en sistemas embebidos .NET nanoFramework Open Source Un
proyecto que si os metéis en esto del IoT debéis vigilar muy bien es: Plataforma gratuita y de codigo abierto que permite la escritura de aplicaciones de codigo administrado y dispositivos integrados restringidos (si como RTOS). Es adecuado para diversos tipos de sensores IoT, dispositivos portátiles, PoCs, robótica, etc. Nos permitirá hacer un desarrollo más sencillo, rápido y menos costoso, ya que nos da acceso a las herramientas de desarrollo como Visual Studio, se integra con el. Antes os conté que necesitabais Python por que era más sencillo acceder a los protocolos del Hardware, pues, ahora bien, desde esta lista de dispositivos podrás observar que el sensor de temperatura BME280 esta en la lista y con un ejemplo para que puedas utilizarlo. Te dejo a ti seguir investigando o incluso unirte a la comunidad.

Si aun no tienes el hardware… PoC Tras haber visto
los ejemplos anteriores, en la siguiente sección vamos a implementar la PoC que hemos diseñado en la Sección 3. Puedes tranquilamente saltarte lo que resta de sección e ir directamente a la Sección 5. Si no, acompáñame con la PoC. Gran parte de la PoC la puedes emular tanto con valores aleatorios como con imágenes libres que te puedas haber descargado de internet. Es decir, el hardware es adicional, pero no voy a mostrarlos la versión aleatoria, a partir la versión contra hardware real te tocará modificarla para que cumpla con los requerimientos que nos habíamos planteado. Es más, si lo deseas puedes evitar hasta el uso de una Raspberry Pi y ejecutarlo todo en Windows. Emular – Una opción más barata

La PoC debe quedar en stand-by. Continua con el resto
del libro. Muchas de las piezas que verás más adelante se va a utilizar en este ejemplo. Esta PoC seguirá un camino a parte en GitHub con su propio repositorio, README y Wiki, para acceder al repositorio: PoC… https://github.com/jmfloreszazo/PoC-HandsOnIoTAzure

Sección 5 Seguridad

¿Por qué necesitamos seguridad? Introducción(1/2) Los datos son el corazón
y el alma de los servicios de IoT. Los datos se han convertido en el producto más buscado. Es la fuerza que impulsa la nueva ciencia y es el quid de las estrategias de monetización de la industria actual. En IoT los dispositivos generan muchos datos y muy valiosos, que pueden ayudar a las empresas a comprender a sus clientes y mejorar su actividad. Con el aprendizaje automático e IA, los servicios de IoT escuchan y detectan continuamente para predecir las necesidades futuras de sus usuarios. La seguridad de los sistemas informáticos e Internet es algo que no se discute; ya debería estar en el ADN de cada producto y cada acción. En IoT es un punto mucho más crítico, los dispositivos recopilan, almacenan y comunican datos de naturaleza extremadamente sensible, ya sean de una persona o una máquina. Dependiendo de la naturaleza del dispositivo IoT, esos datos pueden ser telemetría de un robot de una fábrica, telemetría que emite tu reloj inteligente, datos bancarios, parámetros de seguridad de un dispositivo, datos de rendimiento y uso de un vehículo, etc. Si los servicios de IoT son hackeados, la repercusión puede ser mucho más severa que en el caso de un servicio de computación tradicional. Los usuarios de IoT estamos expuestos a: • Robos. Los dispositivos de IoT de relojes y teléfonos inteligentes exponen a los usuarios a una multitud de amenazas de seguridad. Cuando se usan para transacciones monetarias, los usuarios pueden exponer sus credenciales financieras a los atacantes o si se usan para acceder a un vehículo o en el hogar pueden verse afectados por robos. Tambien podemos ser objeto de un robo por derivación de la información emitida por un medidor de consumo de agua, gas o electricidad en nuestro hogar. Todo debe girar en todo a la seguridad – Máxima que aplico en mi día a día

¿Por qué necesitamos seguridad? Introducción(2/2) • Privacidad. Ya he mencionado
que los dispositivos IoT recopilan mucha información de naturaleza personal. Los dispositivos como Alexa, Google Home, etc. siempre están escuchando, y los sistemas de seguridad del hogar siempre están capturando información tanto en audio como video. Si el atacante obtiene acceso a sus grabaciones y videos, lo habitual que te pidan un rescate o corren el riesgo de divulgar públicamente estos datos. O bien esos datos pueden ser explotados para obtener un perfil de usuario y saber cuando hacer la intrusión en el sistema. • Seguridad. Tener la capacidad de controlar y manejar un dispositivo IoT puede permitir a los atacantes causar daños a los usuarios. Esta documentada el acceso no autorizado a marcapasos para exigir rescates. Toda aquella casa que disponga de una cerradura inteligente está comprometiendo su seguridad ya que son un punto de entrada para ladrones. Todos aquellos usuarios de coches con conectividad y procesamiento digital están expuesto a atacantes que pueden controlar prácticamente cualquier función del vehículo. • Productividad. Los usuarios de IIoT e IoT Empresarial están expuesto a pirateos que pueden causar perdidas de ingresos y productividad. La interrupción de una cadena de fabricación puede producir un efecto en cascada en la cadena. Piratear un detector de humos de una oficina que active los extintores de agua puede inutilizar una oficina. O el archiconocido ataque DDoS que puede provocar que se impida acceder a los recursos, por ejemplo, enviar ciento de millones de peticiones simulando decenas de miles de relojes inteligentes puede hacer caer la red de un fabricante y dejar de prestar servicios a los usuarios. Esto es solo la punta de iceberg del por qué debe preocuparnos la seguridad en el ámbito del IoT.

Metodología Ciclo de vida de la seguridad(1/17) Como casi con
cualquier producto de IT, la seguridad debe estar presente desde la fase de inicio de un producto o características. Durante la fase de planificación o implementación de un producto de IoT, ya sea una nueva característica o un producto nuevo, esta fase requiere de una evolución de la tecnología a usar para la producción, seguridad que ese implementará en el diseño, un analisis de las conformidades (compliances) de acuerdo a las zonas geográficas donde se ofrecerá el servicio IoT (GDPR en EU o la CCPA de California), potenciales vulnerabilidades y por supuesto definir un equipo responsable para abordar los problemas de seguridad del servicio de IoT. Una vez finalizada la fase de implementación, se debe comenzar a integrar las medidas de seguridad en el dispositivo y en lo servicios de IoT. Para esta acción, todas las partes interesadas, deben capacitarse para abordar los procedimientos de seguridad. Esto actores deben esta capacitados para seguir las mejores practicas para configurar y asegurar correctamente los dispositivos IoT. Es cuando debemos establecer las claves de seguridad y los certificados. Y posteriormente configurar la seguridad y parámetros para buscar puntos de ruptura. La gestión de incidentes y protocolos también se deben definir en esta etapa. A continuación, el producto de IoT o función del servicio asociada, entra en el entorno operativo. Esta etapa se caracteriza por que los responsables deberán: estar pendientes de la autenticación de los dispositivos, de la integridad de los datos, de evitar dispositivos repudiados y actuar en consecuencia, la confidencialidad, disponibilidad del servicios, acceso y roles, etc. Etc. Los servicios y los dispositivos deben tener un mantenimiento. Desde el inicio –La seguridad comienza a implementarse desde el principio

Metodología Ciclo de vida de la seguridad(2/17) Durante esta etapa
de mantenimiento, se deben implementar las actualizaciones para proteger los dispositivos de IoT ante amenazas emergentes y de forma constante. Logicamente los dispositivos de IoT y sus datos deben mantenerse en funcionamiento de la forma prevista. Y deben llevarse a cabo analisis forense de seguridad para detectar intrusiones y brechas de seguridad. Estas etapas del ciclo de vida de IoT continúan cíclicamente hasta que se interrumpe el servicio de IoT. Una vez que la interrupción del servicio de IoT se planifica, los usuarios deben ser notificados. Todos los datos asociados deben ser purgados y retener la información el tiempo que el cumplimiento así lo permita. El producto de IoT debe tener un protocolo de eliminación. Esto, además, no lleva a tener un nivel de acuerdo un SLA para restringir o cancelar el acceso a los servicios a los dispositivos para que no puedan continuar operando, al final esto podría ser un punto de entrada para usuarios maliciosos.

Metodología Ciclo de vida de la seguridad(3/17) Integración de Seguridad
• Entrenamiento de seguridad • Obtenga claves y certificados de seguridad • Configuración de seguridad • Monitoreo de seguridad • Pruebas de penetración • Protocolos de respuesta y gestión de incidencias Plan e Implementación • Nuevo producto o característica • Evaluación de tecnología • Diseño seguro • Evaluación del cumplimiento • Modelado de vulnerabilidades y amenazas • Configurar roles y responsabilidades del equipo de seguridad Operar Servicios de IoT • Autenticación de dispositivo • Integridad de los datos • No repudio • Confidencialidad • Disponibilidad • Gestión de acceso • La privacidads Mantener Infraestructura IoT • Protocolos de actualización seguros • Gestión de Devie • Manejo de datos • Análisis forense de seguridad • Gestión y respuesta a incidencias Interrupción Planificada • Notificar a los usuarios • Mantenimiento, eliminación y eliminación de datos • Interrupción de la inversión • Eliminación física de dispositivos de IoT • Deshabilitación remota del dispositivo IoT Este Ciclo de Vida es el que guía la estructura del libro

Metodología Ciclo de vida de la seguridad(4/17) Implementación de la
seguridad IoT El ciclo de vida de un producto IoT o una nueva funcionalidad, es una etapa crítica del ciclo de vida. Se deben tomar decisiones esenciales que pueden ayudar a evitar puntos débiles en la seguridad que afectaran en el futuro, cuando este operativo. Esta son las actividades involucradas en la planificación e implementación: • Nuevo producto o características: es cuando se desarrolla una prueba de concepto y prototipos para evaluar la viabilidad del producto IoT. Basado en el prototipo, el dispositivo IoT se fabricará en masa una vez identificados los requisitos y limitaciones tecnológicas. Este punto va de la mano con la evaluación tecnológica. La propiedad intelectual, maras, derechos de autor y patentes es un punto de brecha de seguridad que se da en esta fase y que habitualmente entra en conflicto con las subcontrataciones de la fabricación en masa. Existe otro tipo de hackeo al que estamos expuestos que debe tener en cuenta. Lo normal es que se exija un NDA (acuerdos de no divulgación) que prohíbe compartir información confidencial y patentada. • Evaluación tecnológica: en el desarrollo de un producto IoT o servicio, la evaluación de la tecnología juga un papel clave, y su impacto en el ciclo de vida es decisivo. Esas decisiones implican:

Metodología Ciclo de vida de la seguridad(5/17) - Hardware para
la construcción del dispositivo. - Software que ejecutará el dispositivo. - Plataformas de desarrollo e interface de aplicaciones (API) que usaran los dispositivos IoT. - Elección de proveedor de servicios en la nube para IoT, ya sean privados, públicos o híbridos. - Elección de la tecnología de red que usaran para comunicaciones entre dispositivos IoT, servicios de backend, etc. Esto lo veremos más adelante. - API de seguridad y métodos que se usaran para administrar la autenticación de usuarios, la integridad de los datos, evitar rechazos, confidencialidad, etc. • Secure by desing (SBD): vendría a ser algo así seguro por diseño; es una filosofía que significa que la planificación del diseño de cada producto o servicio de IoT debe comenzar teniendo en cuenta la seguridad, seria como la frase que digo habitualmente de todo debe girar en torno a la seguridad. El paradigma SBD es muy extenso y aquí os dejo unas pinceladas: - Establecer los valores de seguridad predeterminados; restringir el acceso a los usuarios de las aplicaciones hasta que se les conceda acceso, es decir que los usuarios obtengan accesos y privilegios via contraseñas, tokens, certificados, etc. - Los servicios de IoT y los dispositivos, tienen muchas características que deben ser bloqueadas por grupos, perfiles, etc. Logrando reducir la superficie de ataque. - Cuando un dispositivo o servicio IoT experimenta un comportamiento inesperado, fallos o bugs, se debe evitar revelar información de los sistemas subyacentes.

Metodología Ciclo de vida de la seguridad(6/17) - Las aplicaciones
de IoT deben implementar diversas capas de seguridad. Un ejemplo sería usar multifactor. - Se deben ofrecer diversos niveles de privilegios a diferentes conjuntos de usuarios. - Reducir los privilegios es una forma eficaz de frenar violaciones de seguridad. Los usuarios deben poseer privilegios mínimos para realizar las funciones necesarias de IoT y solicitar los privilegios adicionales cuando sean necesarios. - Usar APIs de terceros puede aumentar la funcionalidad del servicio, pero también aumenta de forma drástica la superficie de ataque. Por tanto, este tipo de práctica en IoT es desaconsejable. - Para terminar, por que esto podría ser inacabable, los diseños que realicemos para la seguridad deben ser simples (KISS) para poder reaccionar de forma rápida y mantener la actividad de nuestros servicios y dispositivos. • Evaluación de cumplimientos: se debe evaluar todos y cada uno de los cumplimientos regulatorios a los que han de adherirse, ya sea por que tenemos ecosistemas que estarán usando diversas ubicaciones geográficas y por tanto implica a cumplimientos legales con gobiernos o bien por el carácter del dato. Seria la GDPR en Europa y manifestar en el servicios y dispositivo que estamos recopilando datos, dando la opción al borrado de esos datos. Por ejemplo, aunque estemos en Europa, Alemania exige que los datos estén en su territorio. Tenga cuidado con esto. • Modelado de vulnerabilidades y amenazas: es un ejercicio de precaución. Nos da la oportunidad de catalogar las posibles áreas de ataque y probar si actuamos en consecuencia ante la amenaza en el ecosistema. • Configurar los equipos de seguridad: debe existir un grupo de seguridad con sus roles y responsabilidades y todos deberían trabajar en consonancia para solucionar e intervenir ante problemas de seguridad.

Metodología Ciclo de vida de la seguridad(7/17) Integración de las
medidas de seguridad La organización debe preparar a los usuarios , empleados y cualquier ente relacionado con el proyecto en las medidas de seguridad apropiadas. Se deben obtener las claves de seguridad, los certificados han de ser desplegados, se debe probar de forma proactiva las posibles lagunas de seguridad, se debe administrar los incidentes, implementar los protocolos, etc. Los protocolos han de ser la guía fundamental para recuperarse ante una brecha de seguridad y mantener los servicios de IoT en funcionamiento. Esta son las actividades involucradas: • Capacitaciones de seguridad: todas las partes interesadas en un ecosistema IoT se deben beneficiar de esta formación. Capacitar a los empleados, usuarios, operadores, desarrolladores, ... puede reducir el riesgo. Que se debe tratar en la capacitación: - El phishing es una de las formas habituales de introducir software malicioso en IoT. Habitualmente el clic en un enlace de un correo o la descarga de un fichero con malware. Todos los actores deben conocer y reconocer este tipo de ataque.

Metodología Ciclo de vida de la seguridad(8/17) - La ingeniería
social que aprovecha los errores humanos para obtener acceso a IoT. Se debe capacitar al personal para abstenerse de divulgar información tanto a entidades como a personas no confiables. Tampoco debemos dejar dispositivos IoT conectados y desbloqueados o desatendidos. - Las partes interesadas deben esta capacitadas para para informar de incidentes de seguridad cuando lo identifican en base a un procedimiento o metodologia o mejores prácticas. - Debe existir una comunicación periódica sobre las mejoras introducidas en las prácticas de seguridad debido a avances, modificaciones o refinamientos. • Obtención de claves y certificados de seguridad: para validar la identidad de un servicio IoT, el proveedor de servicios obtiene un certificado digital de empresa u organización denominado autoridad certificadora (CA). La CA valida la identidad de los servicios de IoT y los vincula a las claves de seguridad criptográficas del proveedor de servicios IoT (par clave publica y privada, los conocidos PKI) mediante la emisión de certificados digitales. El certificado digital habilita: - Cifrado de datos para transmisión segura a través de un canal seguir de internet. - Autenticación de una entidad sirviendo como credencial que valida la entidad que se esta emitiendo - La integridad de los datos mediante la firma del certificado, para que no se pueda manipular en transito. Actualmente las blockchains a traves de contratos inteligentes permitirán gestionar las operaciones relacionadas con las de dispositivos y servicios IoT, es posible que comente algo en temas avanzados. La aplicación de esta tecnología no esta madura. Y también es incipiente el numero de investigaciones sobre certificados ECQV.

Metodología Ciclo de vida de la seguridad(9/17) • Monitoreo de
seguridad: es la recopilación, obtención y analisis de datos para detectar comportamientos sospechosos o anomalías del sistema de IoT (aquí os adelanto que Azure Defender para IoT será lo que os muestre). Debemos definir que tipos de eventos o comportamientos deben generar alertas y por tanto tomar medidas en consecuencia. • Penetration testing: el objetivo será evaluar la seguridad de IoT. Lo normal es contratar a un equipo externo experto en este tipo de acciones. No voy a explayarme más, si te interesa el tema, encontrarás mucha información en la red. • Protocolos de gestión y respuesta a incidentes: suele ser un conjunto de pautas que el proveedor del servicio de IoT utiliza para identificar, eliminar y recuperase ante un ataque de seguridad. Estan diseñados para facilitar una rápida respuesta a las amenazadas. Solicitante (Proveedor del Servicio de IoT) Solicitud de firma de certificado Certificado digital Solicitante Clave Pública Solicitante Clave Privada Información identificativa Organización, Dominio, Email, ... Autoridad Certificadora (CA) Validar de forma independiente la información y la identidad CA Clave Privada Generar certificado firmado

Metodología Ciclo de vida de la seguridad(10/17) Operaciones en los
servicios de IoT Al entrar los servicios y dispositivos en estado operativo debemos responsabilizarnos del correcto funcionamiento y disponibilidad de acuerdo al SLA. Debemos ser responsables de la autenticación de dispositivos, la integridad de los datos, el no repudio, la confidencialidad, disponibilidad del servicio, el acceso, los roles, … Esta son las actividades involucradas: • Autenticación del dispositivo: es un punto crítico, ya que se confía implica tanto la confianza del dispositivo (por ejemplo, acceso al sistema) como la integridad de datos. Debemos basarnos en que el ID establecido al dispositivo es quien nos permitirá hacer la trazabilidad necesaria para una anomalía o los datos a lo largo de su vida útil o usar es ID para bloquear el acceso al sistema. Por tanto, debemos poder confiar en que ese ID es el que dice ser, el que esta autorizado, en consecuencia, si no lo es, debe ser ignorado y vacunarnos así contra un posible ciberataque. Para autenticar la identidad del dispositivo podemos usar: - Claves simétricas. - Certificado X.509. - Modulo de plataforma confiable (TPM). - Modulo de seguridad (HSM). Los tres primeros son los que nos ofrece Azure IoT Hub. Y un TPM es un tipo de módulo de seguridad de hardware (HSM).

Metodología Ciclo de vida de la seguridad(11/17) • Integridad de
datos: para mantener la seguridad de IoT, es fundamental proteger los datos de modificaciones no autorizadas, como inyección de código malicioso. El código firmado con certificados digitales puede utilizarse para verificar la integridad y asegurarnos que no han sido manipulados o alterados en la transmisión entre dispositivo y servicio. • No repudio: es una prueba indiscutible de la validez y el origen de los datos del IoT que se genera y han trasmitido. Los datos y transacciones firmados digitalmente pueden proporcionar un blindaje al rechazo por la fecha y origen. Aquí vuelve a salir Blockchain como tecnología emergente que evita el repudio. • Confidencialidad: debemos proteger los datos, servicios, etc. de accesos no deseados. El cifrado de datos es necesario para ofuscar la información crítica, como resultado, lo datos sería inútiles aun habiendo tenido una brecha de seguridad. Solo los usuarios autorizados podrán descifrar el contenido. • Gestión de acceso: principalmente sirve par evitar acceso no autorizados por parte de los usuarios. Debido al ecosistema híbrido que es IoT (criptografía, protocolos de encriptación, autenticación, …) y que esta orientado a datos muy sensibles, vas a tener que lidiar entre que nivel de seguridad ofrecemos y que nivel de usabilidad damos. Muchos dispositivos de IoT no tiene un sistema de I/O para ingresar contraseñas de inicio de sesión, por poner un ejemplo y para facilitar esto a veces se usa multifactor o dongles (llaves) seguros, reconocimiento facial, voz, etc. Esto es lo que promueve la FIDO Alliance en vez del uso de password: más problemas que el tipico tira y afloja entre seguridad y usabilidad. Alguna de las tecnológicas que habitualmente se usan son oAuth, PKI, Blochaing, GBA, Open- Id Connect y gestión de e-SIM. Veamos algunas:

Metodología Ciclo de vida de la seguridad(12/17) - Autenticación basada
en contraseña, es el más común. Y poco más que deciros que esto provoca la reutilización de contraseñas, ya que somos humanos y no podemos usar en cada servicio una aleatoria y de alta calidad (números, letras, símbolos y en combinaciones muy dispares, aun menos de 50 caracteres). Esto provoca a que estas claves se vean expuesta en diversos servicios. - Autenticación multifactor añade una capa de seguridad más. Se basa en usar un dispositivo como un teléfono donde llega una clave de seguridad, el uso de un dongle seguro, rasgos biométricos, … tras haber introducido tu contraseña. - Autenticación basada en certificados. Diagrama anterior. - Autenticación basada en tokens, que permiten a los usuarios ingresar una vez las credenciales y luego se recibe una cadena aleatoria única, que permite pasar ese token entre servicios en vez de introducir cada vez las credenciales. - Autenticación biométrica que usa las características del usuario, como la voz, iris, huella digital, retina, etc. Que en contraposición pone en peligro la integridad física en caso de un ataque… causa por la cual se está investigado en algoritmos de detección de actividad (en resumen, que no estes bajo coacción o cosas similares). • Privacidad: se refiere a como los datos del usuario se recopilan, comparten y utilizan. Por ejemplo, la GDPR. Debes construir tu sistema teniendo en cuenta que la privacidad del usuario debe mantenerse durante todo el ciclo de vida, o solo es cumplir un requisito gubernamental, es proteger al usuario y su información ante una violación de seguridad.

Metodología Ciclo de vida de la seguridad(13/17) Mantenimiento de la
infraestructura de IoT Nuestro sistema ya está operativo y estabilizado, ahora debemos mantenerlo en perfecto funcionamiento, es decir, estable y seguro. Se debe implementar actuaciones de seguridad para proteger tanto dispositivos como servicios. Se debe asegurar y mantener que un dispositivo o servicio funcione de la forma prevista y aquí los gemelos digitales son nuestra mejor opción. Se debe llevar a cabo analisis forense con las brechas de seguridad, y si se detectan, llevar a cabo los protocolos de respuesta y actuación al incidente. Esta son alguna de esas acciones de mantenimiento: • Protocolos de actuación: para implementar actuaciones de seguridad debemos tener en consideración: - En caso de error durante un proceso de actuación, el dispositivo IoT debe poder cargar la ultima versión estable y segura conocida. Por tanto: copias de seguridad. - Bloquear versiones con exploits conocidos, para evitar que un hacker cargar una versión con error en un dispositivo y pueda aprovechar esa brecha. - Programar actualizaciones para evitar bloquear el trafico de nuestros servicios. Lo normal en IIoT es usar el tiempo de inactividad.

Metodología Ciclo de vida de la seguridad(14/17) - Las actualizaciones
de firmwares son propensas a vulnerabilidades en transito, es decir debe que viajan del proveedor a tu dispositivo, para ellos se deben usar firmas digitales, por ejemplo. - Si un dispositivo no se actualiza automáticamente y no esta alineado con los servicios, debemos poder hacerlo de forma remota o bloquear su uso hasta que estén alineado. Esto puede usarse para exploits. • Gestión de dispositivos: serían el proceso de aprovisionamiento, autenticación, configuración, mantenimiento, supervisión y desmantelamiento de dispositivos IoT. La administración de dispositivos para que continúen siendo efectivos y confiables. En Azure tenemos DSP (Device Provisioning Service) que veremos más adelante. - Aprovisionamiento e incorporación de dispositivos IoT cuando se conectan a internet y a los servicios de backend por primera vez. Los dispositivos deben estar autenticados y, si se va a confiar en ellos, compartir datos de configuración. Todo esto es posible gracias al uso de certificados o claves previamente compartidas. - Al dispositivo incorporado se le debe configurar de forma predeterminada y especifica para el escenario en el que trabajará. - Tambien debería poder actualizar y mantener, habitualmente firmwares para subsanar errores y añadir mejoras. Es un sistema OTA (on-the-air) que permitirá que el ecosistema permanezca seguro y libre de errores. - Un software de gestión que recopile información de diagnostico. Es decir, monitorizar para sacar estadísticas y localizar brechas de seguridad. Tambien se puede usar para predicciones o reducir el nivel de inactividad de dispositivos IoT. - Una vez que el dispositivo debe retirarse del servicio, el software de administración debe proveer las herramientas necesarias para hacerlo de forma segura. Si por el contrario es un reemplazo debemos procurar que o bien este 100% funcional sin impacto o bien intentar que ese impacto sea el mínimo. Tambien se debe poder destruir claves, certificados, etc. para evitar ingeniería inversa (esto aplica en cualquier fase).

Metodología Ciclo de vida de la seguridad(15/17) • Gestión de
datos: ya hemos dicho que en IoT que es la gestión de datos: la transmisión, almacenamiento o procesado para convertirlos en información crítica o procesable para la aplicación correspondiente. Esta gestión implica desarrollo y arquitecturas que deben nacer con políticas, prácticas y procedimientos que cumplan todo el ciclo de vida, desde la primera adquisición hasta el des-aprovisionamiento y destrucción de datos, es decir de extremo a extremo del ciclo de vida. Y para ello deben garantizar las siguientes funciones críticas: - Los datos se generan por la telemetría o cocinado de datos generado en el dispositivo que se transfieren por internet. - Los dispositivos tienen recursos a veces inexistentes para almacenar datos, pero lo habitual es que puedan almacenarlos durante un breve periodo de tiempo. Esto o bien provoca perdidas o sobreescritura para continuar captando datos. Se debe actuar de la mejor forma para evitar pérdidas datos. Tambien debemos actuar en consecuencia: copias de seguridad tanto en dispositivo como en servicios. - Una práctica habitual es la fusión de datos, es decir, recopilar datos de distintas fuentes o dispositivos y resumirlos o fusionarlos (cocinarlos) para reducir el volumen de los datos transmitidos por el dispositivo o almacenados el servicio. - El software de gestión debe permitir una consulta de datos fluida y legible. - El software de gestión debe poder procesar, eliminar y completar datos, así como gestionar redundancias y fusionar/agregar datos (punto anterior). Logicamente deben ser almacenados para obtener información sobre un histórico, datos “actuales” y predicciones a futuro.

Metodología Ciclo de vida de la seguridad(16/17) • Analisis forense
de seguridad: es la detección y notificación de incidentes y brechas de ciberseguridad en dispositivos IoT, redes que lo conectan, proveedores de servicios en la nube y datos generados, transmitidos, procesados o almacenados. El equipo forense recopila, procesa, documenta y analiza los incidentes. Observan minuciosamente cualquier fase y detectan discrepancias, así como evidencias de una posible acción delictiva. Suelen usarse un gran batería de herramientas, pero actualmente Azure te lo pone más fácil con Azure Defender for IoT. • Gestión y respuesta a incidentes: tras la detección por parte del equipo forense de una incidencia que afecta a la seguridad de IoT. Se debe responder para contener, mitigar los daños y subsanar o recuperarse al incidente. Los pasos habituales son: - Aislar los elementos afectados de forma elegante, es decir, sin degradar el servicio, esto muchas veces no es posible. Debe ser contenida la amenaza lo más rápido posible, así como la reconstitución de las piezas afectadas. Subsanar el sistema. - Tras la eliminación de la amenaza, se debe identificar la brecha. Tras identificarla, podría haber sido un puerto abierto, se debe eliminar esa amenaza y si la naturaleza del problema hace intuir que el problema puede estar propagado, pensar siempre en la peor opción y revisar esa casuística en todo el ecosistema, con esto evitamos el mismo ataque en el futuro. Al final es un parcho del sistema. - Cuando nos recuperarnos y ponemos todo en funcionamiento, nos debemos dedicar a evaluar que todo este estabilizado. Monitorización. - Y como último paso. Documentar detalladamente el incidente. Es para tener una comprensión profunda del porqué del incidente, como se contuvo, erradicó y recuperó. Esa información es valiosa para la organización, para ti y para tus compañeros.

Metodología Ciclo de vida de la seguridad(17/17) Degradación, interrupción y
discontinuación planificada Al final del ciclo de vida, el proveedor debe ocupase de la discontinuidad del servicio. Es un tema muy complejo debido a la escala de un sistema IoT. Si se desestima una versión del dispositivo IoT, pero el servicio continúa, el proveedor debe enviar nuevos dispositivos a los usuarios. Estos dispositivos discontinuados se retiran de forma segura y o bien se destruyen de forma segura o se inutilizan. En caso de interrupción permanente del servicio de IoT, el proveedor debe tener en cuenta los siguientes factores: - Todos los usuarios de IoT deben ser notificados mucho antes de la interrupción. Se cerrarán todas las cuentas y en la medida de lo posible indicar servicios alternativos. - Todos los usuarios deben tener la oportunidad de actuar sobre lo que pasará con sus datos una ves que el servicio llega al final de vida útil (end-of-life, EOL). Dependiendo de los acuerdos, regulaciones, normativa, … los usuarios deben disponer de tiempo suficiente para descargar los datos recopilados y almacenados. Y si así lo requiere el usuario el proveedor deberá eliminar los datos de sus sistemas. Tras el cese de actividad, en un tiempo razonable debemos borrar todos y cada uno de los datos en nuestro sistema para evitar cualquier responsabilidad potencial a parte de evitar el riesgo de pirateo o acceso no autorizado a los mismo. - Si los dispositivos que se venden en al consumidor final, logicamente debes detener la venta y eliminar el inventario restante. Prepara un programa de recepción y reciclado, el planeta te lo agradecerá. Si no puedes recepcionarlos, indica como se puede reciclar. Piensa que esto será un dispositivo inútil ya que están casi al 100% ligados a un backend que ya no existirá. En caso de IIoT se debe trabajar en un programa de recuperación entre cliente y proveedor, en la medida de lo posible. En cualquier caso, debes poder como proveedor deshabilitar dispositivos IoT de forma remota, borrar certificados, etc.

Resumen Seguridad en IoT(1/8) Si no conoces mínimamente las vulnerabilidades
de un dispositivo de IoT, logicamente no podrás dar un buen servicio. A modo resumen estas son las principales: • Mantenimiento insuficiente: Opuesto a los teléfonos móviles, relojes, portátiles, etc. Existe una gran mayoría como lectores de consumo eléctrico y gas, semáforos, alumbrado eléctrico, etc. que a penas tiene mantenimiento y supervisión, que los expone a un sabotaje. Puede que, si te cobran más en la luz a ti no te afecte, pero a otra persona puede suponerle no comer esa semana o que pienses que si atacan un semáforo no pase nada, pero si eres tu el que esta en un cruce y abren todos en verde, tu vida está juego. Existen dos tipos de vulnerabilidades: invasivas y no invasivas, donde o bien se ataca directamente al chip o se ataca a algo que está en su perímetro. Esto es un ataque físico a nivel de electrónica, del cual no soy experto, solo se lo más básico y no puedo continuar dándote más detalles. Pero si que puedo dejarte un enlace muy interesante donde podrás encontrar artículos por expertos en sus campos: https://www.ieee-security.org/ y la revista gratuita Security & Privacy. Vulnerabilidades – Las más frecuentes

Resumen Seguridad en IoT(2/8) • Servicios de red y nube
inseguros: Estoy hablando de Azure, un sitio muy seguro no exento a ataques. La información es un leitmotiv de cualquier cibercriminal. Los atacantes tienen varios vectores a los que ir, os muestro una pincelada. Estos ataques van desde DoS, DDoS, MMIT a Data spoofing: Dispositivo IoT Gateway Dispositivo IoT Dispositivo IoT Usuario

Resumen Seguridad en IoT(3/8) • Vulnerabilidades y mala gestión del
dispositivo Son diferentes y muy variados. Sería cuando se intenta aprovechar un error en le proceso de aprovisionamiento, como podría ser el tema de los certificados. Un mal diseño o mala elección de chip que por ejemplo no se puedan actualizar o hacerlo sea muy costos, que implique incluso un desplazamiento a operarios. Puertos abiertos, no será la primera vez que veo una entrada micro usb disponible con abrir una tapa y permitir instalar o firmware o sniffers o … Tambien entraría el uso de software de terceros donde abrimos el campo de ataque. Problemas en el software de distribución OTA, que se cuele por medio un atacante y distribuya firmware hackeadas. Un mal software que permita falsificación de dispositivos. Un mal control del distribuidor del dispositivo IoT que permita a un hacker entrar la cadena de distribución y modificar dispositivos…

Resumen Seguridad en IoT(4/8) • Prácticas deficientes en gestión de
identidades y contraseñas El clásico que no necesita más explicación es algo que ya se debería conocer. Si no es así, busca en internet, a mi me aparecen más de 300 millones de resultados. • Protocolos de actualizaciones relajados Si encuentras una vulnerabilidad, cuanto antes este un firmware disponible mejor, no esperes a desplegar esas actualizaciones cada mes o 6 meses. Estas dejando una ventana muy grande a los ciberdelincuentes. Familiarízate con el termino Zero Day Vulneravility. Introduce mecanismos de seguridad en validaciones de firmwares. Intenta que no se pueda hacer roolback firmware en tus dispositivos y así evitas que un atacante pueda poner una versión anterior con una vulnerabilidad. Notifica a tu canal de distribución, clientes, etc. de la nueva actualización y obliga a instalar la nueva, lo más fácil es decirles que su dispositivo dejará de funcionar tras unos meses…

Resumen Seguridad en IoT(5/8) Vamos a ver los actores involucrados
en los ataques, así como sus posibles motivaciones. Esto nos ayudará a predecir los posibles canales y vectores de ataque. Conoce a tu enemigo: Vectores de ataque y actores – Los más frecuentes Motivaciones Con mala intención Robo de información Tomar el control Bloquear y romper el sistema Sin mala intención Cumplimentar regulaciones Test de penetración Cazador de recompensas

Resumen Seguridad en IoT(6/8) Actores • Hacker malintencionado: obtener acceso
ilegal, motivado por el robo de información, obtener control o emitir ransonware, causar una disrupción del servicio. Este actor suele ser buscado por otros de esta lista. • Hacker sin mala intención: obtener acceso ilegal, motivado por una recompensa económica que pague la empresa y suele ser o alguien de la organización o a traves de un hackathon o una auditoria. Este actor genera informes que nos ayudan a cerrar y bloquear posibles vectores de ataque. • Hacktivistas: motivados por la política, quien llamar la atención de algun problema social de derechos humanos, libertad de expresión, etc. Pueden tener intenciones malas o no, dependerá. • Gobiernos: entra dentro de una guerra silenciosa, quieren crear disrupción de sistemas (como la Mirai Botnet o Stuxnet), robar información tecnológica o militar. • Criminales: normalmente motivados por el dinero, buscarán otros actores de esta lista y habitualmente secuestran a cambio de dinero. • Ciberterroristas: quieren crear disrupción y caídas críticas con la intención de genera pánico. Buscan reconocimiento de su causa. • Bromistas: entra en un área gris y hackean por fama y notoriedad. • Usuarios no autorizados: usuarios autorizados del sistema que explotan las credenciales en busca de más privilegios y poder vender o las credenciales o datos. Suelen estar a disgusto con su organización. • Ladrones: motivación monetaria. Y logran tomar control de puertas, camaras de seguridad, … como puente para su otra acción delictiva. • Otros: sin afiliaciones anteriores y sin motivaciones claras, lobos solitarios que son más complicados detectar tanto la motivación como el objetivo.

Resumen Seguridad en IoT(7/8) Niveles • Sensores y actuadores: obtener
información de los sensores y usarlo para posibles exploits. • Aplicaciones: robo de credenciales para obtener control. Instalar software corrupto tanto para controlar dispositivos como para propagar malware. • Gateways y redes locales: credenciales y datos con el ataque man-in-the-middle. Puede leer algo de información en un PDF que saque sobre seguridad básica para desarrolladores de .NET. • Firmware y SO: corromper los dispositivos para que se pueda confiar y usar de forma no autorizada. • Microcontroladores y procesadores: básicamente temas de electrónica que a mi se me escapan y necesitan de una manipulación a muy bajo nivel. Redes • Escaneos de puertos: para encontrar posibles entradas con lo que generan los puertos ya conocidos de IoT. • Idle scan: búsqueda de posibles puertos TPC para observar que ocurre. • Monitorizar la red: para ver que paquetes se mueven. • Derivaciones de red óptica, conocido como Fiber tapping. • DoS y DDoS: viejos conocidos. • Ataque Smurf, Ping flood, MITM, ARP, Ping of death, etc.

Resumen Seguridad en IoT(8/8) Cloud Algunos son parecidos a los
de Red, como DoS o MITM y otros ya son más exclusivos del Cloud como Side-channel attack o Weapoining cloud system. Os pongo la parte que os tocará ir investigando, pero que no es obligatoria para poder entender las medidas que vamos a conocer de forma práctica: • Defensa y prevención. Contramedidas. Para un ataque. • Detección e identificación de ataques. • Recuperación ante ataques. • Impacto social y economico de un ataque. Como podéis observar la lista es larga y cada uno de los puntos con mucha información que no es para este libro, pero que al menos te pongo en conocimiento con esos grandes titulares. Y … – No terminaría este capítulo nuca

Ejemplos Azure IoT(1/26) Esto ya lo habéis estado usando, es
como hemos estado conectado los dispositivos al IoT Hub. No es nada nuevo. En este ejemplo vamos a registrar un terminal y obtener su cadena de conexión. Lanza VS Code y comencemos. csharpSASSecurity – Symmectic Key Security https://github.com/jmfloreszazo/HandsOnIoTAzure

Ejemplos Azure IoT(2/26) Lo primero de todo recalcar que ya
has conectado de esta forma en anteriores ejemplos, esta imagen os sonará: Y que lo que vamos a ver es como creamos un dispositivo desde una aplicación de CLI y obtenemos una SAS. Vamos a realizar un autorregistro, que tiene más sentido en esta sección. Este ejemplo es inseguro, ya que vamos a usar una clave de IoT Hub que exige mucho control para mantener la seguridad, más mecanismo para rechazar registros en un intento de ataque, etc.

Ejemplos Azure IoT(3/26) Los pasos para crear una cadena de
conexión que nos permita solamente crear dispositivos: Gracias a las distintas opciones podemos añadir un mínimo de seguridad, que es evitar acciones no permitidas al dispositivo. Como veis es inseguro ya que, si logran encontrar esa cadena, nos pueden hacer un ataque y llegar a tumbar el servicio, los IoT Hub solo admiten una cantidad de mensajes por cada SKU que hemos pagado.

Ejemplos Azure IoT(4/26) En el siguiente codigo debemos añadir las
cadenas de conexión en app.config y ejecutamos: Podemos observar que estamos generando la telemetría y se a creado el dispositivo en IoT Hub:

Ejemplos Azure IoT(5/26) Al haber sacado el tema de aprovisionamiento
masivo, vamos a aprovechar este ejemplo para dos cosas: certificados X.509 y Device Provisioning Service (DPS). Vamos a ver la parte teórica y práctica. Lanza VS Code y comencemos. csharpX509SecurityAndDPS – Certificados y distribución https://github.com/jmfloreszazo/HandsOnIoTAzure

Ejemplos Azure IoT(6/26) IoT Hub Device Provisioning Service (DPS) Hacemos
un stop, por qué me gustaría enseñaros proteger via un DPS y certificado X.509. Conociendo esto bien, ya podrías iniciar un proyecto con una seguridad mínima viable. Por tanto, dejemos de usar SAS y comencemos a usar X.509. En los ejemplos yo seguiré usando SAS debido a la celeridad que me da. Pero como podrás intuir es más complejo asegurar via SAS que via X.509. Las características principales son: • Autoaprovisionamiento de dispositivos IoT via Zero Touch (se aprovisionan y configuran automáticamente) y Just in Time. • Permite esta conectado a múltiples hubs a través de políticas de asignación y regiones. • Atestación via clave simetría, certificado X.509 y TPM

Ejemplos Azure IoT(7/26) Cuyas responsabilidades: Existen dos formas de gestionar
la inscripción: • Grupales, permite asignar múltiples dispositivos que usan una misma certificación. • Individuales, asignar un solo dispositivo (esto invalida la política grupal). Además, debes conocer los conceptos: • Cancelación de la inscripción de un dispositivo: disernrolling. • Desaprovisionar un dispositivo: deprovisioning. • Reaprovisionar un dispositivo: reprovisioning. DPS IoT Hub Gestionar las inscripciones Gestionar los dispositivos Aplicar atestaciones Almacenar dispositivos gemelos Ejecutar políticas de asignación Recibir eventos y telemetría Registrar dispositivos en IoT Hub Aplicar rutas y consultas Devolver un endpoint de IoT Hub Integrar con otros dispositivos

Ejemplos Azure IoT(8/26) Disenrolling: Nos permite evitar que un dispositivo
se inscriba. Pero no evita que un dispositivo registrado envíe datos al IoT Hub. Tienes las siguientes opciones: 1. Deshabilitar o eliminar un grupo de dispositivos. 2. Deshabilitar o eliminar un solo dispositivo, este o no dentro de un grupo. Deprovisioning: Desaprovisionar un dispositivo lo que hace es cancelar la inscripción (disenrolling) y des-registrar para no permitir enviar datos a IoT Hub. Con las opciones de hacerlo con: • Grupos. • Individual. Reprovisioning: Es mover un dispositivo aprovisionado a otro IoT Hub. Via configuración de una política o a través de grupos o de forma individual. Esta acción, nos permite migrar los datos y el estado del dispositivo o hacer un reset del estado y limpio de datos iniciales.

Ejemplos Azure IoT(9/26) Cómo funciona esquemáticamente el registro de un
dispositivo con un flujo X.509: Certificado root CA verificado Grupo de alistamiento Alistamiento individual Cadena certificada

Ejemplos Azure IoT(10/26) DPS IoT Device IoT Hub Registrar IoT
Hub Endpoint ¿Coincide con una inscripción individual? ¿Coincide con una inscripción grupal? ¿Habilitada inscripción grupal? ¿Habilitada inscripción individual? No Si Si Denegada No No No Aceptada Conectado Si Si

Ejemplos Azure IoT(11/26) ¿Cómo funciona la asignación de IoT Hub
y DPS? Puedes tener hasta 50 IoT Hub enlazados y dependiendo de tus preferencias asignar los dispositivos a uno u otro IoT Hub. Aunque seguramente querrás que sea la latencia quien actúe como deben registrarse y si no, en IIoT adoptes un plan por plantas, o en salud por hospitales… esto te permitirá observar el trafico y tarificar lo más ajustado posible. Test de latencias en Azure: https://www.azurespeed.com DPS Device 1 IoT Hub B IoT Hub A IoT Hub C IoT Device 2 IoT Device 1 IoT Device 3 Device 2 Device 3 DPS 200ms IoT Hub B IoT Hub A IoT Device 1 100ms 125ms

Ejemplos Azure IoT(12/26) Secuencia de autoaprovisionamiento: Fabricante Dispositivo Operador Desarrollador
DPS IoT Hub Asignar Identidad y url del DPS Proveer de identidad al dispositivo Configurar auto aprovisionado Codigo de despliegue y registro Registar via url DPS e Id Determinar IoT Hub Registar dispositivo Devolver endpoint de IoT e Id del dispositvo Gemelo digital y envio telemetría

Ejemplos Azure IoT(13/26) Donde cada rol: • Fabricante: implementar la
atestación, asignar la identidad al dispositivo y establecer url del DPS. • Dispositivo: conectarse con Id y la url del DPS, obtener el dispositivo gemelo y enviar telemetría. • Operador: configurar el autoaprovsionado DPS, enlazar los IoT Hubs, administrar asignaciones. • Desarrollador: construir, desplegar y registrar código, usar los SDK, implementar la atestación. • DPS: autenticar el dispositivo, aplicar la atestación, ejecutar políticas, registrar dispositivo en IoT y devolver el Id e IoT Hub. • IoT Hub: mantenimiento de listas, device Twins, telemetría, rutas y consultas, integración de servicios, monitorización de salud. Vamos a dar un paseo por el DPS.

Ejemplos Azure IoT(14/26) Creamos el DPS: Y asociamos al IoT
Hub:

Ejemplos Azure IoT(15/26) Pues observar aquí como crear un enrollment
group y cambia los valores iniciales del gemelo: { "tags": { "environment": "test_group" }, "properties": { "desired": {} } }

Ejemplos Azure IoT(16/26) Igualmente, puedes hacerlo de forma individual (crea
previamente un device y quédate con el Id):

Ejemplos Azure IoT(16/26) Tras un breve vistazo del funcionamiento con
el UI, vamos a entrar ya en nuestro proyecto para probar todo lo aprendido. Crear un .CER para CA (Certification Authority) 1. Descargar este contenido de GitHub: https://github.com/Azure/azure-iot-sdk-c/tree/main/tools/CACertificates 2. Entras en: ./tools/CACertificates 3. Botón derecho y abres con Windows PowerShell ISE en modo administrador el fichero ca-cecdrt.ps1 4. Descarga la última version estable de https://www.openssl.org/. Pero te sugiero que uses esta de aquí: https://slproweb.com/products/Win32OpenSSL.html (version Win64 OpenSSQL v1.1.1L) y la instales. 5. Ejecuta desde Windows PowerShell ISE como administrador: Set-ExecutionPolicy -ExecutionPolicy Unrestricted 6. Establece estas variables de entorno desde la ventana de Windows PowerShell ISE en modo administrador: $ENV:OPENSSL_CONF="C:\software\OpenSSL-Win64\bin\openssl.cfg" 7. Ahora sí, ejecuta el script que tienes abierto. 8. Debe salirte este mensaje: 9. Ahora lanza el comando: Test-CACertsPrerequisites

Ejemplos Azure IoT(17/26) 10. Ejecutas: New-CACertsCertChain ecc 11. Te habrá
creado 3 certificados, puedes verlo desde la herrramienta: 12. Te sitúas en una carpeta vacia y ejecutas: New-CACertsDevice DemoDevice1 -signingCertSubject "CN=Azure IoT CA TestOnly Intermediate 1 CA“ 13. Establece una contraseña compleja. 14. Desde (ver imagen) seleccionas Azure IoT Ca TestOnly Root CA, botón derecho, todas las tareas y exportar.

Ejemplos Azure IoT(18/26) 15. Debes seleccionar la opción, no exportar
la clave privada, siguiente y: 16. Lo exportas con un nombre en la carpeta donde generaste el anterior fichero. 17. Ahora exportas DemoDevice1 y “exporta la clave privada”, continuas con las opciones por defecto, pones la password y generas el fichero. 18. Ya tienes dos ficheros un .cer y un .pfx. 19. Entras en DPS y lo importas, ver la siguiente imagen:

Ejemplos Azure IoT(19/26) 20. Desde esta opción, genera un codigo
de verificación:

21. Ejecutamos en PowerShell: New-CACertsVerificationCert “<<YOUR CODE>>" 22. En la
ventana del punto 20, carga el fichero generado en el punto 21 y podrás ver en verde el certificado: Crear un SC (Selfsigned Certification) 1. Descarga las fuentes del ejemplo, si no lo habías realizado. 2. Desde la el CLI de Powershell (que no deberías haber cerrado), ejecutas: GenerateTestCertificate.ps1 testdevice2 3. Tendrás que tener dos ficheros un .pfx y un .cer. 4. Subes al IoT Hub el certificado .cer. Ejemplos Azure IoT(20/26)

Ejemplos Azure IoT(21/26) Proyecto IoTDPSWithSAS, como asignar un device via
DPS y bajo mínima complejidad, ya que usamos SAS: Debes obtener varios valores: en enpoint del DPS, el Id del scope del DPS y las claves de enrollment de testgroup que creamos anteriormente.

Ejemplos Azure IoT(22/26) Ejecutas y podrás ver como se crea
el nuevo:

Ejemplos Azure IoT(23/26) Proyecto IoTDPSWithSC, es ejemplo, no usa el
DPS, pero lo incluyo aquí para que veáis algo más de los certificados: En este caso entramos en la carpeta donde generamos los SC y vamos a crear un nuevo dispositivo desde IoT Hub. En realidad, como ves en la imagen primero lo hacemos con un CA. Muy importante dejadlo ya verificado, es para nuestras pruebas. Ejecuta el codigo y verás que se puede mandar la información.

Ejemplos Azure IoT(24/26) Y luego lo puedes hacer Self-Signed: En
este caso debes poder abrir el certificado instalado y localizar la huella digital para que luego coincida la que tienes en el fichero con la que tienes en el equipo. Tambien puedes pasar por alto el registro y usar el .cer renombrándolo a .pfx.

Ejemplos Azure IoT(25/26) Proyecto IoTDPSWithX509CA y este es el ejemplo
al que quería llegar: Lo primero que debemos hacer es subir el fichero .cer y verificarlo, paso que hemos realizado anteriormente. Y crear un nuevo grupo de enrrollment: Guardas el cambio y ejecutas el código local.

Ejemplos Azure IoT(25/26) Entra en el grupo de enrollment y
verás los registros, así como el nuevo device en IoT Hub: Y poco más que mostrar.

Ejemplos Azure IoT(26/26) En algun momento tendrás la necesidad de
filtrar direcciones IP para que puedan conectar los dispositivos de forma explícita. Esta opción nos permitirá aceptar o rechazar tráfico de direcciones IPv4. El filtro nos permitirá aceptar tráfico de un rango específico de direcciones IP y rechazar todas las demás. Un claro ejemplo es usarlo conjuntamente con Azure Express Route, esto nos permite crear conexiones privadas entre el centro de IoT y la infraestructura local. Y en la solapa Private Access podrás hacer uno de Azure Private Links. IP Filter – Especificación explícita de direcciones IP

Ejemplo Azure Defender for IoT(1/7) Desde IoT Hub: • Defender
for IoT Overview Secure your IoT Solution • Si al hacer clic, vuelves al mismo botón, debes ir al recurso Microsoft Azure Defender for Cloud y activar el trial. • Tras uno breve instante tendrás disponible el siguiente panel o refresca con F5. Puede que al entrar en Overview no te pida el paso anterior, esto es por que has habilitado esta opción en el pasado. Azure Defender para IoT

Ejemplo Azure Defender for IoT(2/7) • Defender for IoT Settings
Data Collection Asegúrate que este habilitado Azure Defender for IoT On • Añade un nuevo Workspace, pon el nombre que desees y guárdalo • Ahora debemos activar Azure Audit Logging. Desde el grupo de recursos, debemos entrar en: Monitoring Diagnostic Settings Seleccionas el IoT Hub + Add diagnostics settings

Ejemplo Azure Defender for IoT(3/7) • Y enviamos la información
al Log Analytics workspace: • Y repites la operación con el DPS.

Ejemplo Azure Defender for IoT(4/7) • Si tuvieras ya devices
conectados y con el agente de seguridad de IoT desplegado, tras esperar unos instantes, comenzarías a tener reportes de seguridad, sugerencias, etc:

Ejemplo Azure Defender for IoT(5/7) • Podemos entrar en las
opciones para que veas que va saliendo:

Ejemplo Azure Defender for IoT(6/7) • Desde la siguiente opción
security alerts:

Ejemplo Azure Defender for IoT(7/7) • Desde la opción recommendations:
• Por supuesto podemos poner alertas en base a nuestra base line definida por el Twin. Este es un punto muy importante y aquí podéis ver toda la información.

Un último apunte… Fail Over Directamente relacionado con la seguridad
tenemos que saber que existe y tenemos a disposición out-the-box una opción muy imporante a tener en cuenta: la conmutación frente a errores: Conmutación – Ante errores

Si deseas saber más – Solo tienes que ponerte manos
a la obra Workshop… Securing Azure IoT Solutions IoT Os dejo un enlace a un workshop de Microsoft que en unas 5 horas os muestra como establecer la seguridad de extremo a extremo. No tiene mucho sentido que desarrolle tanto los puntos anteriores de Azure Defender for IoT o Azure Security Center, más allá de lo que os he contado, debido a que el workshop que os indico os deja muy claras las bases y las herramientas correspondientes. https://github.com/microsoft/MCW-Securing-Azure-IoT-solutions Nota del autor: fácilmente podía haber engordado innecesariamente unas 60 páginas más esta sección de seguridad con la información del workshop de Microsoft. El repositorio original y es el que os recomiendo usar para el workshop, podéis usar el fork que he realizado en mi cuenta de GitHub, por si en algun momento deja de estar disponible.

Para terminar… Azure IoT(1/3) Tal y como dice el titular,
solo hemos arañado la superficie; si has terminado el workshop podrás haber visto más cosa como modulos guardianes de edge, y habrás podido profundizar un poco más. Pero en cualquier caso ya tienes una base mínima para ir haciendo las cosas bien desde el minuto 0. Qué podemos añadir a los ejemplos anteriores: • Azure Sentinel. • Microsoft Defender for Endpoint. • Azure Private Links. • Azure Express Route. • NSG. • Firewall. • … Azure nos proporciona muchas más herramientas, pero esto ya es seguridad a nivel de la arquitectura de la solución y no son recursos exclusivos del ecosistema IoT de Azure. Una vez más, aquí te toca estudiar y profundizar en este apasionante, a la vez que exigente mundo de la seguridad. Recuerda: los malos siempre están unos metros kilómetros por delante de nosotros. Desafortunadamente no puedo mostraros un ejemplo de TPM real debido a que no dispongo de hardware para ejecutar esta prueba en la fecha de publicación, cuando lo tenga actualizaré el libro. Solo hemos arañado la superficie – A partir de aquí…

Pero si que podéis emularlo con el workshop que os
he recomendado: Para terminar… Azure IoT(2/3)

Y si alguien quiere ir trabajado sobre hardware real, os
dejo un TPM y un ejemplo: OPTIGA™ TPM SLI 9670 El hardware no es caro, pero aun no he tenido tiempo para comprarlo. En cuanto lo tenga, como decía antes, actualizaré el documento con el ejemplo anterior. Ahora entrarás en la sección de análisis de datos, cuando termines la siguiente sección ya habremos cerrado el circulo de los recursos que debes conocer y manejar para tener éxito con un proyecto de IoT en el ecosistema de Azure. Para terminar… Azure IoT(3/3)

Sección 6 Análisis de datos

Analisis de datos Introducción(1/2) IoT es un circuito cerrado de
sensores, conexiones, y una base de datos que almacena información. La toma de decisiones se basa en la información recibida por los sensores y que luego retroalimenta el sistema. Existen numerosas aplicaciones de IoT en todos los aspectos de nuestra vida y que ya hemos visto: ciudades inteligentes, salud, venta minorista, agricultura, etc. Analítica es un término que se hace popular cuando se democratizó la minería de datos y que hace referencia al análisis de datos para para la toma de decisiones. Las herramientas utilizadas en análisis tocan área tales como aprendizaje automático, estadística e investigación operativa. Hay una gran cantidad de herramientas conocidas: como son las redes neuronales, modelos ocultos de Markov, regresiones lineales multivariantes, pronósticos, etc. La contribución de la investigación operativa a la analítica es incipiente ya que su perspectiva es diferente. Las tecnicas de investigación operativa se utilizan para estudiar el desempeño de un sistema mediante el desarrollo de modelos matemáticos y basados en sistemas computaciones, que se usan para estudiar el desempeño de un sistema bajo diferentes supuestos. Por lo general se aplican a sistemas que aun no se han construido, como nuevos diseños o muevas mejoras de uno existente. En IoT la investigación operativa se le conoce como rendimiento, evaluación y modelado. Las herramientas típicas son simulaciones, teorías de colas y optimización de métodos. Y efectivamente, lo estas pensado, su aplicación principal esta ligada al Digital Twin, pero es un área que esta dando sus primeros pasos, esta muy poco explotada. La razón de ser de IoT – Datos y más datos

Analisis de datos Introducción(2/2) Soy partidario de usa la acepción
análisis, indistintamente, para técnicas de explotación como técnicas de evaluación. En IoT existen muchas aplicaciones en lo que respecta al análisis de problemas: seguridad, detección de intrusiones, garantía de datos, medición y mantenimiento predictivo, capacidad de la red, gestión de sensores para la toma de decisiones, optimización de recursos, … El análisis de datos, no necesariamente para IoT, precisa de unos conocimientos matemáticos y estadísticos profundos. Que no son el objetivo de este libro. Con la definición anterior comprenderéis que naturalmente no voy a tratar el análisis de datos, lo que voy a tratar en este capitulo es como almacenar esos datos para que puedas explotarlos y en la siguiente sección avanzada ver algo. Por tanto ¿qué vamos a ver en esta sección? Logicamente las herramientas necesarias para almacenar la información de la forma correcta para que puedan pasar por el análisis de datos, así como algun flujo o arquitectura que muestra lo que realmente solemos hacer cuando nos encontramos en un proyecto de IoT. Sin más preámbulos voy a ir presentando los recursos que debes conocer dentro de Azure y se engloban en el ecosistema de IoT. No sin antes pasar por la base teórica.

Las Cinco W Datos(1/8) Ya hemos respondido a casi todas
las cuestiones, veamos cuales y a donde nos dirigimos: 5W – Qué, Quién/Quiénes, Cuándo, Dónde, Por qué, Cómo Qué Quién Cuándo Dónde Por qué Cómo • ¿Qué?: el dato es la telemetría o información preprocesada o completamente procesada. • ¿Quién?: son los dispositivos IoT clásicos o Edge los que transmiten el dato. • ¿Cuándo?: sería la ventana de tiempo de envio del dato en un caso de telemetría o un evento cuando se trata de una información Edge, por ejemplo. • ¿Dónde?: el dato viaja a los servicios de IoT, el backend. Y donde debe almacenarse el dato para proporcionar la información para la que se diseña el sistema. • ¿Por qué?: logicamente dependiendo de la solución tendrá una respuesta diferente, pero fundamentalmente el dato debe cumplir con los requerimientos del sistema. Aquí también entraría la analítica del dato, área que ya hemos comentado que no vamos a tratar en este libro. • ¿Cómo?: hasta ahora hemos visto una pequeña parte del movimiento del dato del dispositivo al backend, pero no nos hemos parado a estudiarlo. Es lo que vamos a tratar en esta sección: como viaja el dato desde el device hasta como se presenta al usuario.

La mayoría de los sistemas necesita al menos una de
las siguientes acciones con respecto a los datos: Esto quiere decir que podemos definir una arquitectura que las mapee y luego comenzar a crear componentes de software que implementen cada una de estas partes. Por tanto, vamos a plantear un diagrama que recopile los cinco puntos anteriores. Arquitectura Clásica – Un vistazo de alto nivel ¿Cómo? Datos(2/8) Recopilación Gestión Análisis Configuraciones Desencadenadores

¿Cómo? Datos(3/8) Arquitectura básica y general: Telemetría Recopilación del dato
Gestión del dato Análisis del dato Desencadenador del dato Configuración del dato Time Series Database Resultado de los análisis Informes Sin acción

La anterior arquitectura, podemos dividirla en dos partes. La que
corresponde al dispositivo y la que corresponde a la nube: ¿Cómo? Datos(4/8) Cloud Dispositivo Edge Telemetría Recopilación del dato Gestión del dato (local) Time Series Database (local) Configuración del dato (local) Análisis del dato (local) Desencadenador del dato (local) Análisis del dato (organización) Gestión del dato (organización) Desencadenador del dato (organización) Configuración del dato (organización) Time Series Database (organización) Sin acción Resultado de los analisis Informes

Simplificándolo más e introduciendo un concepto de gateway el cual
ya he mencionado y que veremos en la sección avanzada, podríamos tener el siguiente diagrama: ¿Cómo? Datos(5/8) Cloud Dispositivo Edge Sensores Actuadores Aplicación del Device (Gestión de los sensores / actuadores) Librerias de IoT Librerias de IoT Aplicación gateway del Device (administración del dato, Administración de conexiones) Red Local Infraestructura IoT Servicio (analistica, almacenamiento, administración) Servicio (analistica, almacenamiento, administración) Servicio (analistica, almacenamiento, administración) Almacenamiento Internet

Y para finalizar voy a desgranar que ocurre en un
edge ya que los gateways son muy importantes cuando trabajamos con IoT, sobre todo para mantener en funcionamiento dispositivos antiguos o aquellos que no son capaces de trabajar con los protocolos que permite Azure. Por adelantaros algo un gateway nos ayudará a transformar el dato que viene de un protocolo a otro protocolo, por eso mi insistencia, son de vital importancia en IoT: ¿Cómo? Datos(6/8) Dispositivo Edge Sensores Actuadores Aplicación del Device (Gestión de los sensores / actuadores) Gestion cliente Gestion cliente/ servidor Aplicación gateway del Device (administración del dato, Administración de conexiones) Red Local Almacenamiento local Gestion de la persistencia Analítica local Administrar sistema (config, etc.) Administrar datos y validaciones Administrar sistema (config, etc.) Administrar datos y validaciones

¿Como se traduciría esto a los recursos de Azure?. Vamos
a partir del diagrama inicial para presentaros las piezas que vamos a ver: ¿Cómo? Datos(7/8) IoT Hub IoT Central Service Bus topic Service Bus Storage Event Hubs In-build Event Hubs Time Serie Insight Stream Analytics Logic Apps Data Transformation Databricks HDInsight Machine Learning

Ya hemos visto a nivel esquemático que necesitamos conocer. Y
que recursos nos ayudan a realizar las cinco acciones, y también sabemos que al menos una debe existir en el ecosistema de IoT. A continuación, debes conocer en mas detalle estos recursos que te permitirán decidir cual de ellos es el adecuado para cumplir con los requerimientos de la solución. No voy a entrar en bases de datos relacionales, no relacionales, par-valor, etc. esto se presupone que es un conocimiento que ya deberías tener. Por tanto, solamente vamos a ver aquellos recursos que son propios o que nacen a partir de un requerimiento del ecosistema de IoT. Antes de entrar en esos recursos propios de Azure que he mencionado en el diagrama anterior, vamos a ver a continuación uno de los aspectos básicos y necesarios para comprender aun más IoT. ¿Cómo? Datos(8/8)

No vamos a entrar en detalle, si no, que es
introducción básica y necesaria. Esta introducción pretende dejaros en vuestro radar estos elementos y si quieres profundizar en ellos, tengas la mínima información para ampliar esos conocimientos. Para comenzar vamos a ver las tecnologías de comunicación actuales (a fecha de Enero de 2022) más importantes del ecosistema: • WPAN (Wireless Personal Area Network) basadas en No-IP: Estandar 802.15, Bluethoot, IEEE 802.15.4, Zigbee y Z-Wave. • WPAN (Wireless Personal Area Network) y WLAN (Wireless Local Area Network) basadas en IP: TPC/IP, WAN con IP (6LoWPAN), IEEE 802.11 + WLAN y WPAN con IP. • LRWAN (Long Range Wide Area Networks). Celular (3G, 4G, CBRS y 5G), LoRa y LoRaWAN y Sigfox. Y los protocolos más utilizados, aunque Azure IoT Hub solo use alguno de ellos, Son: HTTP, MQTT, AMPQ, CoAP y STOMP. Breve introducción teórica – Del dispositivo al backend Resumen Protocolos y redes de comunicación(1/28)

Los protocolos son las herramientas que unen y encapsulan datos
sin procesar de un sensor y lo convierten a algo significativo y formateado para que la nube lo acepte. Una de las principales diferencias entre IoT y M2M, es que M2M puede comunicar a través de una WAN sin un servidor dedicado o sin ningun protocolo encapsulado. Por ejemplo, SCADA en la industria puede usar un sistema usado BACnet o Modbus para comunicarse entre maquinaria y servidor. Mientras que IoT, como bien sabes los endpoint deben usar internet como su red principal. Por ejemplo, usando MQTT o HTTP. HTTP Por más de 20 años lleva HTTP en funcionamiento; se diseñó para un propósito general con modelos cliente/servidor. Los dispositivos IoT suelen estar muy restringidos, estar en lugares remotos y un ancho de banda limitado. Por lo tanto, se necesitan protocolos más eficientes, seguros y escalables para gestionar hasta distintas topologías de red. Aun así, HTTP se usa y mucho, es uno de los 3 protocolos existentes en IoT Hub, normalmente se debe usar en dispositivos Edge. Como bien sabéis HTTP no es eficiente en una red y los protocolos HTTP2 y HTTP3 lo son, aunque relativamente. Aunque la seguridad es inherente al protocolo y se establece via TLS. HTTP esta en todos los lugares, máxime con el uso de RESTful APIs. Protocolos de comunicación Resumen Protocolos y redes de comunicación(2/28)

Una diferencia que incluyo aquí es que los demás protocolos
a excepción de HTTP usan un modelo conocido como MOM (message-orientated middleware). La idea básica de MOM es que la comunicación entre dos dispositivos se realiza con colas de mensajes distribuidos. Una mamá (hacen la analogía con mamá, MOM es mamá en ingles) entrega un mensaje de una aplicación a otra. Algunos dispositivos producen datos que se generan a una cola mientras que otras consumen datos almacenados en la cola. Algunas implementaciones requieren un servicio broker o middleware, un intermediario. Se usa el patrón publicar- suscribir, como el caso de AMQP, MQTT y STOMP (implementaciones de MOM), las colas nos ayudan a la resilencia del diseño. La alternativa a MOM es RESTful. Esta implementación, un servidor posee el estado de un recurso, pero no el estado no se transfiere. Con total seguridad conocéis los métodos GET, POST, PUT y DELETE, que son las solicitudes que realiza el cliente al servidor son un intermediario en la arquitectura. Son patrones síncronos de solicitud-respuesta. Para no alargar más la explicación, os muestro la diferencia esquemática entre MOM y RESTful: Resumen Protocolos y redes de comunicación(3/28)

Resumen Protocolos y redes de comunicación(4/28) Publisher Broker (Server) Subscriber
CONNECT CONNACK CONNACK CONNECT SUSCRIBE (topic) SUBACK PUBLISH (topic, data) PUBACK PUBLISH (topic, data) PUBACK Client Request REST HTTP TCP IP Client REST HTTP TCP IP Response Internet MOM Service RESTful Service

MQTT En este caso voy a detenerme un poco más,
ya que es el protocolo más común en el mundo de IoT y es complica de uno de patrones de arquitectura más usado últimamente CQRS. En el año 1993 la tecnología IBM WebShpere Message Queue fue concebida para abordar problemas de comunicación segura entre sistemas distribuidos independientes y no concurrentes. Y un derivado de esta tecnología de 1999 da como resultado el protocolo MQTT, todo gracias a Andy Stanfrod-Clark y Arlen Nipper de IBM. Los objeticos de este protocolo son: • Fácil de implementar. • Servicios de calidad. • Liviano y eficiente con el ancho de banda. • Agnóstico del dato. • Conciencia continua de la sesión. • Y que pueda abordar problemas de seguridad. MQTT proporciona estos requisitos, aunque la mejor forma de entender este protocolo y además haciendo mención de IoT que nos la da mqtt.org: Resumen Protocolos y redes de comunicación(5/28)

MQTT es un protocolo de mensajería estándar de OASIS para
Internet de las cosas (IoT). Está diseñado como un transporte de mensajería de publicación/suscripción, extremadamente liviano, que es ideal para conectar dispositivos remotos con una huella de código pequeña y un ancho de banda de red mínimo. Hoy en día, MQTT se utiliza en una amplia variedad de industrias, como la automotriz, la fabricación, las telecomunicaciones, el petróleo y el gas, etc. MQTT en sus inicios fue un protocolo interno y propietario de IBM, hasta que en 2010 con su version 3.1 se hace open source. En 2014, el consorcio OASIS publica la version MQTT 3.1.1 y bajo un estandar ISO (ISO / IEC PRF 20922). Y recientemente se encuentra en la versión MQTT 5 (2019). La version 5 resuelve los problemas siguientes: • MQTT 3.1.1 tiene problemas de personalización o agregación de metadatos, que es común en HTTP. • MQTT 3.1.1 tiene dificultadas con la Interoperatividad cuando se comunicación a través de diferentes plataformas de proveedores, bibliotecas y rutas de datos. Para solucionar estos problemas MQTT 5 introdujo las propiedades de usuario. Resumen Protocolos y redes de comunicación(6/28)

¿Qué es MQTT publish-subscribe (publicación/suscripción, editor/consumidor, también conocido como pub/sub)?
Las arquitecturas publicación/suscripción es una forma de desvincular a un cliente de transmitir un mensaje a otro cliente que recibe un mensaje, a diferencia de un modelo cliente/servidor, los clientes no conocen ningún identificar físico (endpoint). MQTT es una arquitectura pub/sub, no una simple cola de mensaje. Las colas de mensajes almacenan mensajes por naturaleza, mientras que MQTT no. En MQTT, si nadie se suscribe (escucha) un tema (topic), simplemente se ignora y se pierde. Las colas de mensajes también mantienen una topología cliente/servidor en la que el consumidor se liga con un productor. Es decir, desacoplado, este termino te sonará de la tendencia actual a los microservicios. Un cliente que transmite un mensaje se llama publisher (editor); un cliente que recibe un mensaje se llama suscriptor (suscriptor). En medio se coloca el MQTT broker que tiene la responsabilidad de conectar clientes y filtrar datos. Estos filtros proporcionan: • Filtrado por temas (subject): por diseño, los clientes se suscriben a temas y ciertas ramas de temas y no reciben más datos que los que desean. Cada mensaje publicado debe contener un tema y el broker (corredor) es un responsable de retransmitir ese mensaje a los clientes suscritos o ignorarlos. Resumen Protocolos y redes de comunicación(7/28)

• Filtrado por contenido (content): los broker tienen la capacidad
de inspeccionar y filtrar los datos publicados. Por tanto, el broker puede administrar cualquier dato que no esté encriptado antes de almacenarlo o publicarlo a otros clientes. • Filtrado por tipo (type): un cliente que escucha un flujo de datos al que esta suscrito también puede aplicar sus propios filtros. Los datos entrantes se pueden analizar y el flujo de datos puede procesarse o ignorarse. Un modelo pub/sub implica que tanto quien editor y consumidor conozcan el tema y el formato de los datos antes de iniciar una transmisión. MQTT desacopla a editores y consumidores. Debido a que el broker es quien gobierna a ambos, es necesario establecer directamente un editor y consumidor en función de aspectos físicos (endpoint). Es muy útil para implementación de IoT ya que la identidad física puede estar desacoplada o ser ubicua. MQTT y otros modelos pub/sub también son invariantes en el tiempo. Es decir, que un mensaje publicado por un cliente puede ser leído y respondido en cualquier momento por un suscriptor. Un suscriptor podría estar apagado o con un ancho de banda muy limitado (por ejemplo, Sigfox) y responder unos minutos u horas más tarde a un mensaje. Debido a la falta de relaciones físicas y temporales, los modelos pub/sub escalan exponencialmente. MQTT puede ingerir millones de mensajes por hora y usar miles de editores. MQTT es independiente del formato de los datos. Cualquier tipo de datos puede ser un valido. Por tanto, ambos, editor/consumidor, deben comprender y aceptar el mismo formato de datos. Resumen Protocolos y redes de comunicación(8/28)

Es posible transmitir tanto texto, como imágenes, audio, datos cifrados,
objetos, … lo que se te ocurra. Pero binarios y JSON actualmente son los datos más comunes. MQTT por protocolo admite payload (cargas de trabajo) de hasta 256MB, pero logicamente deberías restringir ese uso a unos pocos KB. Una de las ventajas de MQTT 5 es que podemos tener suscripciones compartidas. En versiones anteriores, cuando se suscriben diferentes clientes a una suscripción común, cada uno recibía una copia del mensaje. Esto vale para muchos casos, pero en ciertos casos toca trabajar sobre el equilibrio de la carga. Desde mi punto de vista MQTT tiene un mal nombre, en realidad no existen colas inherentes al protocolo. Cuidado con esa Q, que os puede llevar a error. A nivel de arquitectura MQTT tiene dos aspectos opcionales que debes conocer: LWT (Last Will and Testament y QoS (Quality of Service). Tambien podrás darle un vistazo a la representación de datos, en este enlace: data representation. O que es CONNACK o CONNECT del diagrama anterior. A partir de este momento te toca investigar más sobre MQTT, estas páginas solamente pretendían ser una base para que puedas entender el uso tan estandarizado en IoT. Resumen Protocolos y redes de comunicación(9/28)

MQTT-SN A veces conocido solamente por MQTT-S, es una derivación
de MQTT para una red de sensores. Mantiene la misma filosofía que MQTT de ligereza, pero diseñado pensado en dispositivos edge inalámbricos. Incluye soporte par aun ancho de banda pequeño, para fallos en los enlaces, mensajes de corta duración y recursos muy limitados en el hardware. MQTT-SN es tan ligero que se ejecuta sin problemas sobre BLE y Zigbee. No necesita el stack de TPC/IP. Y habitualmente, casi siempre, se usa mediante serial link (puerto serie), ya que la carga es muy pequeña. Existe una alternativa basada en UDP que es más ligero que TPC/IP. MQTT-SN tiene cuatro aspectos fundamentales: • Gateways. En MQTT una pasarela tienen la posibilidad de convertir el protocolo MQTT-SN a MQTT y viceversa. • Forwaders. Los reenviadores son una ruta entre un sensor un gateway. • Clients. Los clientes se comportan de la misma forma que en MQTT. • Brokers. Se comportan igual que en MQTT. Los Gateways son el aspecto más característico de este protocolo ya que pueden ser transparentes, que lo que hacen es convertir la información entre entradas y salidas, o de agregación que pueden generar información mas compleja. El uso de Gateways nos obliga a tener opciones de aviso y descubrimiento, para poder enviar la información entre puntos. Resumen Protocolos y redes de comunicación(10/28)

Las diferencias fundamentales entre MQTT y MQTT-SN son: • MQTT-
SN es muy poco conocido, casi apostaría que es la primera vez que lo ves, frente a MQTT que es muy popular. • En MQTT-SN existen tres tipos de mensaje CONNECT frente a uno que tiene MQTT. Ambos se usan para el will topic y will message. • Los nombres de temas MQTT se reemplazan por mensajes ID más cortos. Es más largo de explicar, pero básicamente es así. • El ID de los temas y mensajes, se puede usar sin tener ningun registro de MQTT-SN. Para usar esto tanto clietne como servidor deben usar el mismo ID. • Introduce un procedimiento de descubrimiento para ayudar a los clientes. • Pueden existir varias puertas de enlace y compartidas. • Tiene una característica KeepAlive, que permite a dispositivos durmientes preguntar por ellos y despertarlos cuando se necesita. Tanto MQTT como MQTT-SN tienen diferentes brokers como pueden ser: Adafruit IO, Mosquitto (el más conocido), HiveMQ, MQTT-C, Thing-Stream, etc. Resumen Protocolos y redes de comunicación(11/28)

AMQP (Advanced Message Queueing Protocol) Es una version más robusta
de MOM. Ideado por JP Morgan en 2003 y creado con un grupo de trabajo de 23 empresas en 2006. En 2011 el grupo de trabajo se fusiona en OASIS y es donde se encuentra actualmente. Tiene dos implementaciones la 0.9 y la 1.0, que coexisten. En la actualidad esta muy afianzado en la industria de transacciones bancarias y tiene su parcela reservada en el mundo del IoT. AMQP esta estandarizado por una ISO e IEM, siendo la ISO / IEC 19464:2014 su registro. Tambien puedes encontrar el grupo de trabajo en www.amqp.org. Este protocolo se transmite en canales virtuales con un ID unico. Y estas tienen encabezados, payload y pie de la información. Sin embargo, un canal solo puede asociarse con un host. AMQP es un sistema orientado a mensajes y controlado por un flujo. Es un protocolo de bajo nivel. Por tanto, debemos usar un API. Existen librerías para .NET, JAVA, etc. Azure Service Bus usa este protocolo, también lo puedes ver en RabittMQ, por ejemplo. La base de este protocolo es que uno o más host virtuales con sus propios espacios de nombre, intercambios y colas deben residir en un servidor central. Los consumidores y productores de mensajes se deben suscribir a un servicio de intercambio. Los servidores de intercambio reciben un mensaje del editor y lo enruta a la cola asociada. Esta relación, se llama vinculación (binding), que puede ser directa o indirecta a una cola o múltiples colas (como una retransmisión – broadcast). Alternativamente, el enlace se puede asociar a un intercambio con una cola usando una clave de enrutamiento, es decir, un intercambio directo. Otro tipo de intercambio es el que se realiza con temas (topics). Resumen Protocolos y redes de comunicación(12/28)

La topología de red de un AMQP es hub-and-spoke (concentrada
y radial). Consta de nodos y encales. Un nodo es una fuente con nombre o un receptor de mensajes. Un marco de mensajes se mueve entre nodos a traves de enlaces unidireccionales. Si un mensaje pasa a través de un nodo, el identificador global no cambia. Si el nodo realiza alguna transformación, se asigna un nuevo ID. Un enlace tiene la capacidad de filtrar mensajes. Existen tres patrones de mensajería: • Asíncronos: el mensaje se transmite sin necesidad del reconocimiento del receptor. • Request/Reply o Pub/Sub: Similar a MQTT, con un servidor central. • Almacenar y reenviar: se usa para retransmisión de concentradores, donde un mensaje se envia a un concertador intermedio y luego se envia al destino. Resumen Protocolos y redes de comunicación(13/28) Productor 1 Mensaje Broker (Server) Productor 2 Productor 3 Intercambiador Intercambiador Intercambiador Mensaje Mensaje Cola 1 Cola 2 Cola 3 Consumidor 1 Consumidor 2 Consumidor 3 Mensaje Mensaje Mensaje

CoAP (Constrained Application Protocol) Es un protocolo basado en UDP,
por tanto, la conexión no puedes ser por definición de confianza. Para compensar estos problemas CoAP presenta diferentes tipos de mensajes: confirmable, no-confirmable, advertido y reset. Usa un diseño RESTful de request/response lo que permite una mayor eficiencia y preservación del ancho de banda. Si quieres saber más sobre CoAp sigue este enlace. STOMP (Simple Text Message-Oriented Middleware Protocol) Tambien usado para streamming. Esta optimizado para la legibilidad humana, análisis de tolerancia y fallos. No es eficiente en redes y protocolos de comunicación donde se contabiliza por bits/mensajes, cualquier emisor con conectividad limitada o necesite altas cargas de comunicación o energía. Esta basado en MOM. Si quieres saber más sobre STOMP sigue este enlace. Resumen Protocolos y redes de comunicación(14/28) Las siguientes explicaciones son muy breves, si deseas profundizar en los protocolos que vienen a continuación te recomiendo entrar en los consorcios correspondientes. Y la anteriores son pinceladas para conocer los aspectos básicos y comprender a grandes rásgos por qué se usan en los servicios de IoT de Azure.

Resumen Protocolos y redes de comunicación(15/28) HTTP/RESTful MQTT MQTT-SN AMQP
Modelo RESTful MOM pub/sub MOM pub/sub MOM pub/sub Protocolo descubrimiento Si No Si No Demanda de recursos Muy alto Bajo Muy bajo Alto Media de consumo energético Alto Muy bajo Bajo Alto Autenticación Si (TLS) No (SSL/TLS) No (SSL/TLS) Si Cifrado Si (TLS) No (SSL/TLS) No (SSL/TLS) Si Complejidad del protocolo Alto Bajo Muy bajo Alto TCP/UPD TCP TCP TCP/UPD TCP/UDP Transmisión (boardcast) No Indirecto Indirecto No Calidad del servicio No Si Si Si

Comprender como funcionan las comunicaciones sobre las que trabajará un
ecosistema IoT es fundamental para conocer las limitaciones a las que se ven sujetas los datos. No vamos a entrar en una discusión a bajo nivel, si no, que con un vistazo quiero que sepas que virtudes y defectos tienen las tecnológicas de comunicación seleccionadas y si quieres saber más, ya te tocaría profundizar sobre ella. En resumen: pros y contras. Espero que, tras este resumen, puedas saber los límites de tu arquitectura por haber elegido una comunicación Bluethoot o 5G. Como bien sabéis IoT es un conglomerado de dispositivos dispares que produce y/o consumen datos. Es muy importante conocer las limitaciones de la construcción del sistema de comunicación en IoT o en cualquier red, lo mismo puedo decir de los protocolos que antes hemos estudiado. Logicamente y hablando de redes, IoT no es una excepción y podrá ser a su vez una amalgama de distintos tipos de redes, podrá combinar redes de largo alcance, locales, etc. Y si quieres complicarlo más: restricciones gubernamentales. Dentro del mundo de las comunicaciones existen unos conceptos que te vendrán bien repasar: radio frecuencia, como se transmiten las ondas, Teorema de Shannon-Hartley, … Ya que por mucho que quieras si esas en medio de la Alcarria midiendo la densidad de flores y abejas, seguramente el 3G no alcanza los 55KM desde el transmisor a tu base y tengas que optar por SigFox, en detrimento de un payload e 12 bytes a 140 bytes (por ejemplo). Redes de comunicación Resumen Protocolos y redes de comunicación(16/28)

WPAN (Wireless Personal Area Network) basadas en No-IP Los sensores
y demás trastos conectados a internet necesitan un método para transmitir y recibir información. Es esta sección nos vamos a centrar en WPAN ya que es el método predominante para conexiones industriales, comerciales y de consumo. La conectividad con cable se usa y seguro que algo tenéis enganchado al router, ya sea la TV, la consola o el PC. En la industria las trasmisiones de radiofrecuencia puede que sean incompatibles con el ecosistema en el que se encuentran y debe usarse obligatoriamente cable (cuando digo cable, entiéndase también fibra óptica). Se separa IP y No-IP porqué los sistemas de comunicación basados en IP necesitan más recursos y requisitos de la pila TCP/IP que No-IP no necesitas. Los sistemas No-IP esta optimizados para el uso energético, mientas que IP esa restricción es más laxa. Si quisiera, podría escribir un libro a parte tanto para la sección anterior como para esta, ya que es un mundo donde perfiles especializados saben mucho más que yo. Pero si eres un arquitecto/a de soluciones o un desarrollador/a debes conocer lo mínimo. Habrá cosa que toque de soslayo, como topología red o malla, o conceptos como sub-metro o me detendré un poco más en 5G una herramienta poderosa para las soluciones IoT. Resumen Protocolos y redes de comunicación(17/28)

De que podría hablar y detenerme en esta sección, de:
• Calidad y alcance de una señal de radiofrecuencia (RF). • De la asignación del espectro inalámbrico (Wireless). • Del protocolo Bluethoot y especialmente la versión 5. • De 802.15.4. • Zigbee. • Z-Wave. Como comprenderéis esto supondría mucho más de lo que pretende este libro. Por tanto, voy a dar pinceladas relevantes en cuanto al IoT. Originalmente una WPAN se diseño para ser una red de área personal pero hoy en día ese término tiene una sobrecarga muy grande. El Estándar 802.15: Muchos de los protocolos y modelos se basan en esta IEEE 802.15. La idea original fue para dispositivos portátiles y aquí se acuño el termino de work-group. Este termino se a expandido y ahora incluso abarca kilómetros. En este enlace puedes ver las especificaciones IEEE que aun rigen este protocolo. Resumen Protocolos y redes de comunicación(18/28)

Este consorcio tiene muchos grupos de interés (IG) que investigan
la confiabilidad (IG DEP) para abordar la confiabilidad y resistencia de las redes inalámbricas, las comunicaciones de alta velocidad e incluso las de THz (terahercios). Bluetooth ¿Quien no conoce esto?, ¿quien no sabe que se basa en el Rey Haral Blatadn y que le gustaba comer arándanos?, lo dicho, poco que añadir y si quieres profundizar aquí esta el consorcio: www.bluetooth.org. Por tanto, voy a dejaros una serie de datos de 5G que nos ayudará a decirnos por esta tecnología en el IoT. • La latencia es hasta 10 menor. 1 milisegundo. • La densidad de la comunicación es hasta 10 vece mayor. • La transferencia es hasta 10 veces mayor que su predecesor. • Es espectro de red es 3 veces más eficiente. • La capacidad de trafico se incrementa en 100 veces. • Y la eficiencia de la red mejora hasta en 100 veces. Gracias a estas mejoras el BLE (Bluetooth de baja energía) es ideal para IoT. Nos permite incrementar incluso la vida útil del Beaconing. Con 5G podemos adoptar mejoras en las redes y mallas de comunicaciones, etc. Resumen Protocolos y redes de comunicación(19/28)

Zigbee Aproximadamente entra en juego en 2004 y se usa
mucho en entornos industriales. Y se basa en IEEE 802.15.4. Es una especificación para un conjunto de protocolos de alto nivel de tipo RF que requieran comunicaciones seguras y con baja tasa de envio de datos, así como maximizando la via útil de sus baterías. Usa una topología de malla y es muy facil integrarlo. Se uso principalmente en la domótica y esta bajo una alianza: la Zigbee Alliance. Z-Wave Aparece en 2001bajo el desarrollo de una compañía Danesa, Zensys, que pronto empieza a sumar grandes corporaciones como Honeywell, Belkin o LG. Esta orientado para automatizaciones Smart Home. Esta enfocado en productos de consumo. Y dispone de una alianza: Z-Wave Alliance. Es un protocolo cerrado. Resumen Protocolos y redes de comunicación(20/28)

WPAN (Wireless Personal Area Network) y WLAN (Wireless Local Area
Network) basadas en IP En honor a la verdad de los anteriores protocolos algunos han adoptados un poco el diseño completo de TPC/IP, como Zigbee-IP o Bluethoot con 6LoWPAN. Lo que aquí quiero separa son aquellos que si usan el estandar IEEE 802.11 que se usan generalmente para gateways o hubs de IoT o mencionar aquellas especificaciones que han nacido para optimizar IoT como el 802.11ah. Podríamos volver a escribir cientos de paginas hablando de : • TCP/IP. • WPAN con IP-6LoWPAN. • IEEE 802.11 para WLAN. • WPAN con IP - Thread. Pero otra vez debo ser escueto en mis explicaciones y poneros sobre la pista de estos protocolos. Resumen Protocolos y redes de comunicación(21/28)

TCP/IP ¿Qué no sabes de TCP/IP?. Si alguien no lo
sabe, aquí mis cuatro palabras. Es un grupo de protocolos de red que han posible la transferencia de datos en una red, entre equipo informáticos e internet. TCP/IP se refiere a: • TCP Protocolo de Control de Transmisiones, permite conectar e intercambiar datos entre los anfitriones. • IP o protocolo de internet, una serie de cuatro octetos separados por un punto, que lleva datos de una maquina a otra. TCP/IP tiene cuatro niveles o capas que debes conocer: enlace, red, transporte y aplicación. Las ventajas de este modelo es que es capad de trabajar sobre una amplia gama de hardware y soporta muchos sistemas operativos. Es adecuado para redes pequeñas y grandes, domesticas o empresariales. Diseñador para enrutar y prestar compatibilidad estandar. Y es que el se usa de forma estandar en internet. En IoT nos es recomendable para sensores, pero si para dispositivos edge. Hasta aquí las cuatro pinceladas. Si quieres saber más, sigue este enlace. Resumen Protocolos y redes de comunicación(22/28)

6LoWPAN Es un esfuerzo por llevar la direccionalidad IP a
los usuarios pequeños y con recursos limitados. Este concepto aparece en 2005, un consorcio cerrado, pero el estandar es abierto. El acrónimo de 6LoWPAN es IPV6. La intención es la conexión IP en RF, sistemas que tienen limitaciones de espacio, energía y no necesitan realmente un ancho de banda grane. El protocolo se puede usar con 802.15.4, con Bluethoot y por debajo de 1GHz y controlado por un PLC. La ventaja principal es que es muy simple y se puede usar en gateways 3G/4G/LET/Wi-Fi/Ethernet. Un gran defecto es el numero de direcciones esta limitado a un numero fijo de dispositivos, si, son muchos 50 mil millones, pero ya vistes en la introducción que esto puede quedarse pequeño. Si quieres saber más: Grupo de Trabajo 6LoWPAN. Veremos como evoluciona. Resumen Protocolos y redes de comunicación(23/28)

IEEE 802.11 Su origen esta en 1991 por NCR para
conectar cajeros automáticos. En 1999 es cuando la Wi-Fi Alliance se funda y esta tecnología se vuelve omnipresente. Estas primeras versiones solo daban 2 Mbps muy lejos de lo que actualmente tenemos. El éxito de 802.11 se debe al enfoque de las capas del modelo OSI. Como los anteriores protocolos, es un tema muy largo y complejo, pero voy a destacar las siguientes implementaciones: • IEEE 802.11ac , que es la nueva generación de WLAN y que puede llegar hasta 500 Mbps. • IEEE 802.11p, usado para la tecnología vehículo-a-vehículos. Las conocidas VANET. • IEEE 802.11ah, una variante con objetivo IoT. WPAN with IP - Thread Protocolo relativamente nuevo para IoT basado en IPV6. Su principal objetivo es la domótica y Smart homes. Thread se lazó a mediados de 2014, por Thread Group Alliance y empresas como Aplhabet, Qualcomm, Samsung, ARM, … están metidas en la alianza. Resumen Protocolos y redes de comunicación(24/28)

LRWAN (Long Range Wide Area Networks) No perdamos el foco
que los que estamos conectado es IoT, por tanto, lo que hemos visto antes de WPAN y WLAN, se queda corto debemos ir a las WAN (Wide Area Networks) donde incluso: • 4G LTS. • 5G. • Long Rado Range (LoRa). • Sigfox. Como todo lo que hemos visto, solo me enfoco en dar pinceladas con respecto a los datos. Las comunicaciones de largo alcance suelen ser un servicio, por tanto, implican una suscripción a un operador que proporciona la infraestructura. Esto difiere de las WPAN y WLAN. Tambien implican un SLA que tiene un efecto directo en la arquitectura de la aplicación IoT añadiendo más restricciones que habitualmente son limitaciones. 4G LTS y 5G Por si mismas son tecnologías muy complejas que se escapan de este libro. Lo que, si os puedo decir que todos y cada uno de nosotros llevamos un terminal con una u otra, si no ambas. Y que logicamente aquellas personas que han pasado de 4G a 5G habrán visto como sus celulares disponen de conexiones más rápidas y con menor consumo de batería. Extrapólalo a IoT, por eso mismo esta revolucionando el sector del IoT. Resumen Protocolos y redes de comunicación(25/28)

LoRa y LoRaWAN Es una tecnología patentada, propietaria y no
esponsorizada por 3GPP. LoRa es una capa física para protocolo IoT de largo alcance, mientras que LoRaWAN es una capa MAC. Con la primera frase os estoy diciendo indirectamente que es más caro ya que necesitas un Carrier y luego eta que son de 5 a 10 veces más lentas que una tecnología 3G o LTE. Aunque es posible que baje de precio cuando este leyendo este libro. Con esto, yo no recomiendo su uso, a no ser que sean circunstancias muy especiales. Por ejemplo, en medio de una zona aislada sin ningun tipo de comunicación, te tocará levantar torres de comunicación de LoRa y lo mismo pasa para Sigfox. Desde 2015 existe una alianza que eta respaldada por IBM y Cisco. No quiero hacer propaganda de un Carrier privado y poco conocido, pero en como mucho habrá en tu país entre 1 y 2 operadores, siendo la excepción los países Europeos altamente industrializados como Italia, Alemania e Inglaterra, que disponen de más de 3 operadores. Resumen Protocolos y redes de comunicación(26/28)

Si bien es cierto que existe una comunidad abierta, no
se hasta que punto lo es, ya que el se basa en un sistema patentado y licenciado. Si realmente necesitas este protocolo ten en cuenta estas limitaciones. Y como curiosidad es un protocolo de origen francés como el siguiente que os cuento. Resumen Protocolos y redes de comunicación(27/28)

Sigfox Para terminar otro protocolo patentado y propietario de origen
Frances. Basado en banda estrecha y desarrollado exclusivamente para IoT. Desde mi punto de vista tiene unas características que limitan mucho su utilidad: • Hasta 140 mensajes/dispositivo al día. Unos 6 mensajes la hora. • Tamaño máximo de 12 bytes. Y no se confunda, son 8 para uplink y 8 para downlink. • Rendimiento de 100 bps ascendentes y 600 bps descendentes. Originalmente era para una red de sensores pura. El hardware es abierto, se cobra por la red y suscripción. Por supuesto tiene su correspondiente alianza y lo están usando muchas empresas, el grupo PSA hace trazabilidad de contenedores con este sistema. También se le conoce como 0G. Para terminar. Existen otros protocolos como ANT+, aunque propietarios, ofrecen un alto rendimiento y están espoleando a los competidores como Bluethoot 5, el bajo consumo y las redes de esta version 5 nacen tras un año de funcionamiento de ANT+, es decir, Bluethoot tubo que reimplementarse para no perder el negocio de los relojes deportivos inteligentes, un mercado muy grande. Resumen Protocolos y redes de comunicación(28/28)

Un vistazo a… Routing(1/16) Routing Azure IoT Hub esta diseñado
para recibir telemetría de millones de dispositivos. En cualquier solución del mundo real, el enrutamiento (routing) se usa para ayudar a procesar estos datos. Se usa para dirigir los mensajes a diferentes endpoints. Podemos diseñar nuestras propias rutas y si el filtro no coincide con las rutas existe, desviar esos datos a un almacén para que no se pierdan mensajes. Cuando creamos una ruta debemos especificar una fuente de datos. En la mayoría de los casos, se desea procesar los mensajes de la telemetría, pero también se pueden manejar eventos del ciclo de vida del dispositivo y los cambios de su gemelo digital. Una consulta se puede usar para limitar los mensajes que pasan por la ruta. Se puede filtrar por los valores del cuerpo del mensaje, por las propiedades del sistema (Id del dispositivo), por las propiedades añadidas por el emisor, por las etiquetas y por las propiedades del gemelo del dispositivo. La característica del filtrado se puede usar cuando se usa Azure IoT Hub estandar, en versiones económicas puede que no este disponible la funcionalidad.

Un vistazo a… Routing(2/16) Se admite cuatro tipos de endpoints:
• Blob storages. • Event Hub. • Service Bus Queue. • Service Bus Topic. Un dispositivo IoT envia telemetría. Por ejemplo:

Un vistazo a… Routing(3/16) Sobre la anterior información queremos que
nos filtre aquellos que cumplen unas ciertas condiciones. Para ello usamos un lenguaje similar a que se usa en los WHERE de SQL, digamos que se parece a SQL, en nuestro argot solemos usar SQL-Like.

Este ejemplo lo que va a realizar es enviar telemetría
de un dispositivo y dicha telemetría la vamos a enrutar a un storage para su posterior análisis. Lanza VS Code y ejecuta el ejemplo. Deja que envíe mensajes cada segundo o cada cinco segundos, a tu parecer. Yo para la demo usaré 1 segundo. csharpRouteSample – Enrutamiento de telemetría https://github.com/jmfloreszazo/HandsOnIoTAzure Un vistazo a… Routing(3/16)

Nos habrá creado 10 dispositivos que irán generando información cada
segundo. Dejamos que se ejecute al menos un par de minutos. Y antes de entrar en materia, comentaros que existe un endpoint creado por defecto, que nos permitirá consumirlo mediante un Event Hub y en un grupo de consumo predefinido (que podemos ampliar): Un vistazo a… Routing(4/16)

Sabiendo esto, es el momento de entrar a crear nuestros
propios endpoints. Para ello: • Hub settings Custom endpoint Add Storage. Un vistazo a… Routing(5/16)

En esta ocasión ponemos un nombre que indique que esta
capturando toda la telemetría generada. Ya que, en la segunda ocasión, vamos a filtrar por dispositivo y solo capturará la que le pidamos. Es decir, crea un nuevo contenedor con el nombre del dispositivo: Ahora vamos a enrutar: • Hub settings Routes Add Storage. Añadimos la ruta y también podemos probar las consultas que vamos a preparar (ver siguiente imagen). Deberás realizar el proceso dos veces, uno sin filtro, lo que ponga por defecto, para llevarnos toda la telemetría y otro como se muestra en la imagen siguiente. Con la definición del endpoint y el enrutamiento, hemos dirigido la información donde queríamos, al mismo tiempo hemos realizado un filtrado de datos que nos ayudará en posteriores análisis, por ejemplo, si solo queremos cuando cambian las propiedades del device twin. Un vistazo a… Routing(6/16)

Un vistazo a… Routing(7/16)

Solo nos queda entrar en el contenedor para ver que
se está generando: En el siguiente enlace podéis ver como funciona con mayor detenimiento los filtros (SQL-Like): https://docs.microsoft.com/es-es/azure/iot-hub/iot-hub-devguide-routing-query-syntax Un vistazo a… Routing(8/16)

Una vez visto como funciona el enrutamiento a un storages,
vamos a ver que pasa cuando lo enviamos a un Event Hub, si queréis podéis modificar ligeramente el ejemplo de Service Bus de la Sección 2 cuando hablábamos de Python además de crear un endpoint para un Service Bus (con este ejercicio que os dejo, ya tendréis todo controlado). Continuemos con Event Hub. No sin antes hacer un pequeño stop y hablar de teoría de este recurso de Azure. En realidad, voy a hablar de Event Grid. Permitirme este pequeño lio hasta que veas a donde quiero llegar. Azure Event Grid tiene las siguientes características: • Es un enrutador de eventos de alto rendimiento, que puede obtener información de cualquier fuente y llevar a prácticamente cualquier destino, que además permite el modelo pub/sub, desacoplado y funciona con temas y suscripciones. • La integración con IoT Hub, nos permite suscribirnos a eventos, telemetría, cuando se crea o de borra o se conecta un dispositivo y nos permite trabajar con filtros. Un vistazo a… Routing(9/16)

De modo esquemático así funciona: Un vistazo a… Routing(10/16) Blob
Storage Event Hub IoT Hub Service Bus Otros... Event Grid Service Bus Otros... Event Hub Function Storage Queue Logic App Event Handlers Event Publisher Temas (DeviceTelemetry, DeviceCreated, DeviceDelete, Suscriptores

Y para terminar os muestro una comparativa entre IoT Hub
con Event Grid frente a IoT Hub Routing: Ahora entenderás que Event Grid es la tecnología subyacente en IoT Hub y por eso he realizado esta explicación tan poco ortodoxa. Continuemos con nuestro ejemplo. Un vistazo a… Routing(12/16) Event Grid Routing Sin orden Garantiza el orden Muchos tipos diferentes de endpoints y creciendo Numero limitado de endpoitns Pagas por operaciones en el Event Grid No añade costes extras Filtrado en el tema y los atributos Filtrado con una condición en la ruta Telemetría Telemetría Eventos del ciclo de vida del dispositivo Eventos del ciclo de vida del dispositivo Cambios en el dispositivo gemelo

Vamos a crear una Function desde el portal: Entramos en
el recurso: • Functionss Add Develop in portal Template = Azure Event Grid Trigger Create Un vistazo a… Routing(13/16)

Ahora nos vamos al IoTHub: • Events + Event Susbcription
Azure Function Template = Azure Event Grid Trigger Y rellenar los campos con lo que os muestro a continuación: Un vistazo a… Routing(14/16)

Solamente nos falta añadir algo de código para que la
función realice alguna cosa: • Function EventGridTrigger1 Code + Test Como podrás ver ya existe una salida logeada que no tendremos que ni tocar, por que nuestra intención no es crear logica de negocio, si no ver que realmente hemos conectado y proyectado la información. Un vistazo a… Routing(15/16)

Arranca el proyecto, ejecútalo durante unos minutos para que genere
telemetría y entra en la monitorización de la Function para que veas el resultado: Como podrás haber visto, es muy sencillo derivar la información al endpoint que nos interese gracias al poder de enrutado de IoT Hub, y lo mejor de todo, sin coste adicional. Un vistazo a… Routing(16/16)

Explicación objetiva – Con datos se ve todo mejor ¡Atención!,
detalle importante MQTT vs AMQP vs HTTP(1/2) Payload MQTT = 518 Bytes vs Payload AMQP = 638 Bytes

¡Atención!, detalle importante MQTT vs AMQP vs HTTP(2/2) Para algo
os he explicado la teoría y era para esto en concreto. Tambien he aprovechado el anterior ejemplo. Como podréis observar el peso del mismo mensaje es diferente en cada protocolo. Este peso del mensaje será una restricción para la red que usemos. Si con HTTP el mensaje llega a pesar 24 bytes, por mucho que quieras (ya que puede estar incluso el contrato de uso firmado) no podrás usar Sigfox. Y eso sin añadir una horquilla para un posible crecimiento del mensaje en unos meses. Conocer esta comparativa os ahorrará muchos quebraderos de cabeza.

Un vistazo a… ASA(1/9) Azure Stream Analytics aka ASA Es
un servicio de gestión de flujos para un gran volumen de datos y es el actor principal de muchas arquitecturas de IoT, por qué: • Tiene análisis en tiempo real. • Es capad de procesar eventos complejos. • Puede procesar datos procedentes de múltiples fuentes. Los componentes que lo forman son: • Entradas y salidas, con consultas SQL-Like, para hacer análisis y agregaciones. • Admite funciones para añadir complejidad y logica. • Puede extraer datos y manipularlos en tiempo real. Los escenarios típicos son: • Análisis de telemetría de IoT. • Encontrar tendencias y desviaciones. Una de las principales ventajas de ASA es que se puede desplegar y configurar en muy pocos minutos, para procesar literalmente millones de eventos por segundo (supongo que te imaginas que no es barato).

Un vistazo a… ASA(2/9) Una de sus grandes ventajas es
que se basa en un lenguaje de consulta similar a SQL y que se puede aprender en muy poco tiempo. Pero la más importante es que ASA es capad de ejecutarse en el Edge. Un trabajo de Stream Analytics obtiene los datos de entrada y de referencia opcionales para utilizarlos en una consulta que realiza el análisis. Estos resultados se trasmiten en streamming a un o varias salidas. Como entrada se puede conectar a un Event Hub, IoT Hub, Blob Storage o Azure Data Lake Storage de segunda generación. La salida podrás distribuirla a diferentes servicios que van desde un Azure Data Lake Storage, Function App, Service Bus, CosmosDB hasta un Power BI. Logicamente no voy a presentar estos servicios, es un objetivo fuera del alcance del libro. ¿Cómo funciona este tipo de consultas? En la siguiente imagen os desgloso su funcionamiento.

Un vistazo a… ASA(3/9) Una de sus grandes ventajas es
que se basa en un lenguaje de consulta similar a SQL y que se puede aprender en muy poco tiempo. Pero la más importante es que ASA es capad de ejecutarse en el Edge. Un trabajo de Stream Analytics obtiene los datos de entrada y de referencia opcionales para utilizarlos en una consulta que realiza el análisis. Estos resultados se trasmiten en streamming a un o varias salidas. Como entrada se puede conectar a un Event Hub, IoT Hub, Blob Storage o Azure Data Lake Storage de segunda generación. La salida podrás distribuirla a diferentes servicios que van desde un Azure Data Lake Storage, Function App, Service Bus, CosmosDB hasta un Power BI. Logicamente no voy a presentar estos servicios, es un objetivo fuera del alcance del libro. ¿Cómo funciona este tipo de consultas? En la siguiente imagen os desgloso una consulta típica.

Un vistazo a… ASA(4/9)

Un vistazo a… ASA(5/9) Aquí puedes ver una explicación exhaustiva
de las consultas. Pero voy a destacar la parte que para mí es la más importante. Ventana de procesado Lo habitual en aplicaciones que procesan en tiempo real, es realizar cálculos sobre un conjunto de datos (agregación) u operaciones sobre un subconjunto que se encuentran delimitadas por un período de tiempo. Y por eso vamos a analizar esas agrupaciones definidas en una ventana de tiempo. • Obtén el X (promedio, cuenta, suma, etc.) por dispositivo, cada 60 segundos. GROUP BY TumblingWindow(second, 60), IotHub.ConnectionDeviceId • Cada 15 segundos, obtener el valor X (promedio, cuenta, suma, etc.) de un dispositivo durante los 30 útimos segundos. GROUP BY HoppingWindow(second, 20, 10), IotHub.ConnectionDeviceId • En cada evento, obtener el valor X (promedio, cuenta, suma, etc.) por dispositivo en los últimos 5 segundos. GROUP BY SlidingWindow(second, 10), IotHub.ConnectionDeviceId • Y aquí tienes el enlace para ampliar sobre los restantes métodos de cálculo.

Un vistazo a… ASA(6/9) Continuemos trabajando con la solución csharpRouteSample.
Pero antes vamos a crear un trabajo de Stream Analytics, sigue los siguientes pasos: La opción edge, puede que se vea en la siguiente sección o en otro caso os ponga un enlace, pero en resumen se trata de hacer un Gateway, que, si que veremos, ya que es importante conocer como crear un Edge Gateway.

Un vistazo a… ASA(7/9) Entramos en Settings, Inputs y un
output para IoT Hub:

Un vistazo a… ASA(8/9) Ve ejecutando el simulador si no
lo habías realizado antes. Ahora creamos la consulta: Una vez guardado. Ejecuta el Stream Analytics Job, mucho cuidado, paralo cuando no lo uses o el consumo de tu cuenta de Azure se resentirá:

Un vistazo a… ASA(9/9) Entra en tu contenedor y observa
el resultado: Te recuerdo: para el job. Como no se trata de estudiar este recurso, te dejo un enlace para que puedas ver como funciona una UDF (User Defined Function): ejemplo de UDF en ASA.

Un vistazo a… Powe BI para IoT(1/4) Power BI No
voy a explicar que es conceptualmente Power BI, dudo mucho que nadie separa para que sirve y su potencial. Realmente no es una pieza del ecosistema de IoT, pero sí que es una herramienta que nos ayuda cuando debemos hacer cuadros de mando de IoT, ya que tiene controles exclusivamente dedicados a este componente. Vamos directos al ejemplo que os planteo. Deberás tener una cuenta de Power BI, si no lo tienes, en este enlace puedes obtenerlo. El pipeline de ejecución esta asociada a ASA, por eso, he decidido ponerlo en esta posición de la sección. Ejecuta nuestro simulador de telemetría, el que venimos usando en esta sección y déjalo emitiendo mientras nosotros continuamos. Device Azure IoT Hub Azure Stream Analytics Power BI

Un vistazo a… Power BI para IoT(2/4) Crea un nuevo
built-in endpoint en Azure IoT Hub: Ahora creamos un nuevo trabajo de ASA, con un nuevo input al grupo de consumo anterior y de endpoint messaging. Tambien creamos una salida y la consulta. No olvides de ejecutar el trabajo de ASA y pararlo cuando termines este ejemplo.

Un vistazo a… Power BI para IoT(3/4)

Un vistazo a… Power BI para IoT(4/4) Ejecuta Power BI
y creamos un nuevo report: Y a partir de aquí, ya puedes seleccionar el valor EventEnqueuedUtcTime y el valor que quieras mostrar en el grafico de lineas. Esto ya depende más de tus conocimientos de Power BI, conocimientos que se escapan a este curso.

Un vistazo a… TSI(1/14) Azure Time Series Insights Una base
de datos de series de tiempo (TSDB) es un sistema de software optimizado para ordenar y organizar información medida por el tiempo. Una serie de tiempo es una colección de puntos de datos que se recopilan en intervalos sucesivos y se registran en e orden con la medida del tiempo. Algunos ejemplos de TSDB: operaciones bancarias, mediciones de un sistema de monitorización y observación de microservicios (ver mi workshop al respecto), datos provenientes de IoT, etc. Las TSDB son útiles para supervisar métricas, como ya expliqué en el curso al que menciono, ya que pueden clasificar grandes y complejas cantidades de datos, haciendo que la información sea más accesible que si se almacena en una base de datos tradicional. No deja de ser una implementación sobre motores NoSQL, lo mismo que ocurre con Gremlin o Neo4J, donde hablé en su día de las bases de datos de grafos, digamos que estas bases de datos son la cuarta después de las bases de datos relacionales, las no relacionales y las de grafos. ¿Qué son las bases de datos de series temporales? Existen diferencias entre la base de datos que he mencionado y estas TSDB. Por ejemplo, los cambios se insertan en vez de sobrescribirse, por tanto, muestran un historial de esa información. Tambien nos permite realizar análisis más profundos en tiempo real de todos los datos en lugar de usas el otro tipo de base de datos, que es de datos estáticos. Los datos de la TSDB nos permiten revelar una imagen completa de un sistema a lo largo del tiempo y por tanto analizar tendencias históricas. A quien venga de la estadística le sonarán las series estocásticas.

Un vistazo a… TSI(2/14) Las características de principales de una
TSDB son: • Los datos se recogen durante un periodo de tiempo determinado. • Los datos siempre son inserciones, no existen actualizaciones. • Cuando se escriben datos, se asigna automáticamente al intervalo de tiempo más reciente. ¿Por qué es imporante una TSDB? Nos ayudan a supervisar la información en tiempo real (near real-time) y abordar problemas a medida que se producen. Tambien se pueden usar para predecir y actuar en consecuencia. Están optimizadas para obtener un mayor rendimiento con las consultas a pesar de la cantidad de datos almacenado. Alguna de las ventajas de utilizar una TSDB: • Es capad de escanear cantidades extremadamente grandes de datos a la vez. • Si los datos se recogen cada milisegundo, la base de datos puede comprimirlos a un minuto o incluso a intervalos más cortos. Es decir, el data sampling. • Las TSDB utilizan interfaces de programa de aplicación (API) que se pueden escribir.

Un vistazo a… TSI(3/14) Un ejemplo muy claro es Azure
Application Insight:

Un vistazo a… TSI(4/14) Donde el gasto de almacenamiento en
la nube esta ligado a las variables de ingesta, retención de datos y sampling. Por ejemplo, un caso de uso muy común en el mundo de la monitorización es dejar unas marcas de despliegue (ver articulo al respecto) y ver la diferencia de uso de la CPU Mantener los datos fijos separados de los dinámicos facilita a las TSDBs la búsqueda y la obtención rápida de puntos de datos específicos. A parte de Azure Application Insight que esta basado en una TSDB, tenemos una base de datos como InfluxDB o Prometheus de código abierto.

Un vistazo a… TSI(5/14) Para mi el problema de una
TSDB es: • El precio tanto on-premise como en Cloud. • El escalado de almacenamiento, tanto físico como de memoria. • La política de retención, práctica para eliminar automáticamente la información que ya no es relevante. De este modo, se garantizará que haya espacio suficiente para la nueva información. • Y que las TSDB suelen requerir una mayor cantidad de código, así como un código más complejo en las aplicaciones para acceder a los datos. Conclusión Existen casos de uso muy claro que directamente nos llevan a una implementación de este tipo de bases de datos y son el motor ideal para ello. Solo tenéis que ver que Microsoft lo hace tanto par IoT con Azure Time Series Insight como Azure Application Insight. Ahora vamos a centrarnos más en las Time Series Insight (TSI) de Azure. Cuyos casos de uso típicos pueden ser: • Detección de anomalías. • Monitorización. • Integración con otros servicios.

Un vistazo a… TSI(6/14) Sirven para análisis basados en el
tiempo a escala: • Visualizar y explorar • Desde IoT Hub y Event Hub Cuyo almacenamiento de datos puede ser: • Almacenamiento en frío (parquet) • Almacenamiento en caliente (ad-hoc) • Análisis y aplanamiento de JSON Podremos verlo con: • Gráficos • Mapas de calor • Tablas Podemos consultar a este servicio via: • API REST • Expresiones de series temporales (TSX) • TSI Explorer • Modelos y variables Y tiene seguridad añadida para que podamos conectarnos con tranquilidad.

Un vistazo a… TSI(7/14) Por si te lo preguntabas vamos
a ver: ASA vs TSI ASA TSI Agregaciones Visualización Filtros Drill down No almacena datos por si mismo Almacenamiento cold y warm Lenguaje SQL-Like TSX, lenguaje de expresiones y consultas Datos de referencia Modelo jerárquico Análisis posterior Analisis posterior Para insight a medida

Un vistazo a… TSI(7/14) Vamos a usar el mismo ejemplo
que hemos usado antes para generar telemetría; lanza el emulador y dejar generando datos para que podamos usarlos. Y creamos nuestro TSI:

Un vistazo a… TSI(8/14) Tenemos que alimentar al recurso TSI
mediante un build-in endpoint de IoT Hub: Ahora desde el TSI que has creado añadimos un nuevo event source:

Un vistazo a… TSI(9/14) Ponemos las siguientes características al event
source que hemos creado:

Un vistazo a… TSI(10/14) Entramos en la ULR que expone
nuestro TSI: Y observa el panel de telemetría en tiempo real:

Un vistazo a… TSI(11/14) Entretente un poco en jugar con
la herramienta. Por ejemplo, puedes ver los datos en formato tabulados:

Un vistazo a… TSI(11/14) En los siguientes enlaces podrás ampliar
información de uso de TSI: • Custom models. • A sincronizar los modelos de TSI con Digital Twins. • Y a usar el API REST correspondiente. Logicamente aprender el 100% del uso de este recurso ya depende de ti, si no, el libro se convertiría en algo inmanejable. Ya tienes las pitas, te toca investigar. Para finalizar voy a mostraros como enlazar TSI con Power BI. Del mismo modo que usábamos Stream Analytics para Power BI, vamos a ver como podemos usar TSI como fuente de datos para que nutra a Power BI, en esta ocasión la versión de escritorio que puedes obtener desde este enlace. En esta ocasión si que voy a mostrarte como queda el informe final, que no mostré anteriormente y reserva para esta ocasión. Ya que es muy posible que, a nivel de organización, ejemplo anterior, no tengas derechos para entrare en un grupo de trabajo, única diferencia que existe con este caso. Ten encuentra que será un poco más lento trabajar contra TSI que contra ASA.

Un vistazo a… TSI(12/14) Cargamos nuestra aplicación de Power BI
de escritorio y Get Data:

Un vistazo a… TSI(13/14) Pegamos la consulta que hemos traído
de TSI Explorer (podrías hacerla tu por tu cuenta) y si nos pide hacer login en Azure, pon tus credenciales: Conectas y tras unos instantes te mostrará la tabla:

Un vistazo a… TSI(14/14) A partir de este momento, ya
te toca trabajar sobre tu Power BI. Ten en en cuenta que si en vez de enviar los datos a TSI lo envías a un blob, también podrías mostrarlo en Power BI (es otra de las diferentes alternativas que tienes): Y a partir de aquí, con la información de la telemetría o la información precocinada, etc. Tienes infinidad de opciones para mostrar los datos que necesiten ver las diversas entidades del ecosistema… Power BI es una herramienta muy potente con la que te recomiendo que te familiarices a la hora de hacer informes; te puede ayudar mucho. Nunca está de más conocer este tipo de herramientas. En mi vida profesional he realizado miles de informes y la verdad que es un mundo apasionante a la par que divertido si los datos son tu pasión.

Ejemplo de… Arquitectura de referencia Integración – ¿Cómo queda cada
pieza que hemos aprendido? Arquitectura basada en: https://docs.microsoft.com/es-es/azure/architecture/solution-ideas/articles/iot-azure-data-explorer IoT Hub Event Grid App Service Function App Machine Learning Azure Cosmos DB Azure Maps SQL Server Storage Blob Event Hubs Trabajos de Stream Analytics Power BI Time Series Insights TSI Explorer Other Apps & Services Wind Turbine s Park Back Office Web Brownser Telemetría Telemetría Enrutada Información GPS Turbina Telemetría enriquecida Telemetría Agregada Telemetría Agregada Cold Storage

Para terminar… Para pensar • ¿Quiero usar una TSDB y
la red de SigFox?, pues os diría que no tiene mucho sentido usarlo por qué la información de una TSDB es para una telemetría con una cadencia de información menor que la ofrece la trasmisión SigFox. • ¿Quiero usar una Stream Analytics y 5G?, independientemente del coste, es una decisión acertada, 5G nos permite enviar mucha información que permite explotar el potencial de Azure Stream Analytics. • Tengo que actualizar los carteles luminosos de las carreteras. ¿Qué protocolo debo usar? Pues tendrás que ver si la tecnología que te gustaría implementar, por ejemplo, 5G, esta soportada en tu región y si esta, ¿quieres mantener dos versiones? Tal vez… Como veis, si tenéis las herramientas, las conocéis mínimamente, podréis proponer soluciones acertadas. Que sean las más optimas puede que si o que no, eso dependerá del nivel de conocimientos de cada uno, pero al menos no vamos a proponer cosas que no cumplan con los requisitos de la aplicación. Con toda la información adquirida en este capitulo ya podemos comenzar una aplicación IoT. Ya tenéis todo lo básico para empezar. La siguiente sección, son recetas que solucionan problemas comunes, recursos que ayudan de forma puntual o bien temas que son más complejos y que solo aportan valor a una minoría de proyectos, que tampoco debe dejar desamparados. ¿Tiene sentido? – Si, no, tal vez…

Sección 7 Avanzado

Un pilar fundamental Monitorización(1/17) En IoT también tenemos que tener
en cuenta la parte de monitorización y observación de aplicaciones. En resumen, es supervisar, solucionar problemas y optimizar la solución de IoT. Voy a intentar que pueda ver desde configuraciones, resoluciones de problemas, realización de pruebas hasta diagnostico de extremo a extremo. Monitorizar comprende 7 áreas bien definidas: • Configurar métricas. • Configurar Logs. • Consultas y visualización mediante Azure Monitor. • Uso de Azure Policy. • Escalado. • Obtener diagnósticos de Azure IoT Edge. Observar y Monitorizar – Te remito a Monitorización Moderna de Aplicaciones

Un pilar fundamental Monitorización(2/17) Configurar métricas Las métricas nos permiten
instrumentar las áreas claves de IoT para que podamos realizar un seguimiento del rendimiento, predecir los requisitos del ciclo de vida del dispositivo y solucionar problemas. Los diagnósticos y las métricas de IoT Hub se basan en Azure Monitor Service y están integrados directamente.

Un pilar fundamental Monitorización(3/17) Además de estas métricas podemos configurar
las alertas sobre las métricas que deseemos que nos adviertan sobre problemas que nosotros consideremos graves y por último enviarlo a un grupo de acción. Una de las razones por la que queremos y debemos poner esto, es por qué, por ejemplo, si hemos firmado un SLA con un cliente que mantenga un nivel de mensajes dentro de un rango y comenzamos a gestionar mensajes por debajo del SLA, estaremos incumpliendo el acuerdo y lo mejor es que seamos reactivos, no proactivos, que sean nuestros equipos quien avisen y no los del cliente.

Un pilar fundamental Monitorización(4/17) Tambien puede darse el caso que
un estén fallando las actualizaciones de los dispositivos gemelos, por ejemplo, da error en un hardware que en teoría ya se había arreglado, si no tenemos mecanismos para saber si esta enviando la información correctamente, perderemos mucho tiempo y dinero al enviar un equipo de mantenimiento a un generador eléctrico. No solo debes monitorizar IoT Hub, si no, todas las demás piezas, es algo evidente y que si has leído el documento que tengo sobre monitorización, podrás haber interiorizado todo esto. Sobre todo, existe una relación directa entre la monitorización, las alertas y el autoescalado, que deberás comprender para que nuestra aplicación continue funcionando adecuadamente en picos y des-escarlar para no incurrir en gastos innecesarios. Los escenarios donde es necesario monitorizar serán muy diferentes, pero la base inicial parte de las secciones de monitorización y alertas de tu recurso. Si tuviera que elegir las Metricas, comenzaría con aquellas de alto nivel: • Mensajes usados. • Mensajes D2C. • Dispositivos conectados. • Dispositivos totales.

Un pilar fundamental Monitorización(5/17) Si usamos las Metricas, por ejemplo:

Un pilar fundamental Monitorización(6/17) Logs IoT Hub se puede configurar
para recopilar registros de diagnóstico para eventos clave. Estos registros pueden enviarse a diversas ubicaciones para su procesamiento, generación de informes o automatización. Y al igual que las métricas de IoT Hub, los diagnósticos no se recopilan de forma predeterminada, sino que debes configurarlo tu. Se puede acceder a los registros enviados por Logs Analytics directamente desde IoT Hub, en lugar de acceder via Azure Monitor (como prácticamente cualquier recurso de Azure). Tenemos varias opciones donde enviar el contenido del registro de IoT Hub: Wind Turbine s Park IoT Hub Blob Storage Log Analytics Event Hub

Un pilar fundamental Monitorización(7/17) Con las consultas de Kusto (KQL),
lenguaje similar a SQL que nos permite visualizar el contenido de los registros enviados a Log Analytics directamente desde IoT Hub. Al igual que tenemos la opción de enviar a diferentes ubicaciones, si así es nuestro deseo, también podemos optar por enviar métricas, registros etc. Incluso cambiarlos. La información que podemos obtener es muy amplia, van desde conexiones a desconexiones de dispositivos, Metricas concretas de telemetría del dispositivo o todas, problemas con métodos directos, enrutamientos, Jobs, actualizaciones de los gemelos, etc. Debo puntualizar que ninguno de estos registros esta dirigido al firmware del dispositivo, por tanto, son errores puramente locales del dispositivo. Veamos como configuramos los logs de diagnostico.

Un pilar fundamental Monitorización(8/17)

Un pilar fundamental Monitorización(9/17) Un ejemplo de KQL:

Un pilar fundamental Monitorización(10/17)

Un pilar fundamental Monitorización(11/17) Policy Al crear recursos en Azure,
podemos usar Azure Policy para garantizar que esos recursos se ajusten a un conjunto de reglas que especificamos. IoT Hub tiene soporte limitado para Azure Policy. Solo existe un único requisito de configuración disponible: registros de diagnóstico. Con Azure Policy, podemos aplicar reglas contra la creación de nuevos recursos de Azure IoT Hub, así como los recursos existentes. Las directivas de Azure se aplican a IoT Hubs nuevos y existentes, marcando los IoT Hubs como no conforme si al menos una configuración de registro de diagnóstico no está configurada. Cada política asignada se puede abarcar desde el nivel de suscripción hasta un grupo de recursos. En general, también es posible excluir ciertos recursos de la aplicación de políticas si, por ejemplo, los está utilizando en un entorno de desarrollo o si necesita aplicar una política más específica.

Un pilar fundamental Monitorización(12/17) Escalado Aunque IoT Hub no ofrece
la función de escalado automático, podemos usar código para realizar esto en su lugar. Podemos elegir entre varios niveles de Azure IoT Hub y que cada nivel tiene varias unidades entre las que podemos elegir. Estos niveles y unidades nos permiten escalar IoT Hub para que coincida con nuestra solución. Si superamos las cuotas de desarrollo de nuestro nivel y unidad seleccionados de IoT Hub, estamos sujetos a las limitaciones correspondientes. Para los niveles básico y estándar, podemos ampliar o reducir nuestro IoT Hub para que coincida con los requisitos de nuestra solución en cualquier momento. Sin embargo, no se proporciona ninguna recurso u opción ad-hoc para escalar automáticamente nuestra solución de IoT, por lo que tenemos que gestionarlo nosotros mismos. Microsoft ha proporcionado una solución de muestra que ilustra cómo podemos abordar el escalado programático de nuestra solución IoT. La aplicación de ejemplo utiliza Azure Durable Functions.

Un pilar fundamental Monitorización(13/17) https://github.com/Azure-Samples/iot-hub-dotnet-autoscale IoTHubScaleInit • TimeTrigger IoTHubScaleOrchestator •
Orquestador IoTHubScaleWorker • Worker

Un pilar fundamental Monitorización(14/17) Obtener diagnósticos de Azure Iot Edge
Además de lo que hemos visto, existen unas métricas exclusivas de IoT Edge que provienen de los IoT EdgeAgent y los EdgeHub (que hemos visto en las secciones anteriores). Estos módulos exponen métricas a las que podemos acceder y que pueden ser ingeridas por Prometheus. Recuerda que se usan contenedores. Los modulos muestran sus métricas en el puerto 9600. Sin embargo, este puerto no esta disponible si no se configura primero. Para ello nos tocará modificar el manifiesto de implementación y añadir el puerto 9600. Una vez realizado este paso, podemos apuntar nuestro navegador a la IP del dispositivo IoT Edge y agregar el puerto de desarrollo para ver las métricas en formato raw. Logicamente en vez de usar Prometheus podemos exponer las métricas directamente a Azure.

Un pilar fundamental Monitorización(15/17) Obtener diagnósticos de Azure IoT Edge
Además de lo que hemos visto, existen unas métricas exclusivas de IoT Edge que provienen de los IoT EdgeAgent y los EdgeHub (que hemos visto en las secciones anteriores). Que podrás ver directamente con CLI o directamente en el portal, así como los mensajes correspondientes de error y su log. Además, estos módulos exponen métricas a las que podemos acceder y que pueden ser ingeridas por Prometheus. Recuerda que se usan contenedores. Los modulos muestran sus métricas en el puerto 9600. Sin embargo, este puerto no esta disponible si no se configura primero. Para ello nos tocará modificar el manifiesto de implementación y añadir el puerto 9600. Una vez realizado este paso, podemos apuntar nuestro navegador a la IP del dispositivo IoT Edge y agregar el puerto de desarrollo para ver las métricas en formato raw. https://github.com/microsoft/azure-iothub-exporter

Un pilar fundamental Monitorización(16/17) Logicamente y como era de esperar,
en vez de usar Prometheus podemos exponer las métricas directamente a Azure. Pero es algo que esta en preview:

Un pilar fundamental Monitorización(17/17) Tambien puedes usar Power BI o
Grapana para hacer tus Dashboard o bien usar el Dashboard por defecto de Azure. Esto esta muy bien, pero que sepas que existe otra opción muy interesante y que particularmente he usado mucho en monitorización para operaciones que son los Workbooks que escapan a este curso y tendrás que investigar por tu cuenta. Punto y seguido – Workbooks

¿Para qué sirven los … Gateways(1/5) Los dispositivos IoT Edge
pueden funcionar como puertas de enlace, lo que proporciona una conexión entre otros dispositivos de la red y su instancia de IoT Hub. El dispositivo que actúa como gateway puede funcionar como si fuera un IoT Hub, por tanto, puede controlar conexiones de cualquier dispositivo que tenga una identidad con la misma instancia de IoT Hub. Este tipo de patrón se denomina transparente, porque los mensajes pueden pasar desde el dispositivo de nivel inferior hasta el IoT Hub como si no existiera una puerta de enlace entre ellos. En el caso de los dispositivos que no pueden conectarse por si solos a IoT Hub, la puerta de enlace de IoT Edge les ofrece esa conexión. Este tipo de patrón de enlace se denomina traducción, porque el dispositivo IoT Edge tiene que realizar el procesamiento de los mensajes de dispositivo de nivel inferior entrantes antes de que se puedan reenviar a IoT Hub. Estos escenarios requieren de modulos adicionales en la puerta de enlace de IoT Edge para administrar los pasos de procesamiento. Los patrones de puerta de enlace transparente y traducción no son excluyentes. Un solo dispositivo IoT Edge puede funcionar con ambas puertas. Estos patrones nos proporcionaban las siguientes ventajas: Gateways – Puertas de enlace

¿Para qué sirven los … Gateways(2/5) • Análisis perimetral: puedes
usar servicios IA en entornos locales para procesar los datos que proceden de dispositivos de nivel inferior sin enviar datos de telemetría. Busca y reacciona a la información local y solo envia un subconjunto de datos a IoT Hub. • Aislamiento de dispositivos de nivel inferior: el dispositivo de puerta de enlace puede proteger a todos los dispositivos de nivel inferior de la exposición a internet. Se puede situar entre una red de tecnología operativa (OT, sin conexión a internet) y una rede de tecnología de la información (IT). Del mismo modo que se usan para conectar los dispositivos que no tienen capacidad de conexión a IoT Hub. • Multiplexación de conexiones: todos los dispositivos que se conecta con a IoT Hub mediante un IoT Edge Gateway podrán usar la misma conexión subyacente. Es obligatorio usar AMQP como protocolo para obtener esta capacidad. • Suavizado del trafico: a parte de servir para almacenar localmente todos los mensajes, nos permite implementar un sistema de exposición de la información. Hace resiliente nuestra solución a picos de trafico. • Compatibilidad sin conexión: nos permite almacenar en un dispositivo IoT Edge toda aquella información de telemetría y dispositivo gemelo que no sea compatible con IoT Hub, por tanto, no se entrega y puedes implementar un sistema personalizado para este caso.

¿Para qué sirven los … Gateways(3/5) Puertas de enlace transparentes
En resumen, un dispositivo que teóricamente no puede conectar con IoT Hub tendrá que conectar con un dispositivo que hace de puerta de enlace. Los dispositivos de nivel inferior tendrán sus propias identidades de IoT Hub y se conectarán con protocolo MQTT o AMQP. Por tanto, la puerta de enlace simplemente pasará la información del dispositivo a IoT Hub. Conceptualmente se trata de una jerarquía. Desde aquí podrás leer un amplio documento donde se explican las jerarquitas (imagen anterior) de las puertas de enlace. Aunque resumo brevemente lo que son las relaciones primarias y secundarias: la puerta de enlace de IoT Edge se debe considerar el elemento primario y de un dispositivo inferior secundario que se conecta a ella.

¿Para qué sirven los … Gateways(4/5) Puertas de enlace de
traducción Si los dispositivos de nivel inferior no se pueden conectar a IoT Hub, la puerta de enlace de IoT Edge debe actuar como traductor. Normalmente son dispositivos con protocolos incompatibles con MQTT, AMQP o HTTP. Otros protocolos, como Modbus, BACnet, etc. no podrán conectar con IoT Hub y por tanto la puerta de enlace traduce la información. Muchos modulos de terceros que tienen hardware específico o un protocolo de nivel inferior deben implementar una puerta de enlace. Lo habitual es traducir todo el contenido del mensaje. Existen dos tipos de protocolos de traducción: traducción del protocolo y de identidades. • Ya lo hemos visto, pero: el modulo de traducción recibe los mensajes del dispositivo de nivel inferior y los convierte a un mensaje de protocolo admitido, a continuación, la puerta de enlace envia los mensajes en nombre del dispositivo inferior. • En este caso, el modulo superior IoT Edge Gateway proporciona además una identidad a los dispositivos. Es decir, tanto traduce como es capad de añadir una identidad IoT Hub lo que nos permite convertir en dispositivos totalmente administrados en IoT Hub, nunca sabrás que esos dispositivos originalmente vienen de una puerta de enlace de traducción de identidad.

¿Para qué sirven los … Gateways(5/5) Logicamente existen ejemplos muy
interesantes de los que podrás aprender mucho y aquí os dejo una serie de enlaces al respecto: • Azure IoT Edge LoRaWAN Starter Kit. • Conexión de un dispositivo IoT Edge de nivel inferior a una puerta de enlace Azure IoT Edge. • Implementación de un módulo Proxy. • Ejercicio 3 del Workshop de seguridad de IoT. Y en el Azure Marketplace podrás encontrar ya algunos modulos de IoT que van desde traducciones hasta análisis perimetral. Ejemplos – Salgamos de la teoría

Industria 5.0 IA 2.0(1/2) Gracias a este Workshop de Microsoft:
https://github.com/microsoft/MCW-Predictive-Maintenance-for-remote-field-devices Podemos ver un magnífico ejemplo sobre la aplicación de la IA en IoT. Donde se aplica el mantenimiento predictivo en dispositivos remotos. Créditos de las imágenes: Microsoft Mediante un Ejemplo – De extremo a extremo

Industria 5.0 IA 2.0(2/2) Si extrapolamos este conocimiento a nuestro
proyecto guía, podemos observar que Azure Cognitive Services, concretamente Computer Vision o quizá puedes crearte tu propia Azure Function con .NET ML (puedes ver otro de mis cursos aquí) y aplicar desde 0 Machine Learning: En cualquier caso, ya tienes la base para poder crear tu propio ejemplo de IA aplicado al IoT. Como podréis ver, al final, solo se trata de encajar las piezas necesarias en la arquitectura de de la aplicación. En el caso más eficiente y si es posible, os recomiendo usar Edge Computing.

Otro enfoque Blockchain en IoT(1/3) Blockchains aporta una serie de
cambio significativos en muchos sectores debido a la característica de la inmutabilidad y transparencia. Estas dos características son muy deseadas en muchos sectores. En la Industria 4.0 este aporte de transparencia y confianza aporta un beneficio intrínseco a cadenas de suministro, seguimientos de pagos, gestión de bases de datos, seguridad y un largo etc. Por el contrario, las blockchains necesita una implementación y mantenimiento que no esta al alcance de cualquiera. Si quieres saber más de las blockchains, puedes buscar en mis publicaciones al respecto, donde explico: ¿qué es el algoritmo de consenso?, ¿PoW?, ¿Pos?, ¿DPoS?, etc. Una serie de conceptos que debes conocer para comprender bien el potencial en IIoT. ¿Por qué necesitamos Blockchain en la industria? La industria actual esta pasando por una fase de transformación, incluso ya hemos hablado de Industria 5.0. Quizá el gran revulsivo son las startup que están aportando ideas innovadoras. Y la respuesta es obvia: eliminación de cualquier interacción manual entre las actividades. Revolucionando IIoT – Una unificación

Otro enfoque Blockchain en IoT(2/3) Aunque algo ya hemos hablado
con anterioridad los puntos clave son de aplicación de IoT en la industria son: • Automatizaciones en la cadena de suministros. Gracias a Computer Vision en dispositivos IoT podemos mantener un stock optimizado. La información de captura de la imagen estará garantizada por Blockchain. • Seguridad y privacidad. Obviamente si las información de un dispositivo IoT se basa en una transacción de Blockchain se demuestra fehacientemente que la información es buena y no manipulada. • Trazabilidad de las distintas fase de mano factura. Ya hemos visto un ejemplo de logística con IoT. • Sistemas de Pagos. Podemos permitir a un dispositivo IoT realizar el pago automáticamente, es decir que tome su propia decisión. Por ejemplo, el contador de la luz asegurado por Blockchain que envía la información de consumo y realiza automáticamente el pago con una información de consumo veraz. Aunque te suene a ciencia ficción, esto ya esta implantado. • Computación Cloud y Edge. Nos puede servir para proporcionar transparencia a la hora de inspeccionar y pasar auditorias. Por ejemplo en la industria automovilística, para que no ocurra como pasó con el caso de las emisiones falsificadas: un motor emite información capturada por el hardware evaluador de emisiones llevando sus datos a una Blockchain.

Otro enfoque Blockchain en IoT(3/3) Para concluir y por qué
lógicamente y aunque puedo montar una infraestructura con Azure, por el coste económico que supone para poner en marcha una Blockchain, solamente os dejo mis conclusiones: Que los grandes problemas actuales son la huella de carbono que supone la Blockchain, la falta consorcios dispuestos a afrontar el coste de distribuir y comenzar la cadena de bloques necesaria para el consorcio y que aun es pronto para poder ser disruptivos en sectores muy anclados en el pasado como son la banca o aseguradoras por no pasar por las notarias, sistemas que aportan muchos impuestos al estado, más o menos podríamos decir que las regulaciones gubernamentales. Y que los grandes beneficios será derivados de los problemas: ahorro de costes. Si desea montar una Blockchain con Azure: https://azure.microsoft.com/es-es/solutions/blockchain/ Y mi documento sobre Blockchain: https://jmfloreszazo.com/blockchain-con-azure/

Algunas recetas … Azure Maps para IoT: Geovallas Como este
libro no pretende extenderse mucho más, a continuación os presento una aplicación de Azure Maps. Este ejemplo donde se hace un seguimiento de salidas y entradas de un material de construcción sobre el perímetro del área de una obra, es completamente extrapolable a vehículos que pertenecen a un comercial y no queremos que nos pase el gasto de combustible cuando sale del área asignada. Control y Seguridad – Otra de las máximas de la vida

Algunas recetas … Azure Indoor Maps Los mapas raster de
Autocad de edificios o plantas de producción pueden tener una nueva vida útil. Gracias a que estos archivos pueden ser colocados sobre la capa de un mapa de Azure Maps y usar sus delimitaciones o posiciones geográficas, podemos aportar información en tiempo real desde la temperatura de un área específica hasta la información en tiempo real de cada molino eólico de nuestro parque. Estos son dos ejemplos muy sencillos que pueden llegar a extrapolarse a otros más complejos como la aviación o el transporte marítimo. Por ejemplo, aquí podemos ver una implementación entre Azure Map y Azure Digital Twins: https://docs.microsoft.com/th-th/azure/digital-twins/how-to-integrate-maps Mapas de interior – Otra forma de representación visual

¿Qué es? Fog Computing(1/2) O también conocido como Fog Networking
o Fogging. Es una arquitectura que se usa en los dispositivos edge para lleva a cabo computación (Edge Computing, computación en el borde), almacenamiento, comunicación a nivel local y enrutado a traves de la red a internet. Es decir que Fog Computing es lo mismo que Edge Computing, pero refiriéndose más a la arquitectura. Con otras palabras: la computación en el borde o nebulización facilita operaciones de computo, almacenamiento, y redes entre dispositivos finales y centros de computación en la nube. Como podrás observar, no es nada nuevo, si no que estoy formalizando el concepto que ya has aprendido anteriormente en este capitulo con las puertas de enlace, la IA y las blockchains. Por puntualizar: • Computación en la nube como en la niebla, proporcionan computación, almacenamiento, aplicaciones y datos a los usuarios finales. Sin embargo, la computación en la niebla esta más cerca de lo usuarios finales y tiene una distribución geográfica más amplia. • Puedes llegar a confundirlo con la computación perimetral que generalmente se refiere a la ubicación de la instancia de lo servidores; pero la computación en la niebla implica distribución de la comunicación, la computación, los recursos de almacenamiento, lo servicios y los dispositivos. Fog – Niebla

¿Qué es? Fog Computing(2/2) El National Institute of Standar and
Technology en 2018 establece una definición formal, cuya traducción vendría a ser: La gestión de los datos generados por los sensores y actuadores de Internet de las cosas (IoT) es uno de los mayores desafíos que se enfrentan al implementar un sistema de IoT. Los sistemas tradicionales de IoT basados en la nube se ven desafiados por la gran escala, la heterogeneidad y la alta latencia que se observan en algunos ecosistemas de nube. Una solución es descentralizar las aplicaciones, la gestión y el análisis de datos en la propia red mediante un modelo informático distribuido y federado. Este enfoque se conoce como computación de niebla. El siguiente documento, además habla de otra tecnología llamada Mist Computing, pero esto te lo dejo ya a ti: Fog Computing Conceptual Model. Nota final sobre esta introducción, si alguien lo esta pensado, Edge Computing puede tener una definición diferente ya que algunos autores definen edge cuando el dato se procesa en el mismo dispositivo o el sensor, mientras que fog es cuando se procesa en otro nodo o en el IoT Edge Gateway.

El concepto de moda Metaverso en IoT(1/2) La novela Snow
Crash de Neal Stephenson, del genero Ciberpunk data de junio de 1992 y este autor se prodiga con la palabra Metaverso y Avatar. Y como veis no es Facebook y ningún otro fabricante quien acuña Metaverso o ya que estamos avatar. En la entrada de la wikipedia, por fin, alguien le dio como fuente principal del concepto. Cuando Facebook lo anunció, perdón Meta, mucha gente le dio la credibilidad a quien no corresponde. Es más existe un articulo de Microsoft de Mayo de 2021 donde se habla de este tema… pero ya sabemos que Facebook, Meta, mueve mucha masa, y fue en Octubre/Noviembre de 2021 cuando cuenta su peculiar versión. Muchos, es día, nos acordamos de Second Life y el libro de 2007: The Entrepreneur’s Guide to Second Life: Making Money in the Metaverse Metaverso es una representación digital de algo real. Por tanto, en IoT y concretamente Digital Twins tiene una relación directa. Ahora mismo con las Hololens de Microsoft y gracias a sus guías y asistencia en campo, podemos desplegar un menú de opciones para reparar una pieza. Realidad aumentada, virtual o mixta – Un nuevo mundo para Digital Twins

El concepto de moda Metaverso en IoT(2/2) En el mundo
de IoT con unas gafas de realidad mixta podemos pasar por la fabrica y ver cada herramienta, robot, panel, exponiendo su telemetría y su estado, así como la referencia con su gemelo digital. Es decir, será la forma de ver el mundo real a partir de la implantación de sistemas mixtos que nos permita ver su gemelo. Fundamentalmente el mundo real estará conectado a su mundo virtual. Si te apetece meterte un poco a nivel de desarrollo, en esta ruta de aprendizaje de Microsoft tienes un buen ejemplo. Creo que con las dos imágenes que ilustran esta pequeña explicación tendréis claro que es el Metaverso, para que sirve en IoT. Créditos de las imágenes: Microsoft

Sección 8 Otras opciones

¿Por qué? Introducción(1/2) Conociendo las debilidades y las fortalezas de
cada proveedor cloud en lo referente a IoT, así como los proyectos Open Source, podrás tener un control exhaustivo de las carencias de tu arquitectura. No digo que Azure las tenga, si no, que conocer como otros proveedores, diseñadores de software, productos, ... resuelven el mismo problema, pueden arbitre los ojos de par en par y ver como adaptar aquello que tienen y es mejor de lo que estás tu usando o dejar la puerta abierta a una posible implementación a futuro, por que bien sabemos que al final los proveedores y fabricantes terminan por copiarse entre ellos. Y yo no soy quien dice que Azure sea la mejor plataforma IoT de 2021, eso ya lo dicen otros: https://azure.microsoft.com/en-us/blog/microsoft-named-a-leader-in-the-2021-gartner-magic-quadrant-for-industrial-iot-platforms/ ¿No era solo de Azure? – Soy partidario que conocer a todos los jugadores de la liga

¿Por qué? Introducción(2/2) Por eso he usado Azure de Microsoft,
por qué hoy por hoy es quien esta al frente del mercado en muchos aspectos. Tambien es cierto, que toda la teoría que os he puesto es para que el libro pueda tener su parte agnóstica y cierta partes al no depender de una tecnología en concreto, nos permita tener un libro que pueda perdurar un poco más. Con esta breve introducción, a mi siempre me gusta fundamentar porqué tomo una u otra decisión. A partir de aquí os voy a poner de la forma más resumida posible que otros actores existen en el ámbito de IoT, herramientas propietarias, open source, proyectos, etc. Acompañarme en estas últimas páginas de libro.

Comparaciones Tablas y listados(1/4) Principales recursos y nubes, para que
puedas extrapolar las herramientas entre distintos fabricantes: Azure AWS GCP IBM Device (all have , Linux & Windows & Mac Libs) Azure RTOS, Azure Sphere, Azure Percept. Amazon FreeRTOS. Edge TPI, Google ASIC chip N/A Edge Gateway IoT Edge IoT GreenGrass Cloud IoT Edge IBM Edge App Manager IoT Hub IoT Hub AWS IoT Core Cloud IoT Core IBM Watson IoT Platform Device management Azure Device Provisioning Portal AWS IoT Device Management Device Manager IBM Maximo, IBM Tririga & IBM Engineering LM Event processing Stream Analytics AWS IoT Events Cloud Pub/Sub + DataFlow N/A Analytics Azure Databricks AWS IoT Anaytics DataFlow IBM Stream Analytics Data visualization dashboard Time Series Insights AWS Iot Site Wise Cloud DataLab N/A BI Power BI QuickSight Cloud Datastudio N/A Security portal Azure Defender for IoT AWS IoT Device Defender N/A N/A Visual IoT configuration Azure Portal AWS IoT Things Graph N/A N/A SaaS solution Azure IoT Central N/A N/A N/A Digital Twins Azure Digital Twins Simulation Digital Twins Platform Google Cloud IoT

A parte de estos fabricantes existen otros como: • Cisco
• General Electrics • Samsung SmartThings • SiteWhere • Webinos • FIWARE • Braincube • Hitachi • Siemens • Torizon • Kaaiot • ThingsBoards • Y muchos otros más … Bien es cierto, que muchos de los anteriores fabricantes solamente tienen piezas y no todo el ecosistema como pueden ser los otros cuatro grandes servicios cloud; de la anterior lista Cisco e Hitachi podrían compararse en la tabla anterior. Comparaciones Tablas y listados(2/4)

En el área open source: • Openremote • Zetta.js •
Node-RED • M2MLabs Mainspring • DSA • Thinger • SiteWhere • ThinSpeak • Y seguro que muchas mas que yo desconozca. Pero la que realmente es importante conocer y por eso la destaco es: Apache IoTDB. Comparaciones Tablas y listados(3/4)

Y en el área de Digital Twins, que lo separo
por qué algunos fabricantes tienen cosas realmente espectaculares serian: • Software AG • Autodesk Digital Twins • Realidad mixta con Azure Digital Twins y Unity • XMPRO • Y muchos más. Os pongo un par de imágenes para que veáis el potencial de los gemelos digitales con las anteriores herramientas, algo que ya se escapa completamente del curso y te propongo por ejemplo hacerte una cuenta en XMPRO para probarlo: Comparaciones Tablas y listados(4/4)

Conclusión: un libro vivo No estoy contento con la sección
de IA + IoT en Azure pero cuando esté terminado el proyecto que he introducido en el libro en una próxima versión, me sentiré más contento. He preferido publicar esta versión que aporta todos los conocimientos necesarios para acometer un proyecto sin ninguna laguna y también os he dado enlaces, puntos de inicio en aquellas partes que no están todo lo desarrolladas que yo quería. Para terminar, solamente me queda agradecer todos los comentarios que crean oportunos, pueden contactar conmigo en las redes sociales y en el canal de Discord que estoy preparando, disculpar si cuando lea esto aun no esta 100% operativo, el tiempo es finito. Febrero de 2022

¡Gracias! Puedes encontrarme buscando por jmfloreszazo en https://jmfloreszazo.com

Manos a la obra con: IoT con Azure

Manos a la obra con: IoT con Azure

More Decks by Jose María Flores Zazo

Other Decks in Technology

Featured

Transcript