Save 37% off PRO during our Black Friday Sale! »

Manos a la obra con: IoT con Azure

Manos a la obra con: IoT con Azure

Recopilación de los artículos, ejemplos y documentos publicados en este blog y que son de ayuda a la comunidad:

Sección 1: historia, actualidad, conceptos, teoría, …
Sección 2: Python para C# devs (en proceso de creación)
Sección 3: prueba de concepto, proyecto y hardware
Sección 4: IoT Hub, IoT Edge, IoT Central + Rest API, Digital Twins, … [Version 0.0.4 actualizada con un ejemplo de Digital Twins e IoT Central]
Sección 5: seguridad, protección, certificados, Azure IoT + Azure Defender for IoT, …
Sección 6: analisis de datos, procesos ETL & ELT, streams, Power BI, TSDB, …
Sección 7: avanzado, Azure IoT Plug & Play, Gateway, protocolos, IA 2.0, Blockchain, …
Sección 8: otras opciones más allá de Azure, Apache, AWS, IBM, …

La Sección 7 irá en constante crecimiento con artículos en el blog, que posteriormente se recopilaran en el PDF con la intención de crear un libro lo más completo posible y que sirva de manual para todas aquellas personas que quieran adentrarse en este mundillo.

https://jmfloreszazo.com/azure-iot-esp/

5087adcbce3dd0ff6155daa8f0948a95?s=128

Jose María Flores Zazo

November 02, 2021
Tweet

Transcript

  1. Manos a la obra con: IoT en Azure Ver. 0.0.5

  2. Bienvenidos Acerca de… ¡Hola! Gracias por entrar en “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
  3. Apúntate a la comunidad https://jmfloreszazo.com/azure-iot-esp/

  4. Índice Resumen Sección 1 Introducción Historia, actualidad, conceptos, teoría, arquitecturas,

    … Sección 2 Python Para C# Devs
  5. Í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.
  6. Índice Resumen del curso Sección 7 Avanzado Desplegar soluciones, IoT

    Plug & Play, Gateways, protocolos de comunicaciones, diagnostico remoto, IA 2.0, Blockchain, … Sección 8 Otras opciones Apache, AWS, IBM, procesador ESP32, ... Sección 6 Análisis de datos Proceso ETL o ELT complejo, desde Streams hasta Power BI, TSDB, ...
  7. 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
  8. Sección 1 Introducción

  9. ¿Qué es IoT? Introducción(1/8) Hoy es 03/02/2023 me despierto a

    las 5.30 horas, como siempre. Sin los sobresaltos y las estridencias del despertador, lo hago con una luz de amanecer suabe, me siento descasando, ya puedo oler mi café favorito prepararse en la cafetera, recibo el parte del tiempo y el estado de la carretera mientras desayuno. Antes de coger el coche paro a observar el cielo e impregnarme del frescor de la mañana, percibo que este será un buen día. Llego al trabajo sin prácticamente atascos, aparco el coche en un aparcamiento gratuito no muy alejado de la oficina, me he evitado dar decenas de vueltas por la zona, paso por mi cafetería de siempre, automáticamente una app de mi teléfono me propone mi café con avena templado y le digo que sí, recojo el café y subo a la oficina… Y en el ascensor te acuerdas de aquel 03/02/2018, día en el cambió todo: tu estilo de vida, tu salud, como te frustraban aquellos atascos e incluso el tiempo que tardabas en aparcarás tu vehículo. Han pasado 5 años y todo el mundo en el que vives es diferente: energía, salud, agricultura, fabricación, logística, transporte, medio ambiente, seguridad, compras e incluso tu ropa. Este es el impacto de conectar objetos cotidianos a internet, o internet de las cosas (Internet of Things) o IoT de ahora en adelante. Es cierto que aun nos queda un poco para llegar a ese 2023 y la utopía que hablo puede que aun este un poquito más lejos, pero no más de 5 años. Quizá la pandemia ya te está evitando perder horas en un atasco, o que algunas cosas cambien un poco a la historia que voy a contar. Pero nuestro presente es que cada día que pasa más y más dispositivos mejoran nuestro bienestar. Por tanto, continuemos con nuestra historia. ¿Qué tal si os cuento una historia? – Usemos el storytelling
  10. ¿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 curl https://packages.microsoft.com/config/debian/stretch/multiarch/prod.list > ./microsoft-prod.list que los envió a un servicio en la nube donde podrás consultar informes y telemetría en mi teléfono movil. 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 ningun 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 via 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.
  11. ¿Qué es IoT? Introducción(3/8) Ya 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 algun 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 via 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 arboles, 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, esta 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 esta bloqueada por un accidente. Conduzco hasta mi puesto de trabajo con un trafico relativamente fluido y por desgracia hoy me toca aparcar alejado de la oficina, tampoco es un drama, esta 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é tipico 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.
  12. ¿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 esta 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, a parte de bajar el nivel de iluminación en consonancia con el nivel de luz exterior. Tambien me da por pensar en como 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 movil, a 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é tubo que cancelar la reunión, y por qué hemos ido a comer más tarde de lo habitual, afortunadamente desde su aplicación movil, 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. Tambien 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 numero del seguro y localizando a la grúa.
  13. ¿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 lo 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 imporante de la planta de producción, que esta 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 fabrica, mi tarjeta a 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.
  14. ¿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 esta muy bien definida y mañana no tendré que trabajar. Gracias a toda la información que se a intercambiado en los procesos, automáticamente se han cancelado las reuniones de mañana y tendré el día libre para compensar las horas. Tambien 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 esta 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 movil. La temperatura de la zona de las basuras es un poco alta, la calefacción esta 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 limite y la basura no la han tirado (los cubos tienen una bascula) 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 camara que detecta el desperdicio: una botella vacía de pastico, restos de un plato de macarrones, etc. Me indica donde debo tirar el desperdicio.
  15. ¿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 si: ¡Hasta mañana! Indirectamente ayudaremos a personas con dicacidad visual, nuestros mayores, …
  16. ¿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
  17. 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.
  18. Evolución y previsión Historia(2/4) Año Dispositivo Enlace 1973 Mario W.

    Cardullo, primera patente de RFID. 1982 Carnegie Mellon máquina expendedora de refrescos. 1989 Tostadora conectada a Interops’89. 1990 HP introduce HP LaserJet IIISi. La primera impresora conectada a una red. 1993 A alguien en la universidad e Cambridge se le ocurre conectar una cafetera a internet. 1996 Generals Motors OnStart: primer instrumento IoT en un coche y continua en el mercado. 1998 Se forma el Bluetooth SIG (Special Internet Group), ya os podéis imaginar el gran hito. 1999 A la gente de LG se le ocurre conectar un frigorífico: LG Internet Digital DIOS. 2000 Otra vez HP lleva la punta de lanza: Cooltown, un concepto de computación omnipresente. 2001 Primer producto con Bluetooth: podría decirse que KDDI es el primer teléfono con bluetooth. 2005 ITU Reports, hacen futurología del IoT, y dan en el clavo de muchas cosas. 2008 La IPSO Alliance primera alianza centrada en IoT. Ahora llamdada 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).
  19. Evolución y previsión Historia(3/4) Año Dispositivo Enlace 2014 SigFox construye

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

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

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

    Signals Report | Microsoft Azure. October 2021. Impacto, revolución y coherencia Potencial(3/3) Global US UK FR DE SP IT BNLX CH JP AUS % de adopción IoT 90% 94% 91% 91% 88% 89% 95% 91% 85% 88% 96% % proyectos en fase productiva 25% 27% 25% 23% 25% 22% 26% 25% 25% 23% 18% Tiempo de uso (meses) 12 11 13 12 14 11 10 12 16 12 16 Planeado usar IoT en más de 2 años 66% 78% 69% 67% 53% 76% 69% 59% 65% 51% 56% Global Industria Energía Movilidad Smart Places % de adopción IoT 90% 91% 85% 91% 94% % proyectos en fase productiva 25% 26% 22% 23% 24% Tiempo de uso (meses) 12 13 15 14 13 Planeado usar IoT en más de 2 años 66% 68% 61% 61% 69%
  24. 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
  25. 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.
  26. 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.
  27. 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.
  28. 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
  29. 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 gardgets de andar por casa, no se acercan a los estándares necesarios en la medicina.
  30. 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.
  31. 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.
  32. 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.
  33. 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.
  34. 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.
  35. 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.
  36. 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), …
  37. 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.
  38. 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
  39. ¿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
  40. ¿Qué es…? Definiciones en profundidad(2/4) Edge Computing Computación en el

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

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

    cualquier palabra que veas iniciada con Smart (inteligente), como Smart City (ciudad inteligente, que hemos visto como sector) o Smart Movility (movilidad inteligente). Es prácticamente sinónimo de IoT aplicado a: la ciudad, la movilidad, coches, etc.: • Smart City, ciudad inteligente. • Smart Movility, movilidad inteligente. • Smart Places, lugares inteligentes. • Smart Cars, coches inteligentes. • Smart Automation, automatizaciones inteligentes. • Smart Home, hogar inteligente. • Smart Retail, ventas minoristas inteligentes (la verdad es que suena mal, en ingles ya parece otra cosa). • Smart working, trabajo inteligente. • Smart Energy, energía inteligente. • Smart Care, cuidados inteligentes. Y así podríamos continuar, muchas de ellas ya se usan como estandar de facto y otros comienzan a escucharse.
  43. 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
  44. IoT vs M2M vs SCADA Comparación de tecnologias(2/3) IoT Los

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

    observar si no fuese por: • Al mover datos los sensores a Internet , via Edge o dispositivos inteligentes, • El mundo que hemos heredado de lo servicios en la nube cuando se pueden aplicar en los dispositivos como estos. • Mejoras en las baterías. • Mejoras en los sistemas de comunicación. • La inclusión del aprendizaje automático. • Etc. Aun estaríamos en el M2M. Es decir, que toda la anterior tecnología heredada de otros ámbitos ha propiciado la evolución del M2M al IoT.
  46. 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
  47. 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
  48. 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
  49. Un modelo básico Estructura de una solución IoT

  50. 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
  51. Sección 2 Python para C# devs

  52. ¿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/
  53. 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
  54. IDE Elementos necesarios (1/3) Instalar Python V3: https://www.python.org/downloads/ Configurar VS

    Code – Vamos a preparar nuestro entorno
  55. IDE Elementos necesarios (2/3) Instalar la extensión de Python para

    VS Code: https://marketplace.visualstudio.com/items?itemName=ms-python.python
  56. IDE Elementos necesarios (3/3) Creamos el programa Hello World! y

    lo ejecutamos, para comprobar su correcto funcionamiento:
  57. De C# a Python Breve traspaso de conocimiento (1/8) Suites

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

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

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

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

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

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

    – Comparación C# vs Python
  64. 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/
  65. 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
  66. 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)
  67. 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
  68. 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.
  69. 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
  70. 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
  71. Ejemplo Llamada a un API(1/3) En este ejemplo vamos a

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

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

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

  75. 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.
  76. 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.
  77. Raspberry Pi + Python + IDE Elementos necesarios (1/2) 1.

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

    Instalamos Enviro + desde GitHub: curl -sSL https://get.pimoroni.com/enviroplus | bash, sigue las instrucciones. 9. Probamos un ejemplo: 10. Ahora vamos con la cámara siguiendo las instrucciones. Y ejecuta una captura de imagen, revisa que este correcta. 11. Le toca el turno a VS Code. Y revisamos el fichero combined.py en VS Code, si ves datos en el LCD, ya tienes todo correctamente instalado en tu Raspberry. Si has podido llegar sin problemas al podido ejecutar el punto 10 y 11 sin problemas, ya estas listo para continuar.
  79. 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]
  80. 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
  81. 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
  82. Caso de uso Arquitectura IoT Estandar (2/5) ¿Qué a ocurrido?

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

    responsable Restos de carne
  84. Caso de uso Arquitectura IoT Estandar (4/5) ¿Qué a ocurrido?

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

    rasgos el funcionamiento: Con Edge – Un modelo más actual y que necesita un hardware más potente y caro Reciclado de vidrio Ciudadano responsable Botella de vidrio
  87. Caso de uso Arquitectura IoT Edge (2/5) ¿Qué a ocurrido?

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

    responsable Restos de carne
  89. 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.
  90. Caso de uso Arquitectura IoT Edge (4/5) ¿Qué a ocurrido?

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

    modo: Trazabilidad – Salvando las distancias y via códigos de barra Reciclado de vidrio Ciudadano responsable Botella de vidrio
  93. ¿Qué a ocurrido? • Una persona responsable con el medioambiente

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

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

  97. 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
  98. 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
  99. 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
  100. Teoría y conceptos principales Azure IoT Hub (2/37) Es un

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

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

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

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

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

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

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

  108. Teoría y conceptos principales Azure IoT Hub (10/37) La acción

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Identidad (solo lectura) Etiquetas (metadatos) Propiedades Deseadas Reportadas
  124. Teoría y conceptos principales Azure IoT Hub (26/37) El concepto

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

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

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

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

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

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

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

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

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

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

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

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

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

    Edge Security Daemon sudo apt-get update sudo apt-get install iotedge Paso 4 Configurar el Daemon. Pero antes debes crear un dispositivo IoT Edge en Azure llamado raspberrypi4 sudo nano /etc/iotedge/config.yaml
  139. Preparando nuestro … Entorno (4/5) Pegas la cadena de conexión

    copiada desde Azure IoT Edge sudo systemctl restart iotedge Paso 5 Comprobar que efectivamente esta enlazado el dispositivo físico con IoT Edge
  140. Preparando nuestro … Entorno (5/5) .Net Core 3.1 – Montado

    en tu Rapsberry Pi A continuación, vamos a seguir estos pasos para poder instalar .Net Core 3.1 en tu Rapsberry Pi y así poder ejecutar un módulo desarrollado en C#. Descargar el paquete de: https://dotnet.microsoft.com/download/dotnet/3.1 Ejecutar desde la carpeta donde descargaste el tar: sudo mkdir -p $HOME/dotnet sudo tar zxf dotnet-sdk-3.1.415-linux-arm.tar.gz -C $HOME/dotnet export DOTNET_ROOT=$HOME/dotnet export PATH=$PATH:$HOME/dotnet Probar: Dotnet run
  141. Ejemplo Hello IoT Edge(1/20) Vamos a probar directamente un ejemplo

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

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

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

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

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

    el Main: Es responsable de invocar el método asíncrono Init(), registrar el evento de cancelación y esperar a es evento. Acción: Desarrollar – 1/3
  147. Ejemplo Hello IoT Edge(7/20) ModuleClient es la API principal y

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

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

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

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

    el Dashboard de Docker:
  152. Ejemplo Hello IoT Edge(12/20) Por último, queremos implementar el codigo

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

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

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

    Nombre de la propiedad Descripción type Siempre debe “docker . status Para los modulos de sistema (Hub y Agent), siempre debe estar en “running . Para los modulos personalizados, puede ser: • stopped. Después de desplegar, el modulo puede estar idle durante un tiempo. • running. Opcion 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.
  156. Ejemplo Hello IoT Edge(16/20) Si entras a ver el fichero

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

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

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

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

    en ACR. • Y desplegamos contra el IoT Device de VS Code, recuerda: Create Deployment for a Single Device
  161. 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
  162. Ejemplo Depuración en IoT Edge(2/6) Es la primera herramienta que

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

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

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

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

    otras herramientas, pero es una opción que puede ayudarte. De todas formas, vamos a la forma más sencilla y que seguramente uséis. Una vez ejecutada la acción, podrás ver en el terminal que se pone a realizar muchos pasos. Cuando termine solamente debes usar: VS Code Debugging – La forma más sencilla de depurar
  167. Ejemplo Hello IoT Device(1/5) Si has asimilado todo lo anterior

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

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

    la medida de lo posible abstraerte en UI, en un futuro me lo agradecerás.
  170. Ejemplo Hello IoT Device(4/5) Establecer la linea de comando y

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

    vamos a ejecutar la siguiente acción en el CLI: az iot device c2d-message send -d {device_id} -n {iothub_name} --data ‘Testing C2D’ O bien desde: Podéis observar que se esta escribiendo el mensaje:
  172. Ejemplo Enviro + IoT Device(1/4) Vamos a generar la correspondiente

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

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

    este suscrito a la telemetría, con Python. Para ello primero vamos a obtener la cadena de conexión del Event Hub:
  175. Ejemplo Enviro + IoT Device(4/4) Cargar pyEnviroPlusIoTDevice y bakend, lo

    ejecutas. Para backend debes modificar la cadena de conexión que se encuentra en local.settings.json, cuidado no pongas en la cadena de conexión la parte de EntityPath ya que es la misma que debes poner en el eventHubName. Ejecuta la Function y podrás observar como esta recogiendo la telemetría, con esto acabo de mostraros un backend de IoT Hub.
  176. Ejemplo Twins(1/5) Este ejemplo con Python y C# vamos a

    ver como funciona un gemelo. Para ello vamos a trabajar desde el UI del portal de Azure y con código. Como ya comenté antes, ya realizo el trabajo indistintamente con Az CLI o el UI, la cuestión es entender los conceptos. Lanza VS Code y comencemos. pyTwinIoTHub – Vamos a ver en la práctica que es un gemelo https://github.com/jmfloreszazo/HandsOnIoTAzure
  177. 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.
  178. 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 reported. 3. Posteriormente podremos llevar un registro de dispositivos a través de las consultas.
  179. 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
  180. 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.
  181. Teoría y conceptos principales Azure IoT Central(1/3) Azure IoT Central

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

    como Azure Time Series Insights (TSI) lo veremos en secciones futuras y se tratará en profundidad. Teoría y conceptos principales Azure IoT Central(2/3) Devices & Twins Analisis Provisioning
  183. A grandes rasgos las fases de Azure IoT Central son:

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

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

    pulsar sobre la url: Llegaremos a este portal:
  186. Ejemplo paso a paso Azure IoT Central(3/14) Creamos un template

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

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

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

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

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

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

    los valores enviados:
  193. Ejemplo paso a paso Azure IoT Central(10/14) La ejecución de

    comandos y la vista de datos en bruto:
  194. Ejemplo paso a paso Azure IoT Central(11/14) Y solo te

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

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

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

    un token en IoT Central: Establece un nombre que quieras y añade el rol de “App Operator”. Cambia los valores correspondientes en la restUriGet y ejecuta el ejemplo. https://github.com/jmfloreszazo/HandsOnIoTAzure
  198. Teoría y conceptos principales Azure IoT Solution Accelerator(1/) Azure IoT

    Solution Accelerator En vez de hacerlo todo tu mismo, como en el ejemplo anterior, puedes partir de una plantilla predefinida. Estas plantillas genéricas las podrás adaptar según tus requisitos. Si quieres más información sobre las plantillas, sigue el enlace.
  199. 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
  200. 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
  201. Teoría y conceptos principales Azure Digital Twins(1/11) Azure Digital Twins

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

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

    sobre el enfoque de Grieves para tener un gemelo digital (espejo) de un gemelo físico a través del flujo de datos, desde el producto físico a la instancia digital, y luego como esta información se intercambia y se envia de regreso al dispositivo físico. El gemelo digital es la construcción de la información del gemelo físico. La intención del gemelo digital es que pueda proporcionar la misma o mejor información que la que podría obtenerse estando en posesión física del gemelo físico. El supuesto clave es que el tipo, la granularidad, y cantidad de información contenida en el gemelo digital es impulsada por los casos de uso. Traducción libre de Virtually Intelligent Product Systems: Digital and Physical Twins. De Michael Grieves. Existen 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.
  204. Teoría y conceptos principales Azure Digital Twins(4/11) MSM proporciona información

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

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

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

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

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

    gemelo digital. Estado: operaciones físico Gemelo físico Proceso físico Entorno físico Sincronización Datos Entorno Virtual Estado: información digital Proceso virtual Gemelo Digital
  210. Teoría y conceptos principales Azure Digital Twins(10/11) ¿Por qué un

    gemelo digital? Los sistemas digitales transformar las empresas al acelerar la comprensión holística: optima toma de decisiones y acciones eficaces. Se reduce la complejidad para mejorar la comprensión. Objetivo inicial. Pero además la sincronización entre entidades físicas y virtuales, proporcionan más información a problemas específicos con una mayor perspectiva mayor, nos proporciona conciencia. Un mayor conocimiento del comportamiento simulado y el tiempo real, 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.
  211. Teoría y conceptos principales Azure Digital Twins(11/11) Por extensión los

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

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

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

    CreateDTScenario, genera:
  215. Ejemplo paso a paso Azure Digital Twins(4/12) Que esta basado

    en: Modeling and Control of Wind Turbine Wind Farm 1 Wind Turbine 1 Tower 1 Rotor 1 Nacelle 1 Gear 1 Generator 1 Wind Turbine 2 Wind Turbine 3
  216. Ejemplo paso a paso Azure Digital Twins(5/12) Pasa un tiempo

    probando los menú y acciones del diseñador visual para que te familiarices, por ejemplo, añadiendo relaciones a mano o lanzando consultas:
  217. Ejemplo paso a paso Azure Digital Twins(6/12) Arquitectura de la

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

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

    la Function que hemos creado antes:
  220. Ejemplo paso a paso Azure Digital Twins(9/12) Conectamos un evento

    en IoT Hub:
  221. Ejemplo paso a paso Azure Digital Twins(10/12) Conectamos: 1. az

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

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

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

    Creamos un Azure IoT Central:
  226. Ejemplo paso a paso Azure Digital Twins e IoT Central(3/9)

    Creamos un Service Bus y una cola:
  227. Ejemplo paso a paso Azure Digital Twins e IoT Central(4/9)

    Establecemos una shared access policies al service bus:
  228. Ejemplo paso a paso Azure Digital Twins e IoT Central(5/9)

    Volvemos a IoT Central para añadir una nueva Data Export:
  229. Ejemplo paso a paso Azure Digital Twins e IoT Central(5/9)

    Observamos en Azure Service Bus que los datos empiezan a llegar:
  230. Ejemplo paso a paso Azure Digital Twins e IoT Central(6/9)

    Creamos un Azure Data Twins que pueda procesar esa información:
  231. Ejemplo paso a paso Azure Digital Twins e IoT Central(7/9)

    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 } ] }
  232. Ejemplo paso a paso Azure Digital Twins e IoT Central(8/9)

    Ejecutamos la Function en local llamada sendTemeletryIoTCentral2DT: Recuerda que debes hacer login desde el CMD con Az Login. Y establecer la suscripción.
  233. Ejemplo paso a paso Azure Digital Twins e IoT Central(9/9)

    Observa como el valor de la telemetría está cambiando en el gemelo digital:
  234. Un sistema operativo 100% Windows Windows IoT Core 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
  235. Sistema operativo en tiempo real de Azure Azure 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:
  236. 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
  237. 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.
  238. 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
  239. Ya tienes las bases de IoT Hub, IoT Central y

    Digital Twins. Ahora te toca interiorizarlas para entrar de lleno en la PoC. Pero esto será cuando termine todas las secciones del libro ya que se puede entender como un objetivo secundario. Como decía la PoC quedará en stand-by. Prefiero que tengas todo el conocimiento para afrontar el proyecto con una base muy sólida. PoC…
  240. Sección 5 Seguridad

  241. Continuará… Os recomiendo prestar atentación al blog o a mi

    cuenta de Twitter o en la comunidad para ver actualizaciones sobre este documento.
  242. ¡Gracias! Puedes encontrarme buscando por jmfloreszazo en https://jmfloreszazo.com