Manos a la obra con: IoT con Azure

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Í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.

View Slide

Í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, ...

View Slide

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

View Slide

Sección 1
Introducción

View Slide

¿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

View Slide

¿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.

View Slide

¿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.

View Slide

¿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.

View Slide

¿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.

View Slide

¿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.

View Slide

¿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,
…

View Slide

¿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

View Slide

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.

View Slide

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).

View Slide

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.

View Slide

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!

View Slide

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

View Slide

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.

View Slide

Adopción por países:
Adopción por tipo de sector:
Source: IoT Signals Report | Microsoft Azure. October 2021.
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%

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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), …

View Slide

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.

View Slide

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

View Slide

¿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

View Slide

¿Qué es…?
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.

View Slide

¿Qué es…?
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.

View Slide

¿Qué es…?
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.

View Slide

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

View Slide

IoT vs M2M vs SCADA
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.

View Slide

IoT vs M2M vs SCADA
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.

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Sección 2
Python para C# devs

View Slide

¿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/

View Slide

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

View Slide

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

View Slide

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

View Slide

IDE
Creamos el programa Hello World! y lo ejecutamos, para comprobar su correcto funcionamiento:

View Slide

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

View Slide

De C# a Python
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.

View Slide

De C# a Python
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.

View Slide

De C# a Python
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:

View Slide

De C# a Python
Objetos anónimos – Comparación C# vs Python

View Slide

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

View Slide

De C# a Python
LINQ – Comparación C# vs Python

View Slide

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/

View Slide

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

View Slide

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)

View Slide

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

View Slide

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.

View Slide

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

View Slide

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

View Slide

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

View Slide

Ejemplo
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

View Slide

Ejemplo
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.

View Slide

Sección 3
Prueba de Concepto

View Slide

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.

View Slide

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.

View Slide

Raspberry Pi + Python + IDE
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

View Slide

Raspberry Pi + Python + IDE
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.

View Slide

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]

View Slide

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

View Slide

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

View Slide

Caso de uso
¿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.

View Slide

Caso de uso
Reciclado organico
Ciudadano responsable Restos de carne

View Slide

Caso de uso
¿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,
• 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).
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.

View Slide

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

View Slide

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

View Slide

Caso de uso
¿Qué a ocurrido?
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.
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.

View Slide

Caso de uso
Reciclado organico
Ciudadano responsable Restos de carne

View Slide

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.

View Slide

Caso de uso
¿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.
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.

View Slide

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.

View Slide

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

View Slide

¿Qué a ocurrido?
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,
¿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.

View Slide

¿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.
Ganadería Factoria Logística Retail
Trazabilidad del ciclo de vida de la ternera

View Slide

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.

View Slide

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.

View Slide

Sección 4
IoT con Azure

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

• ¿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.

View Slide

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

View Slide

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:

View Slide

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.

View Slide

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:

View Slide

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á.

View Slide


View Slide

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.

View Slide

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:

View Slide

Routes
Aunque lo veremos más adelante, las rutas sirven para la comunicación de los modulos de un dispositivo IoT
Edge.

View Slide

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

View Slide

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.

View Slide

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

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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

View Slide

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

View Slide

Device Twin
Identidad
(solo lectura)
Etiquetas
(metadatos)
Propiedades
Deseadas
Reportadas

View Slide

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

View Slide

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

View Slide

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

View Slide

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 WHERE INTO
Podríamos traducirlo como: DE CUANDO EN , es decir, cuando se cumpla una condición de
un origen llévalo a un destino.

View Slide

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.

View Slide

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. $. $messageId, por ejemplo. Definidos out-the-box por el fabricante, en este
caso por IoT Edge.
• App properties. . messageStatus, por ejemplo. Son valores que se añaden via codigo y
personalizados para Edge.
• Body properties. $body. $body.TemperatureValue, por ejemplo. Son mensajes
personalizados por el Edge, son del payload.

View Slide

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:

View Slide

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.

View Slide

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

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Ejemplo
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.

View Slide

Ejemplo
• 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.

View Slide

Ejemplo
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

View Slide

Ejemplo
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

View Slide

Ejemplo
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

View Slide

Ejemplo
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.

View Slide

Ejemplo
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).

View Slide

Ejemplo
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.

View Slide

Ejemplo
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

View Slide

Ejemplo
Si todo fue bien, entra en el Dashboard de Docker:

View Slide

Ejemplo
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

View Slide

Ejemplo
$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

View Slide

Ejemplo
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
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.

View Slide

Ejemplo
Tabla de la estructura del JSON
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.

View Slide

Ejemplo
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:

View Slide

Ejemplo
• 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:

View Slide

Ejemplo
• 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.

View Slide

Ejemplo
• 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.

View Slide

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

View Slide

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

View Slide

Ejemplo
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.

View Slide

Ejemplo
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.

View Slide

Ejemplo
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

View Slide

Ejemplo
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.

View Slide

Ejemplo
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

View Slide

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

View Slide

Ejemplo
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)

View Slide

Ejemplo
Mientras que por CLI:
Intenta en la medida de lo posible abstraerte en UI, en un futuro me lo agradecerás.

View Slide

Ejemplo
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.

View Slide

Ejemplo
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:

View Slide

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

View Slide

Ejemplo
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:

View Slide

Ejemplo
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:

View Slide

Ejemplo
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.

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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.
Devices & Twins
Analisis
Provisioning

View Slide

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

View Slide

Ejemplo paso a paso
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

View Slide

Ejemplo paso a paso
Desde el recurso, pulsar sobre la url:
Llegaremos a este portal:

View Slide

Ejemplo paso a paso
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

View Slide

Ejemplo paso a paso
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

View Slide

Ejemplo paso a paso
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

View Slide

Ejemplo paso a paso
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, …

View Slide

Ejemplo paso a paso
¿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

View Slide

Ejemplo paso a paso
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:

View Slide

Ejemplo paso a paso
Las graficas de los valores enviados:

View Slide

Ejemplo paso a paso
La ejecución de comandos y la vista de datos en bruto:

View Slide

Ejemplo paso a paso
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.

View Slide

Ejemplo paso a paso
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.

View Slide

Ejemplo paso a paso
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

View Slide

Ejemplo paso a paso
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.

View Slide

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.

View Slide

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

View Slide

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

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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.

View Slide

• 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

View Slide

• 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:

View Slide

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.

View Slide

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

View Slide

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

View Slide

¿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.

View Slide

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.

View Slide

Ejemplo paso a paso
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

View Slide

Ejemplo paso a paso
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:

View Slide

Ejemplo paso a paso
Ejecutamos el proyecto CreateDTScenario, genera:

View Slide

Ejemplo paso a paso
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

View Slide

Ejemplo paso a paso
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:

View Slide

Ejemplo paso a paso
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

View Slide

Ejemplo paso a paso
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}"

View Slide

Ejemplo paso a paso
Despliega de AdtBackend la Function que hemos creado antes:

View Slide

Ejemplo paso a paso
Conectamos un evento en IoT Hub:

View Slide

Ejemplo paso a paso
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.

View Slide

Ejemplo paso a paso
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.

View Slide

Ejemplo paso a paso
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.

View Slide

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

View Slide

Ejemplo paso a paso
Creamos un Azure IoT Central:

View Slide

Ejemplo paso a paso
Creamos un Service Bus y una cola:

View Slide

Ejemplo paso a paso
Establecemos una shared access policies al service bus:

View Slide

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

View Slide

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

View Slide

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

View Slide

Ejemplo paso a paso
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
}
]
}

View Slide

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

View Slide

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.

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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:

View Slide

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

View Slide

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.

View Slide

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

View Slide

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

View Slide

Sección 5
Seguridad

View Slide

¿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

View Slide

¿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.

View Slide

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

View Slide

Metodología
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.

View Slide

Metodología
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

View Slide

Metodología
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:

View Slide

Metodología
- 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.

View Slide

Metodología
- 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.

View Slide

Metodología
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.

View Slide

Metodología
- 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.

View Slide

Metodología
• 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

View Slide

Metodología
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).

View Slide

Metodología
• 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:

View Slide

Metodología
- 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.

View Slide

Metodología
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.

View Slide

Metodología
- 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).

View Slide

Metodología
• 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.

View Slide

Metodología
• 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.

View Slide

Metodología
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.

View Slide

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

View Slide

Resumen
• 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

View Slide

Resumen
• 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…

View Slide

Resumen
• 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…

View Slide

Resumen
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

View Slide

Resumen
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.

View Slide

Resumen
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.

View Slide

Resumen
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

View Slide

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.
csharpSASSecurity – Symmectic Key Security

View Slide

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.

View Slide

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.

View Slide

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:

View Slide

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.
csharpX509SecurityAndDPS – Certificados y distribución

View Slide

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

View Slide

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

View Slide

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.

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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.

View Slide

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

View Slide

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": {}
}
}

View Slide

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

View Slide

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

View Slide

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.

View Slide

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:

View Slide

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

View Slide

21. Ejecutamos en PowerShell: New-CACertsVerificationCert “<>"
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)

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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

View Slide

Ejemplo
• 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

View Slide

Ejemplo
• Y enviamos la información al Log Analytics workspace:
• Y repites la operación con el DPS.

View Slide

Ejemplo
• 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:

View Slide

Ejemplo
• Podemos entrar en las opciones para que veas que va saliendo:

View Slide

Ejemplo
• Desde la siguiente opción security alerts:

View Slide

Ejemplo
• 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.

View Slide

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

View Slide

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.

View Slide

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í…

View Slide

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

View Slide

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)

View Slide

Sección 6
Análisis de datos

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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

View Slide

¿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

View Slide

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

View Slide

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
Servicio
Almacenamiento
Internet

View Slide

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

View Slide

¿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

View Slide

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)

View Slide

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)

View Slide

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

View Slide

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

View Slide

Resumen
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

View Slide

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

View Slide

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

View Slide

¿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

View Slide

• 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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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
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.

View Slide

Resumen
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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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.

View Slide

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:

View Slide

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.

View Slide

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
Un vistazo a…
Routing(3/16)

View Slide

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)

View Slide

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)

View Slide

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)

View Slide

Un vistazo a…
Routing(7/16)

View Slide

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)

View Slide

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)

View Slide

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

View Slide

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

View Slide

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)

View Slide

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)

View Slide

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)

View Slide

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)

View Slide

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

View Slide

¡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.

View Slide

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).

View Slide

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.

View Slide

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.

View Slide

Un vistazo a…
ASA(4/9)

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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á:

View Slide

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.

View Slide

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

View Slide

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.

View Slide

Un vistazo a…

View Slide

Un vistazo a…
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.

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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:

View Slide

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:

View Slide

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

View Slide

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

View Slide

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

View Slide

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.

View Slide

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

View Slide

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:

View Slide

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.

View Slide

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

View Slide

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…

View Slide

Sección 7
Avanzado

View Slide

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

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

Si usamos las Metricas, por ejemplo:

View Slide

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

View Slide

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.

View Slide


View Slide

Un ejemplo de KQL:

View Slide


View Slide

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.

View Slide

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.

View Slide

https://github.com/Azure-Samples/iot-hub-dotnet-autoscale
IoTHubScaleInit • TimeTrigger
IoTHubScaleOrchestator • Orquestador
IoTHubScaleWorker • Worker

View Slide

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.

View Slide

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

View Slide

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:

View Slide

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

View Slide

¿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

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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

View Slide

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.

View Slide

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

View Slide

Otro enfoque
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.

View Slide

Otro enfoque
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/

View Slide

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

View Slide

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

View Slide

¿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

View Slide

¿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.

View Slide

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

View Slide

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

View Slide

Sección 8
Otras opciones

View Slide

¿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

View Slide

¿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.

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Manos a la obra con: IoT con Azure

Manos a la obra con: IoT con Azure

Jose María Flores Zazo

More Decks by Jose María Flores Zazo

Other Decks in Technology

Featured

Transcript