Capítulo 4. El ciclo de vida del dispositivo

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

En ya te has adentrado en el intrincado mundo de las soluciones IoT, donde el hardware, el software y la nube se unen en una sinfonía de tecnología. Tu elección de dispositivos o sus combinaciones depende de las necesidades específicas que pretendas abordar. En el capítulo anterior, nos adentramos en el concepto de "probar antes de comprar", explorando vías para determinar la mejor opción para tu dispositivo. Sin embargo, es fundamental comprender que adquirir un dispositivo y ponerlo en marcha no es más que la punta del iceberg: ¡ojalá fuera tan sencillo! Las soluciones IoT abarcan mucho más de lo que parece a simple vista.

Establecer un paralelismo con los automóviles puede ayudar a ilustrar la cuestión. El objetivo principal de un coche es el transporte del punto A al B. Esto implica un motor, combustible, un mecanismo de dirección y asientos para los pasajeros. Estos aspectos son los requisitos funcionales básicos. Sin embargo, tú exiges de tu coche algo más que lo esencial: piensa en faros, cinturones de seguridad, climatizador y similares. Además, entra en juego el ámbito del mantenimiento, que requiere mecánicos cualificados, piezas de recambio, evaluaciones de seguridad y el cumplimiento de las normas reglamentarias. Todas estas facetas se abordan meticulosamente mucho antes de que un coche llegue al concesionario.

Aunque puede que tu empresa de IoT no alcance la complejidad de la fabricación de coches, es imprescindible reconocer que es necesario abordar los requisitos funcionales y no funcionales de tu dispositivo mucho antes de la implementación. Un enfoque sistemático para ello implica integrar estos requisitos en la gestión del ciclo de vida del dispositivo. Más allá de ayudar en la orquestación de las actividades del dispositivo, este marco sirve como recipiente para encapsular las necesidades funcionales y no funcionales. Las decisiones relativas a la gestión del dispositivo tras su implementación deben tomarse con mucha antelación, incluso antes de que el dispositivo emprenda su viaje inaugural.

Por eso, en este capítulo, pasarás por cada fase del ciclo de vida del dispositivo. Dentro de estas fases, señalaré los requisitos que merecen tu atención.

Gestión del ciclo de vida de los dispositivos

La gestión del ciclo de vida de los dispositivos abarca todas las tareas de la vida de un dispositivo relacionadas con su desarrollo, fabricación, mantenimiento y eventual retirada. En el contexto más amplio del Paisaje del IoT, tratado en el Capítulo 1, la gestión del ciclo de vida de los dispositivos forma parte del lado de la nube de Azure, como se muestra en la Figura 4-1.

Piensa que todo lo que entra en la gestión del ciclo de vida forma parte de un plan de control. Cuando tratas con uno o unas docenas de dispositivos, gestionarlos con un plan de control puede parecer exagerado, pero si tratas con miles o millones de dispositivos, un plan de control hace manejable lo aparentemente imposible. La gestión del ciclo de vida de los dispositivos es aplicable a todos ellos, tanto si están destinados a ser utilizados por un solo usuario como por una organización mundial. Los pasos son los mismos, aunque se realicen a escalas diferentes. Los pasos se representan en la Figura 4-2.

El ciclo de vida de un dispositivo se divide cronológicamente en partes superpuestas, marcadas por algunos acontecimientos significativos:

La fase de investigación y diseño comienza con una idea para un dispositivo, que luego se desarrolla hasta que se convierte en algo que se puede fabricar. Ya has leído bastante sobre esta parte en los dos últimos capítulos, pero también incluye considerar cómo vas a mantener tu dispositivo.
La fase de fabricación toma los planes realizados durante la fase de investigación y diseño y los pone en marcha para fabricar realmente el aparato.
- La reclamación de dispositivos se produce como parte de la fabricación y es un acontecimiento importante dentro del proceso de fabricación en el que se registra un dispositivo en una solución de gestión de dispositivos. En el caso de Azure, la solución es el Servicio de Aprovisionamiento de Dispositivos.
- El aparato se envía y se considera listo para su uso una vez finalizado el proceso de fabricación.
La fase de aprovisionamiento del dispositivo tiene lugar una vez que el dispositivo se envía y está listo para su implementación. La Implementación pone en línea ese dispositivo con una solución de gestión de dispositivos para que pueda comunicarse de forma segura con la nube.
La secuencia principal es cuando el dispositivo realiza su función principal mientras se comunica con la nube mediante mensajería, hermanamiento y recepción de actualizaciones de software. Los parches y actualizaciones de software se aplican periódicamente al dispositivo para que siga funcionando de forma óptima y segura.
La fase de desaprovisionamiento del dispositivo se produce cuando el dispositivo ya no es útil para el fin previsto. Entonces se retira del servicio y se elimina.

Seguridad es una preocupación transversal a todo el ciclo de vida del dispositivo, por eso aparece como un recuadro alrededor de todo lo demás en la Figura 4-2. Este libro tiene un capítulo entero(Capítulo 14) dedicado a la seguridad, porque es una preocupación transversal.

Repasemos cada fase con más detalle, empezando por la investigación y el diseño.

Investigación y diseño

Investigación y diseño (I+D) de dispositivos, en la mayoría de los casos, se centra en planificar cómo resolverá tu dispositivo un problema y decidir cómo lo hará. Hay un sinfín de cosas aparentemente dispares que debes tener en cuenta al diseñar tu dispositivo durante esta fase, como el hardware, los sistemas operativos y los SDK, entre otras cosas, que debes utilizar. Esta sección no cubrirá todo lo que tendrás que pensar para tu dispositivo durante su fase de I+D, pero te dará una idea de por dónde empezar.

Empecemos por las tres fases de la I+D.

Tres fases de I+D

Durante la fase de I+D, el dispositivo se desarrollará hasta que llegue a un estado en el que haya un plan claro para su viabilidad y fabricación final. A alto nivel, los pasos son la prueba de concepto, la creación de prototipos y, por último, un producto mínimo viable, como se ve en la Figura 4-3.

Prueba de concepto

Cuando prepara una prueba de concepto para un dispositivo, es poco más que una demostración técnica de la viabilidad de una idea para un dispositivo. Demuestra que los requisitos funcionales del dispositivo se pueden realizar, aunque sus métodos disten mucho de ser óptimos, seguros, escalables o eficientes. El objetivo de una prueba de concepto no es hacer un producto elegante que se pueda empezar a fabricar, y suele ser bastante bruto. Puede que sólo sea una protoboard con cables, sensores, servos y otro hardware que funciona con un PC conectado con salida de streaming a un monitor. En cualquier caso, estos productos en bruto sólo están ahí para darte la certeza de que se puede hacer algo.

A veces, conectar cosas a Azure forma parte de este proceso de prueba de concepto porque necesitas enviar datos a la nube para demostrar cómo se utilizan los datos. Es probable que esta conectividad sea compatible con los requisitos funcionales de tu dispositivo, sin pensar demasiado en la gestión del ciclo de vida del dispositivo.

Prototipo

Una vez que tengas una prueba de concepto en que demuestre la viabilidad técnica de un dispositivo, haz un prototipo para mostrar cómo será y funcionará el producto final. El prototipo adquiere un acabado orientado al producto que demuestra no sólo los requisitos funcionales, sino también algunos de los requisitos no funcionales. Si estás planificando una solución para toda la empresa, el prototipo suele ser algo que querrás mostrar a un inversor o a una parte externa para generar interés en el dispositivo. Puede que estos prototipos no sean perfectos, pero demuestran que tu plan dará como resultado un dispositivo funcional que se puede fabricar y utilizar.

Mientras desarrollas el prototipo, también puedes empezar a pensar, y quizás incluso a probar, cómo se gestionará tu dispositivo durante el resto de su ciclo de vida. Puede que quieras crear un Azure IoT Hub, conectar el dispositivo al IoT Hub y enviar y recibir datos.

Producto mínimo viable

Una vez que hayas refinado tu prototipo , tendrás un producto mínimo viable con todas las características funcionales y no funcionales necesarias para que el dispositivo se considere "completo". Para entonces, ya deberías haber averiguado cómo se puede gestionar tu dispositivo desde la nube con todos los servicios en la nube de apoyo. A veces, un producto mínimo viable es la forma más básica de un producto, o quizá algo más que eso. Esto es todo lo que puedes necesitar para algunos dispositivos para asegurarte de que el dispositivo está listo para ser fabricado, al menos para su primera generación.

Durante las tres fases de I+D, tendrás que tomar muchas decisiones sobre tu dispositivo y sus numerosos requisitos funcionales y no funcionales. Puedes repasar cada una de las categorías que se tratan en los siguientes apartados para identificar qué requisitos debes tener en cuenta para tu dispositivo.

Hardware

La mayor parte del hardware de que elijas para un dispositivo servirá para apoyar la función principal de tu dispositivo. Utilizando el ejemplo del coche de antes, la mayoría de los componentes de hardware -como las ruedas, el volante, el motor, etc.- dan soporte a los requisitos funcionales del coche para el transporte. Los requisitos no funcionales del coche también se reflejan en el hardware. Tienes una forma de cambiar el aceite con un tapón y un filtro de aceite extraíble. Hay un puerto de diagnóstico para conectar a un ordenador y leer los códigos del coche. Estos entran en los requisitos no funcionales derivados del mantenimiento.

He aquí otro ejemplo en el contexto de la IO: imagina un dispositivo de imágenes con una cámara. La cámara y los recursos informáticos necesarios para el procesamiento de imágenes determinarán la selección del hardware. Sin embargo, algunos dispositivos, especialmente si no tienen una interfaz de usuario como una pantalla táctil, pueden necesitar un puerto para enchufar un cable para que un técnico pueda entrar en el dispositivo y arreglar cosas. A veces, los dispositivos vienen con un modo de diagnóstico especial que permite a un técnico o a un usuario solucionar problemas en el dispositivo.

Cuando consideres el hardware para tu dispositivo, tendrás que pensar en elementos como la computación necesaria para alimentar lo que quieres que haga el dispositivo, las medidas de seguridad que puede requerir y las características de conectividad que necesitará para acceder a la nube, lo que casi se da por hecho al tratarse de un dispositivo IoT. También tendrás que considerar qué características de hardware serán las mejores para la gestión del ciclo de vida del dispositivo.

Calcula

Durante la fase de I+D, tendrás que seleccionar los recursos informáticos de que soporten tanto la gestión del dispositivo como su función principal. En el extremo inferior de la gama informática, tienes los dispositivos más básicos y limitados que miden el almacenamiento RAM en megabytes y las velocidades en megahercios. En el otro extremo del espectro, tienes aparatos de hardware que pueden tener cientos de gigabytes de RAM, terabytes de almacenamiento y procesadores multinúcleo, y a menudo disponen de recursos informáticos dedicados, como GPU, para casos de procesamiento especializado.

La contrapartida de una mayor potencia de cálculo es el consumo de energía. Aunque los dispositivos limitados tienen una capacidad de cálculo mínima, suelen consumir milivatios o incluso microvatios de un solo dígito. Algunas aplicaciones requieren un consumo de energía mínimo a lo largo del tiempo porque los dispositivos deben instalarse en un entorno y funcionar durante largos periodos -quizás años- sin recargar el dispositivo.

Para un dispositivo, querrás seleccionar el hardware suficiente para ejecutar tu aplicación más algo de sobrecarga adicional con computación, RAM y almacenamiento para requisitos no funcionales o en caso de que una futura actualización necesite más computación. Tu dispositivo necesitará suficiente almacenamiento para descargar una actualización y aplicar esos cambios sobre el código existente.

Elementos de seguridad

Cuando consideres el hardware para tu dispositivo, querrás pensar también en la seguridad de . La seguridad es una parte importante de la gestión del ciclo de vida del dispositivo, especialmente cuando se trata de la ejecución de código, la reclamación del dispositivo, el aprovisionamiento del dispositivo y la seguridad en general. Por tanto, seleccionar la seguridad adecuada basada en hardware es una de las mejores defensas contra una serie de retos de seguridad y aprovisionamiento que se tratan más adelante en este capítulo.

Una de estas características de seguridad es un módulo de plataforma de confianza (TPM) . Los TPM existen en los ordenadores desde principios de la década de 2010. Estos microcontroladores criptográficos proporcionan un conjunto de funciones utilizadas en criptografía y seguridad en los dispositivos. Una de las principales funciones de un TPM es almacenar claves . Los dispositivos utilizan estas claves y las almacenan en el TPM en lugar de en la memoria. Una vez escritas, las claves no pueden eliminarse sin borrar el TPM. Si se pierden las claves, muchas otras cosas basadas en ellas no funcionarán, como el almacenamiento cifrado. Otra función principal de los TPM es proporcionar atestación basada en hardware . La atestación valida que el dispositivo es realmente el creado y enviado por un fabricante. Esto es especialmente útil en los dispositivos IoT. El TPM proporciona unicidad al dispositivo y lo autentica frente a un servicio de aprovisionamiento.

Los TPM utilizan una especificación publicada por la industria, actualmente en la versión 2.0 a finales de 2023. Los TPM se implementan de muchas formas distintas según el dispositivo, pero la mayoría utiliza un microcontrolador discreto para este fin. Los hipervisores integran un TPM virtual o utilizan el TPM de un dispositivo anfitrión para las máquinas virtuales. Las máquinas sin un TPM físico pueden utilizar TPM basados en software proporcionados por el firmware del dispositivo (BIOS, UEFI, etc.) o el sistema operativo. Los TPM por software pueden funcionar para fines de desarrollo, pero no se recomiendan para aplicaciones de producción. Utiliza en su lugar un TPM de hardware.

Muchos dispositivos restringidos y reforzados con seguridad , como Azure Sphere, tienen funciones de seguridad integradas, y en estos dispositivos no sería necesario un TPM. Sin embargo, utilizar un TPM de para atestiguar es aconsejable en dispositivos no restringidos que utilicen más computación commodity, como placas basadas en x86 o ARM para un dispositivo, especialmente en dispositivos con importantes problemas de seguridad.

Un TPM puede utilizarse como solución para mitigar muchas amenazas de seguridad comunes, pero también se utiliza en el aprovisionamiento de dispositivos. Esto se trata más adelante en este capítulo.

IA y ML

La inteligencia artificial (IA) y el aprendizaje automático (ML) de no siempre se utilizan en las soluciones IoT, pero cada vez se adoptan más porque tienen muchas aplicaciones pertinentes en las cargas de trabajo IoT. A veces es difícil saber si tu solución IoT necesita ML en el dispositivo mientras lo estás diseñando. IA es un término amplio que se utiliza para cubrir una franja de diferentes sistemas informáticos que intentan realizar tareas que normalmente requieren inteligencia humana. El ML es un subconjunto de la IA que se centra en crear y aplicar modelos desarrollados a partir del análisis de grandes conjuntos de datos para encontrar los modelos adecuados, y luego aplica esos modelos a nuevas entradas. Mi colega, Jeff Prosise, ha escrito un libro entero sobre el tema.¹

Algunos de los casos de uso canónicos para AL y ML incluyen el procesamiento de señales, como imágenes, vídeo y audio, y la identificación de patrones en grandes conjuntos de datos. En el pasado, los dispositivos IoT no solían ser capaces de ejecutar este tipo de cargas de trabajo en un dispositivo. Los datos debían transmitirse a la nube o a un dispositivo de perímetro para su procesamiento. Sin embargo, los recientes avances en el diseño de chips permiten ejecutar estas cargas de trabajo en los dispositivos IoT. El procesamiento de imágenes y audio tiene amplias aplicaciones en muchos contextos diferentes, como la gestión de inventarios, los coches autoconducidos, la videovigilancia, la fabricación y los hogares inteligentes. Uno de los casos de uso más populares consiste en avisar a alguien cuando una persona (en lugar de un animal o un objeto aleatorio) llega a la puerta de casa. Esto se debe a que se ha entrenado un modelo para reconocer a las personas mediante visión por ordenador. El modelo se implementa en el dispositivo para que pueda enviar la notificación sin tener que enviar un flujo de vídeo a Internet para que se analice allí.

Para soportar este tipo de cargas de trabajo, se utilizan dos tipos principales de hardware en las cargas de trabajo basadas en IA: las unidades de procesamiento gráfico (GPU) y los aceleradores de IA. Las GPU fueron el primer hardware informático ampliamente utilizado para el procesamiento de IA porque muchos PC, como las estaciones de trabajo y los ordenadores de juegos, disponían de GPU. En 2007, NVIDIA empezó a proporcionar SDK útiles para cargas de trabajo basadas en IA con CUDA. Las GPU suelen funcionar bien para cargas de trabajo de IA en hardware de clase PC, pero sus requisitos de refrigeración, consumo de energía y tamaño las sitúan fuera del alcance de la mayoría de las aplicaciones IoT; sin embargo, las GPU pueden seguir funcionando cuando un dispositivo se encuentra en algunos entornos con aplicaciones de perímetro.

Uno de los ejemplos más populares es la Unidad de Procesamiento Tensorial (TPU) de Google , que ahora se está abriendo camino en dispositivos como los teléfonos. Una TPU funciona con la biblioteca TensorFlow de Google, permitiendo que los modelos diseñados para TensorFlow se ejecuten en una TPU. Google ha construido varios tipos de TPU, como ordenadores de placa única, dispositivos basados en USB y dispositivos basados en PCIe.

Inicialmente, las cargas de trabajo de IA en dispositivos IoT o de perímetro sólo eran posibles en ordenadores potentes y centralizados, como servidores u ordenadores basados en la nube. Este método sigue siendo relevante para IoT, pero los dispositivos IoT habilitados para IA tienen dos ventajas principales. En primer lugar, los dispositivos IoT con IA procesan los datos en tiempo real con baja latencia y sin riesgos de cortes de red. Esto permite a los dispositivos IoT tomar decisiones de forma más rápida y fiable. En segundo lugar, la IA en los dispositivos IoT reduce la carga de la red. Los datos se procesan localmente y, por tanto, no es necesario transmitirlos por la red a un dispositivo de perímetro o a la nube para su procesamiento.

Todavía no se ha generalizado la adopción de dispositivos con IA para la IO. Aun así, el efecto de goteo de la tecnología a medida que se abre camino en los dispositivos móviles, los ordenadores de placa única y los módulos de baja potencia implica que la IA en los dispositivos IoT cambiará la arquitectura de las aplicaciones para IoT y el diseño del hardware .

Conectividad

Dispositivo El hardware de conectividad influye en la forma en que un dispositivo se comunicará con la nube para enviar y recibir datos en ella. Cada forma tiene diferentes ventajas, desventajas y problemas de seguridad .

Ethernet

Ethernet es un método probado para conectar dispositivos a una red. Ethernet sigue siendo un medio ampliamente admitido para conectar dispositivos IoT. La mayor ventaja de Ethernet es que proporciona una gran comodidad para las necesidades de conectividad de un dispositivo debido a su simplicidad y ubicuidad en la red. Todo lo que se necesita es un cable Ethernet, y la red se encarga del resto. Ethernet tiene la ventaja de proporcionar Alimentación a través de Ethernet (POE), que puede proporcionar energía suficiente a los dispositivos más limitados. Aunque es sencilla, Ethernet puede causar problemas de seguridad, ya que no proporciona cifrado a nivel de hardware como hacen otros medios. Por tanto, la seguridad de la red es imperativa. Debes asegurar un puerto de red en un conmutador, aislar los dispositivos IoT mediante segmentación y restringir el acceso físico a un dispositivo.

WiFi

WiFi es el tipo más común de conexión de red utilizado para dispositivos porque es barato, rápido, seguro y ampliamente compatible. La instalación de WiFi varía, e incluye compatibilidad hacia atrás con dispositivos que se remontan a la primera generación de WiFi que comenzó en los años 90.

El WiFi tiene algunos inconvenientes. En primer lugar, las conexiones WiFi para dispositivos limitados pueden suponer una carga para la potencia de un dispositivo. En segundo lugar, las redes WiFi pueden crear un vector de ataque porque son accesibles a través del aire (no tienes que entrar físicamente en un edificio para acceder a la red). Los dispositivos en redes WiFi deben implementar un cifrado fuerte y claves WiFi almacenadas de forma segura.

Celular

Celular las conexiones a redes celulares tienen sentido para dispositivos que no estarán cerca de ningún tipo de instalación de red. WiFi y Ethernet suelen estar restringidas a los edificios, pero la cobertura celular existe en la mayoría de las zonas pobladas del mundo. Si no es la conexión principal para un dispositivo, también puede servir como reserva para un dispositivo.

Los módems celulares, al igual que el WiFi, pueden consumir bastante energía para los dispositivos limitados. Además, aunque las redes de telefonía móvil suelen estar estrechamente controladas por el proveedor de telefonía móvil, nunca debes suponer que una red de telefonía móvil es segura en sí misma. Los dispositivos de una red móvil están en una red pública y, por tanto, deben estar reforzados en seguridad en la medida de lo posible.

Bluetooth

Bluetooth no suele proporcionar conectividad a Internet, pero puede transmitir información de un dispositivo a otro que tenga conexión a Internet. En muchos casos, el dispositivo conectado a Internet actúa como proxy, concentrador y perímetro para varios otros dispositivos con Bluetooth. El propio dispositivo Bluetooth puede ser un dispositivo IoT o, en algunos casos, un teléfono o un ordenador portátil. Normalmente, estas soluciones utilizan una aplicación si se trata de un dispositivo de consumo o una conexión de seguridad con Bluetooth entre el dispositivo y su proxy de Internet.

Bluetooth es un protocolo relativamente fácil de implementar para los desarrolladores, pero esto significa que un dispositivo debe tener otro dispositivo, como un teléfono o un ordenador portátil, para poder conectarse a Internet. Además, Bluetooth tiene un alcance relativamente limitado.

Otros

Ethernet, WiFi, móvil y Bluetooth son modos habituales de conexión, pero el IoT no se limita en absoluto a ellos. Algunos fabricantes de dispositivos crean conexiones especializadas a través de medios para proporcionar conectividad, como cables coaxiales, infraestructura eléctrica o un protocolo inalámbrico propio.

Independientemente de cómo se conecte el dispositivo, debe tener en cuenta la seguridad y otros requisitos no funcionales como la reclamación, el aprovisionamiento, la actualización y el desaprovisionamiento para trabajar con Azure, y todos ellos requieren una conexión de red para funcionar .

Software

El software como parte del nexo IoT proporciona todas las instrucciones que el hardware de tu dispositivo ejecuta para recopilar y procesar datos antes de enviarlos finalmente a la nube. El software necesario para que esto suceda está formado por capas de sistemas operativos, SDK y, en última instancia, el código de tu aplicación. Cada capa tiene diferentes aspectos que debes tener en cuenta al seleccionar qué software utilizar en tu dispositivo.

Sistemas operativos

Un sistema operativo proporciona una base para que funcione el resto de tu software. Todos son diferentes, así que tienes que pensar qué sistema operativo se ajusta a tus objetivos de diseño y a los requisitos del hardware. No podrías ejecutar un sistema operativo más pesado como Ubuntu IoT Core que viste en el Capítulo 3 en algo como un dispositivo Arduino, y no puedes esperar que FreeRTOS funcione bien en un hardware de clase PC. La conclusión es que un sistema operativo tiene que funcionar para las necesidades de tu dispositivo y ajustarse a su ciclo de vida general.

Enel Capítulo 2 se trataron algunos sistemas operativos relacionados con Azure con Azure Sphere, Azure RTOS y Windows IoT. Sin embargo, más allá del ámbito de un sistema operativo centrado en Azure, puede que quieras considerar:

Elementos de seguridad

Independientemente de la aplicación , ya sea sencilla o compleja, el sistema operativo que elijas para un dispositivo debe ser seguro. La mayoría de los sistemas operativos concebidos explícitamente para su uso en IoT están construidos desde cero pensando en la seguridad. Los sistemas operativos basados en Linux son conocidos por sus estrictos controles de seguridad y pueden reforzarse para optimizar la seguridad del dispositivo. Además, admiten funciones de hardware de seguridad como los TPM. El Capítulo 14 cubre diferentes tipos de consideraciones de seguridad al construir dispositivos.

Compatibilidad

Un factor importante de a la hora de seleccionar un sistema operativo para un dispositivo es su compatibilidad con el software y el hardware que tengas previsto utilizar. En cuanto al software, la mayoría de los sistemas operativos sin restricciones, como los basados en Linux o Windows, serán compatibles con una amplia gama de plataformas de software como .NET, Python o JavaScript. Los dispositivos más limitados serán mucho más selectivos, con algunas plataformas especialmente construidas para lenguajes específicos. Sin embargo, los dispositivos IoT pueden ejecutar aplicaciones C y C++ de en la mayoría de los casos.

La compatibilidad de hardware de un SO implica qué CPU admite un dispositivo y qué otro hardware, como el hardware de conectividad de red, la integración de dispositivos mediante controladores y las interfaces de hardware como GPIO, serie y USB, admite un sistema operativo. Los sistemas operativos basados en Linux gozan de una amplia compatibilidad con una gran variedad de hardware. Los SO más limitados, como FreeRTOS, tienen menos opciones pero, en general, no exigen grandes requisitos de hardware.

Simplicidad

Simplicidad, en lo que respecta a los sistemas operativos, es el criterio que probablemente tenga un impacto más significativo, porque "simplicidad" puede tener muchos significados. Un sistema operativo debería

Ser fácil de usar, construir y asegurar
Ocupan poco espacio
Requieren menos recursos informáticos, como RAM y CPU
Ser fácil de actualizar y mantener
Sé más seguro con una superficie de ataque pequeña

Sin embargo, la sencillez no implica renunciar a las capacidades. Un sistema operativo sencillo parte del minimalismo como objetivo de diseño y permite a los usuarios basarse en él utilizando herramientas como gestores de paquetes y scripts de configuración.

Coherencia

Al seleccionar un SO para un dispositivo, debes aspirar a la coherencia , lo que significa que el SO debe tener una gestión del ciclo de vida regular y predecible. Muchos sistemas operativos modernos utilizan un modelo de soporte a largo plazo (LTS) para gestionar las actualizaciones. Una versión LTS de un sistema operativo es una compilación concreta que traerá actualizaciones del sistema, normalmente parches de seguridad, hasta una fecha publicada. La versión, sin embargo, puede no recibir nuevas funciones. Para los sistemas operativos de dispositivos que no van a recibir actualizaciones de hardware, las versiones LTS son una bendición: un fabricante de dispositivos puede implementar un sistema operativo y parchearlo de forma predecible en el futuro sin tener que volver a crear imágenes o actualizar el sistema operativo. Además, los dispositivos no siempre necesitan las funciones más recientes del sistema operativo para seguir cumpliendo la función para la que fueron diseñados. Windows IoT y la mayoría de las versiones de Linux, como Ubuntu Core y Yocto Linux, ofrecen versiones LTS.

Los sistemas operativos son la base del funcionamiento de un aparato. Elegir el adecuado no es sencillo.

SDKs

Enel Capítulo 2 se trataron los SDK de Azure para dispositivos con y sin restricciones para la conectividad Azure. Esos SDK, sin embargo, serán sólo algunos de los SDK que utilizarás para tu dispositivo. Si trabajas con hardware de un proveedor de hardware, es probable que se te suministren SDK para ese hardware. Además, puedes crear un SDK para tu dispositivo si pretendes ampliarlo.

Los SDK son una dependencia de para tu aplicación, pero muchos SDK de también tienen sus propias dependencias. Dependerán del marco de trabajo de la aplicación, como Node.js, Python o .NET, y probablemente incluirán paquetes y código que el SDK necesita para ejecutarse sobre lo que ellos proporcionan. El software evoluciona constantemente, por lo que es necesario actualizar el software y las dependencias de vez en cuando. He aquí algunas cosas que debes asegurarte:

Monitorea las actualizaciones de los SDK y sus dependencias, especialmente las actualizaciones de seguridad.
Desarrolla pruebas de regresión automatizadas y escanea el código más reciente en busca de vulnerabilidades de seguridad con herramientas como SonarQube.
Incluye las actualizaciones como parte de un ciclo de vida de actualización del dispositivo predecible.

Aislamiento de la aplicación

Enel Capítulo 14 se habla extensamente de la seguridad, pero una forma de mejorar significativamente la seguridad de las aplicaciones es adoptar el aislamiento de aplicaciones . El aislamiento de aplicaciones significa que el código de tu aplicación, y normalmente los tiempos de ejecución asociados, se ejecutan en un entorno aislado del sistema operativo principal. El sistema operativo sólo expone lo que es esencial para que se ejecute una aplicación.

Una forma fácil de hacerlo en los sistemas basados en Linux es utilizar chroot. El comando chroot es la abreviatura de "cambiar" y "root". Configura un sistema de archivos aislado para un proceso. El proceso no puede navegar por los archivos del sistema de archivos del host, sólo por los que están dentro del contexto chroot. Esta utilidad también proporciona cierto aislamiento de ejecución y seguridad en torno a un proceso para aislarlo del resto del sistema operativo.

Docker es otra forma de aislar procesos. Sin embargo, Docker es más que un simple aislamiento. Es todo un ecosistema utilizado para empaquetar e implementar software en contenedores. Las imágenes Docker se ejecutan en un sistema operativo anfitrión en un entorno completamente aislado. Proporcionan una forma cómoda de distribuir aplicaciones porque se empaquetan y publican en un registro de contenedores. Las imágenes se extraen del registro y se inician como nuevas instancias de la imagen como contenedores. Puedes publicar una nueva versión de tu imagen de contenedor si necesitas actualizar tu aplicación. Docker puede instalar esa imagen sin necesidad de actualizar el sistema operativo subyacente. El Capítulo 6 contiene una explicación completa de los contenedores Docker y del flujo de trabajo de los contenedores Docker.

Una tercera forma que funciona con muchas distribuciones Linux aprovecha un proyecto llamado Snapcraft. Snapcraft crea paquetes llamados "snaps" que se implementan en un dispositivo Linux a través de un gestor de paquetes. Utiliza un modelo de aislamiento de aplicaciones similar al de Docker con los contenedores, pero proporciona un enfoque más declarativo que incluye instrucciones tanto de construcción como de ejecución para la aplicación y expone diferentes cosas de forma más implícita que explícita, como la conectividad de red o el acceso a un hardware concreto. Snapcraft permite al demonio snapd averiguar los detalles de lo que significan estas declaraciones. Los snaps son ampliamente compatibles con las distribuciones Linux orientadas al IoT, como Yocto y Ubuntu Core.

Azure Sphere, aunque es un dispositivo limitado, proporciona aislamiento de aplicaciones para mejorar la seguridad del dispositivo. Las aplicaciones se ejecutan en un contenedor que expone el hardware a través de una API.

Construir, probar y liberar

El proceso de creación, prueba y publicación de software para un dispositivo es polifacético, ya que implica sistemas operativos, marcos, SDK, dependencias y tu software.

La forma más básica de este proceso consiste en construir algo manualmente y enviarlo a un dispositivo. Esto, sin embargo, no se presta bien a un código seguro y de calidad. Para mejorar la calidad y la seguridad del código, éste debe someterse a una serie de análisis y pruebas antes de enviarlo al dispositivo. Para agilizar este proceso, los desarrolladores utilizan la integración continua y la entrega continua (CI/CD) de mediante la automatización, normalmente denominada pipelines.

El proceso CI/CD implica crear software a partir del código fuente, probar ese software mediante pruebas automatizadas con, por ejemplo, pruebas unitarias y simuladores de dispositivos para pruebas de integración, empaquetar tu software y, por último, implementar ese software en los dispositivos.

El CI/CD a través de la automatización tiene el beneficio añadido de capas adicionales de seguridad que ayudan a mejorar la calidad y la seguridad del código. Aprovechar estas funciones de seguridad mediante la automatización no suele añadir tiempo al proceso de compilación:

Asegúrate de que los usuarios que contribuyen al código son actores de confianza con los permisos adecuados para ver y contribuir al código.
Asegúrate de que los desarrolladores aportan código mediante un proceso de revisión. Por lo general, esto impide confirmar código en la rama "principal" de un proyecto. Las contribuciones deben enviarse en forma de pull request, y sólo los agentes autorizados, tras revisar el código, pueden confirmar el código en la rama principal.
Asegúrate de que el código que pasa por un proceso de compilación lo hace con una entidad de seguridad de confianza, normalmente una que no es una entidad de seguridad de usuario.
Utiliza la firma de código para asegurarte de que el dispositivo puede validar el código instalado en un dispositivo antes de instalarlo utilizando autoridades de certificación de confianza.
No permitas que los colaboradores envíen directamente ninguna versión a un repositorio de construcción, como un registro de contenedores.

Utilizar pruebas, escaneos de seguridad y controles de seguridad en torno a un proceso de construcción y prueba puede ayudar a mejorar la calidad general de un producto desde las fases iniciales de desarrollo, pasando por la fase de creación de prototipos, el proceso de fabricación y, en última instancia, el proceso de actualización.

En la medida de lo posible, deberías construir y probar el código sin necesidad de dispositivos, porque esto permite que el código "falle rápido", lo que significa que se pueden encontrar problemas en el código antes de pasar ese código a un dispositivo. Si se necesita un dispositivo, intenta utilizar hardware emulado si está disponible con un proyecto como Qemu, que proporciona emulación de procesador para crear máquinas virtuales de todas las variedades. Qemu puede ejecutarse en un host Linux como parte de una canalización CI/CD.

Enel Capítulo 3 se trató el uso de simuladores de dispositivos en pruebas de integración, pruebas de regresión, pruebas de carga y pruebas de rendimiento como parte de la automatización del código del lado de la nube. El código que se ejecuta en un dispositivo debe pasar por un proceso similar con sus pruebas de integración, pruebas de regresión, pruebas de carga y pruebas de rendimiento. Como todo el código, debe utilizar pruebas unitarias para validar las unidades de código (normalmente hasta el nivel de método) y buscar vulnerabilidades y patrones de seguridad utilizando herramientas como SonarQube.

En última instancia, habrá que probar el código en un dispositivo físico. En la medida de lo posible, automatiza también este proceso, pero suele ser preferible ejecutar las pruebas en un dispositivo porque requiere menos tiempo y menos intervenciones manuales entre construcciones.

Una vez que el código pasa por una fase de construcción y prueba, se construye y empaqueta para una versión. Una versión es simplemente una versión del código que podría ejecutarse como versión final. Este código puede pasar por algunas comprobaciones más, como pruebas de aceptación o similares, antes de ser enviado a un entorno para su publicación.

En las últimas secciones se han analizado los distintos requisitos no funcionales que debes tener en cuenta al construir un dispositivo IoT que tenga que ver con el hardware y el software. Cuando empieces a desarrollar un prototipo, es probable que pases tanto tiempo trabajando en los requisitos no funcionales del dispositivo como en su función principal. Esto es bastante natural. Los dispositivos, especialmente los dispositivos IoT, deben tenerlos en cuenta como parte de la cartera de funciones y tareas de un dispositivo. Parte de esto puede "externalizarse" adoptando plataformas más completas de funciones como Azure Sphere, pero en última instancia, un dispositivo es tu creación: es tu diseño para satisfacer una necesidad específica que tú imaginas. Incluso si utilizas servicios para cierto nivel de automatización, éstos deben integrarse con el dispositivo, aunque no los construyas tú mismo .

Fabricación

El proceso de fabricación de implica tomar un prototipo refinado y crear el producto real que se utilizará. La complejidad del proceso depende del alcance y la escala del dispositivo, y de quién lo vaya a utilizar. El proceso de fabricación de los dispositivos será radicalmente distinto para estas aplicaciones. Las etiquetas comerciales se producen por miles en una fábrica mediante un proceso repetible. En cambio, las soluciones más personalizadas pueden fabricar sólo docenas de dispositivos, cada uno adaptado a las necesidades del usuario.

La fabricación de dispositivos IoT no suele tomar materias primas y componerlas en algo útil; más bien, la fabricación requiere adquirir componentes de hardware y ensamblar esos componentes, instalar software y preparar el dispositivo para su aprovisionamiento. El proceso de fabricación comienza en paralelo con la investigación y el diseño.

A medida que un dispositivo pasa de la prueba de concepto a un prototipo e incluso a un producto mínimamente viable, los fabricantes de dispositivos investigan posibles soluciones y empiezan a procurarse el hardware y las instalaciones para fabricar dispositivos IoT. A medida que un dispositivo se acerca al estado de producción, se elaboran planes detallados para su creación. Un fabricante hará un pequeño lote de dispositivos de preproducción para asegurarse de que los dispositivos cumplen las especificaciones requeridas. Después, el dispositivo se fabrica en serie. Por último, el producto se empaqueta y se envía a un usuario, que instalará el dispositivo o hará que un representante lo instale.

Independientemente del proceso, el inicio de las primeras series de producción de fabricación es el punto del ciclo de vida del producto que marca el final de la importante fase de investigación y diseño, ya que el dispositivo comienza su secuencia principal con el aprovisionamiento.

Envío

Una vez fabricado un dispositivo , se traslada del fabricante a su lugar de implementación. Dependiendo del tipo de aparato, esto puede ser tan sencillo como llevarlo de la fábrica al lugar de instalación e implementación hasta algo mucho más complicado, como la distribución al por menor. Todo ello implica algún tipo de proceso de envío.

Menciono aquí el envío, no porque sea especialmente técnico, sino porque es un hito importante en la vida de un dispositivo. Es probable que sea la última vez que el fabricante vea físicamente el dispositivo. En este punto, el dispositivo tiene todo lo necesario para funcionar y está listo para realizar su función principal.

Reclamación y aprovisionamiento

Aunque la reclamación del dispositivo es técnicamente un paso del proceso de fabricación, es un paso bastante importante en la gestión del ciclo de vida del dispositivo, porque es el paso en el que un dispositivo recibe su conjunto inicial de credenciales utilizadas en el aprovisionamiento.

Los dos principales servicios de Azure utilizados en el aprovisionamiento de dispositivos son el Servicio de Aprovisionamiento de Dispositivos (DPS) de y el IoT Hub asociado al dispositivo. El DPS de Azure es un intermediario de conexión entre un dispositivo y un Azure IoT Hub. Un DPS no es necesario para los dispositivos si éstos se envían con las credenciales para el IoT Hub ya en el dispositivo. Pero un DPS es una forma estupenda de gestionar el aprovisionamiento de dispositivos, porque automatiza la creación y gestión de dispositivos en un IoT Hub. Además, un único DPS puede gestionar más de un IoT Hub, lo que lo hace más propicio para implementaciones de dispositivos IoT a gran escala.

El Hub IoT en Azure facilita muchas operaciones de comunicación, hermanamiento, actualizaciones y mensajería de los dispositivos. Por eso es el componente del lado de la nube más importante para los dispositivos. Más adelante en este capítulo hablaré del hermanamiento y las actualizaciones. El Capítulo 6 trata de las Implementaciones de IoT Edge, y el Capítulo 5 profundiza en los distintos tipos de mensajería que admite IoT Hub. Por ahora, piensa en la mensajería como una de las dos caras de lo que el DPS intermedia.

La reclamación y la provisión implican lo siguiente:

La reclamación comienza creando un conjunto inicial de credenciales que se cargarán en un dispositivo. Esta acción se realiza en la nube en el DPS. Estas credenciales pueden ser:

Fichas de Acceso Compartido (SAS)

Un token SAS utiliza una clave almacenada en el dispositivo y en la nube. El dispositivo utiliza la clave para firmar un token, y el DPS utiliza la misma clave para validar el token.

Certificados X.509

Un certificado X.509 utiliza la Infraestructura de Claves Privadas (PKI) de para crear un certificado que utiliza una autoridad de certificación de confianza entre el dispositivo y la nube.
Se pueden utilizar ambos, pero los certificados son probablemente más seguros y también serán necesarios si quieres utilizar una atestación de dispositivo basada en TPM . Las credenciales pueden ser un conjunto único de credenciales para un dispositivo, o las credenciales pueden ser compartidas como parte de un grupo de dispositivos, dependiendo de la necesidad. Un dispositivo único necesita proporcionar un ID de dispositivo para identificarlo correctamente.
La reclamación continúa una vez creadas las credenciales en el DPS. Estas credenciales se guardan en el dispositivo antes de su envío. Las credenciales pueden formar parte de un proceso de creación e incorporarse al firmware o al sistema operativo instalado en el dispositivo. Las credenciales también pueden instalarse por separado después de que el dispositivo tenga su firmware o sistema operativo instalado. Una vez cargadas estas credenciales iniciales, la reclamación está completa.
El aparato se envía tras el proceso de fabricación y tras la reclamación. El envío se refiere a que el aparato pasa de la fase de fabricación a estar listo para su instalación.
Una vez que un dispositivo está en el lugar previsto para su instalación, está listo para el aprovisionamiento. El aprovisionamiento comienza una vez que el dispositivo está encendido y conectado a una red. El dispositivo utiliza las credenciales precargadas para ponerse en contacto con el DPS a través de uno de los tres esquemas diferentes:

Fichas de Acceso Compartido (SAS)

Los tokens SAS se generan utilizando la clave de acceso compartida enviada en el dispositivo. El ID del dispositivo y otros metadatos componen el token SAS, que luego se firma utilizando la clave. La firma y los metadatos se devuelven al DPS para su autentificación.

Certificados X.509

Los certificados proporcionan un mecanismo de seguridad sólido porque utilizan una autoridad de certificación externa para validar los certificados antes de utilizarlos. El certificado se emite desde el DPS. Una vez validado, el certificado se presenta al DPS para autenticar el dispositivo contra un certificado raíz.

Atestación basada en TPM con certificados

La autenticación basada en TPM proporciona un método de autenticación a nivel de hardware que utiliza certificados almacenados en un TPM. El TPM utiliza sus ID de hardware y el certificado para autenticar el dispositivo. Este método es el más seguro porque mitiga la suplantación de identidad y otros ataques contra una nube que utilice IoT.

Una vez aceptadas las credenciales, el DPS asigna un dispositivo a un Hub IoT. La asignación del Hub IoT puede ser uno de los muchos hubs diferentes asignados como parte de un proceso de selección round-robin o un hub específico para las credenciales proporcionadas.
Una vez que el dispositivo se autentica con las credenciales del dispositivo, el DPS crea un conjunto de credenciales específicas del dispositivo para el IoT Hub. Las credenciales del dispositivo en el IoT Hub pueden ser una cadena de conexión utilizando un token SAS o un certificado X.509 derivado de otro certificado. En este punto, el IoT Hub está listo para que el dispositivo se conecte. El aprovisionamiento se considera completado en este punto.
Una vez creadas las credenciales en el IoT Hub, el DPS las envía al dispositivo. Estas credenciales se almacenan en el dispositivo y deben protegerse como cualquier otro conjunto de credenciales. Las credenciales también contienen información sobre dónde encontrar el IoT Hub. Además, el DPS envía una configuración inicial para el dispositivo. Se trata de los mismos datos almacenados en el gemelo del dispositivo en Azure.
El último paso es utilizar las credenciales proporcionadas por el IoT Hub.

Una vez que el dispositivo tiene las credenciales que necesita para el IoT Hub, el DPS puede apartarse y dejar que el dispositivo y el IoT Hub se comuniquen entre sí directamente. Si alguna vez hay que volver a aprovisionar un dispositivo, éste simplemente pasa por el mismo proceso que el aprovisionamiento. Recibe un nuevo conjunto de credenciales, que pueden o no hablar con el mismo Azure IoT Hub. En cualquier caso, el aprovisionamiento del dispositivo prepara el escenario para la secuencia principal del dispositivo como parte de su ciclo de vida .

Aprovisiona Dispositivos con un Hub IoT a través del Servicio de Aprovisionamiento de Dispositivos

Configurar un Servicio de Aprovisionamiento de Dispositivos y un Hub IoT en Azure es bastante sencillo. La plantilla también está en la carpeta del Capítulo 4 del repositorio de código del libro, por si quieres implementarla de otra forma. En cualquier caso, la plantilla toma dos parámetros: el Nombre del Servicio de Aprovisionamiento y el Nombre del Hub IoT. Estos forman parte del nombre de host de cada uno, por lo que tendrán que ser únicos. Una vez que tengas un nombre, podrás rellenar los campos en el portal de Azure. También tendrás que seleccionar una suscripción y un grupo de recursos, o puedes crear un nuevo grupo de recursos. Selecciona una región para el grupo de recursos.

Cuando estés listo, haz clic en el botón "Revisar + crear". La plantilla ARM vinculará el Hub IoT al Servicio de Aprovisionamiento de Dispositivos como parte de la implementación. Espera unos instantes a que termine. Puedes monitorizarlo en "Implementación en curso". Una vez finalizado, haz clic en "Ir al grupo de recursos" para terminar la configuración aquí detallada:

En el grupo de recursos, elige el Servicio de Aprovisionamiento de Dispositivos.
Selecciona "Gestionar inscripciones" y, a continuación, "Añadir grupo de inscripción". Un grupo de inscripción permite que varios dispositivos se inscriban en uno o varios IoT Hubs. Una inscripción individual es para un dispositivo específico.
La hoja "Añadir grupo de inscripción" tiene varios campos que rellenar. En el momento de escribir este libro, no hay forma de automatizar la configuración de un grupo de inscripción utilizando una plantilla ARM.
1. En "Nombre del grupo", introduce un nombre descriptivo para el grupo.
2. En "Tipo de atestación", selecciona "Clave simétrica". La clave simétrica es adecuada para los fines de este tutorial, pero es preferible un Certificado para una implementación más segura.
3. Mantén marcada la opción "Generar claves automáticamente".
4. Mantén "Dispositivo de perímetro IoT" en falso. En el Capítulo 5, configurarás un dispositivo IoT Edge utilizando este DPS.
5. Toma el valor predeterminado en "Selecciona cómo quieres asignar dispositivos a los hubs". Como sólo hay un único Hub IoT, esta configuración está bien. Para implementaciones de dispositivos más grandes, puedes utilizar un método diferente o incluso personalizarlo con una Función de Azure.
6. La hoja se dirigirá por defecto al Hub IoT que creaste al crear el DPS.
7. Toma los valores por defecto en "Selecciona cómo quieres que se manejen los datos del dispositivo al reprovisionarlo".
8. Para "Estado gemelo inicial del dispositivo", borra lo que hay en el cuadro de texto y sustitúyelo por un conjunto vacío de llaves {}.
9. Deja "Activar entrada" en Activar.
10. Por último, haz clic en "Guardar".
Ahora, selecciona el grupo de inscripción que acabas de crear.
Haz clic en el botón "Copiar al portapapeles" situado junto al valor de Clave primaria.
En Visual Studio Code, abre la carpeta del dispositivo con el que trabajaste en el Capítulo 2. Si no lo has hecho, puedes crear un dispositivo de muestra o un dispositivo simulado utilizando el código del repositorio. Sigue las instrucciones del Capítulo 2 para obtener información sobre cómo hacerlo.
Abre settings.json.
Pega la clave que has copiado en el valor de symmetricKey.
Ahora, navega hasta la hoja "Visión general" del portal Azure. Necesitas obtener algunos valores de esta pestaña:
- Obtén el valor "ID Scope" de la hoja y pégalo en el valor para idScope en settings.json.
- Obtén el valor "Service endpoint" de la hoja y pégalo en el valor para provisioningHost en settings.json.
  
  Cuando hayas terminado, deberías tener un settings.json que se parezca a esto:
```
{   
    "start":"dps",
    "telemetry":"simulator",
    "camera":"simulator",
    "pollFreq": 5000,
    "connString": "",
    "provisioningHost":"blaizedps1.azure-devices-provisioning.net",
    "idScope":"0ne007C4D38",
    "symmetricKey":"rREfrgOcrb7Bm4da…6WvRs2HzwLPcg==",
    "registrationId":"device1"
}
```
Guarda el archivo settings.json. Esto es esencialmente la parte de reclamación del ciclo de vida de un dispositivo.
Ahora, inicia el dispositivo. El dispositivo utilizará la clave contra el Servicio de Aprovisionamiento para la atestación y completará el proceso de aprovisionamiento. El dispositivo, tanto si utilizas un dispositivo de muestra como un simulador, crea un archivo llamado conn.json en la carpeta raíz del repositorio. Este archivo contiene la cadena de conexión para el dispositivo. Cada vez que ejecutes el dispositivo, éste utilizará este archivo para saber qué IoT Hub debe buscar y cómo conectarse.
En el portal de Azure, navega por el IoT Hub que has creado. Allí, en dispositivos, deberías ver un dispositivo con el ID de registro "dispositivo1" o el que hayas cambiado en el archivo settings.json.

Esta demostración muestra el proceso de reclamación y el proceso de aprovisionamiento a través de IoT Hub y el Servicio de Aprovisionamiento de Dispositivos. A partir de aquí, el dispositivo entra en su secuencia principal, donde recibirá actualizaciones, datos de hermanamiento y otros mensajes. Mantén el dispositivo y el recurso cerca para otras demostraciones de hermanamiento y actualizaciones .

Secuencia principal

La secuencia principal del dispositivo comienza tras el aprovisionamiento del dispositivo y éste empieza a realizar su función principal. La secuencia principal del ciclo de vida de un dispositivo tiene tres funciones principales cuando trata con la nube. En primer lugar, un dispositivo tiene que comunicarse con la nube. Esto implica toda la telemetría, comandos y eventos que fluyen de un dispositivo a la nube y de la nube al dispositivo. En segundo lugar, un dispositivo envía y recibe actualizaciones de hermanamiento. Y tercero, la secuencia primaria de un dispositivo incluye parches y actualizaciones de software.

Comunicación

La comunicación entre un dispositivo y la nube es fundamental para su funcionamiento. Sean cuales sean los datos que recogen los dispositivos o la función que proporcionan, el dispositivo necesita comunicarse con la nube para hacerlo. Incluso las actualizaciones de aprovisionamiento del dispositivo son comunicaciones entre el dispositivo y la nube. Para nuestros propósitos aquí, la comunicación es la secuencia de comunicación principal que implica transmitir eventos y telemetría desde el dispositivo a la nube y permitir que la nube envíe comandos y otros datos al dispositivo. El Capítulo 5 trata la comunicación en profundidad.

Hermanamiento

En IoT, el hermanamiento significa que la nube almacena una copia de la configuración de un dispositivo, de su estado, o de ambos, en la nube. Este "gemelo" permite a las aplicaciones consultar la información de todos los dispositivos de una carga de trabajo IoT sin tener que ponerse en contacto con cada dispositivo, un proceso que podría tardar una eternidad en completarse, y que incluso podría no ser fiable. Los dispositivos gemelos existen por varias razones, pero la principal es permitir que los servicios y aplicaciones del lado de la nube consulten e informen sobre los estados de los dispositivos sin tener que ponerse en contacto con cada uno de los dispositivos que forman parte de una implementación IoT. Estos datos permiten a la gestión de dispositivos tomar decisiones sobre un dispositivo. Por ejemplo, los datos del dispositivo pueden contener información sobre la versión del software instalado en el dispositivo, como su sistema operativo, la versión de la aplicación, la versión del SDK o la versión del hardware. Cuando haya nuevo software disponible, el mecanismo de actualización en la nube puede utilizar los datos de hermanamiento para saber qué dispositivos necesita actualizar y, a continuación, realizar un seguimiento de las actualizaciones a medida que se aplican.

Otro uso cotidiano del hermanamiento es permitir la gestión centralizada de la configuración de un dispositivo para aspectos no funcionales y funcionales. Cuando se aprovisiona un dispositivo, puede recibir una configuración inicial como parte de ese aprovisionamiento. Sin embargo, a medida que pasa el tiempo, puede ser necesario cambiar la configuración. Por ejemplo, si un dispositivo está configurado para informar a la nube una vez cada hora con nuevos datos, puede enviarse una nueva configuración para indicar al dispositivo que informe cada dos horas para ahorrar ancho de banda.

Azure IoT Hub proporciona toda la fontanería para gestionar el estado de los dispositivos conectados a un Hub IoT. IoT Hub realiza un seguimiento del estado de hermanamiento en una base de datos que forma parte del Hub. Los usuarios pueden leer datos sobre los dispositivos utilizando un lenguaje de consulta tipo SQL basado en sus datos de hermanamiento. Un gemelo digital viene con dos conjuntos de datos de : deseados y notificados. Deseado refleja de la nube a la máquina lo que la nube cree que debería ser el estado de los datos de hermanamiento. Una vez que los datos de hermanamiento cambian, dispara un evento que notifica a un dispositivo que los datos de hermanamiento han cambiado, y pasa los nuevos datos al dispositivo como parte de ese evento. Por otro lado, los dispositivos emitirán datos sobre su estado, que se convierten en la parte de estado notificada de los datos de hermanamiento.

Sin embargo, los datos deseados y los comunicados no tienen por qué coincidir. La forma en que se utilicen y comuniquen los datos del hermanamiento depende de la solución. Por ejemplo, un dispositivo puede notificar datos sobre su estado almacenados como parte del gemelo digital, pero ese estado es intrascendente: es mera información sobre el estado del dispositivo.

En otras condiciones, un dispositivo debe informar de un estado coherente con el estado deseado. Esto es especialmente cierto para el estado de configuración. Considera el ejemplo que di antes sobre la frecuencia con la que un dispositivo debe informar a la nube. Si el estado deseado indica que el dispositivo debe informar cada dos horas, pero el estado informado indica que el dispositivo está configurado para informar cada una hora, algo falla en ese dispositivo.

Como diseñador de dispositivos, debes utilizar adecuadamente los datos de estado y los eventos. Los SDK de Azure IoT Hub proporcionan eventos que puedes cablear en tu código para responder a las actualizaciones de eventos desde la nube. Asimismo, dispone de llamadas especiales para enviar a la nube datos gemelos notificados.

Hermanamiento de dispositivos con IoT Hub

Si aún no lo has hecho, implementa el IoT Hub y el Servicio de Aprovisionamiento de Dispositivos siguiendo las instrucciones dadas anteriormente en este capítulo, y aprovisiona tu dispositivo de muestra o simulador con el DPS para que pueda hablar con el IoT Hub. Una vez hecho esto, puedes trabajar con el hermanamiento IoT Hub:

En el IoT Hub, busca el dispositivo que aprovisionaste en dispositivos. Puedes hacerlo mirando tu IoT Hub, y seleccionando dispositivos a la izquierda. Desde aquí, deberías ver el dispositivo que aprovisionaste.
Cuando hayas localizado tu dispositivo, inícialo en Visual Studio Code. El dispositivo empezará a enviar datos al Hub IoT en el intervalo predeterminado, que es una vez cada 5.000 milisegundos.
En el dispositivo del portal Azure, selecciona "Dispositivo gemelo".
Allí verás un montón de datos JSON. Los datos JSON contienen información sobre tu dispositivo, como su nombre, estado y otros datos. En la sección de propiedades, verás dos objetos: el objeto desired y el objeto reported. El objeto desired expresa el estado deseado del dispositivo, y reported refleja el estado real del dispositivo. desired no tiene propiedades establecidas, pero, según se informa, debería tener pollFreq establecido con unos metadatos parecidos a éstos:
```
"reported": {
    "pollFreq": 5000,
    "$metadata": {
          "$lastUpdated": "2022-10-08T00:43:52.339081Z",
          "pollFreq": {
               "$lastUpdated": "2022-10-08T00:43:52.339081Z"
          }
    },
    "$version": 9
}
```
La propiedad $version se incrementa cada vez que el dispositivo informa de su estado. En este caso, es nueve veces.
En desired, añade el siguiente código:
```
"desired": {
    "pollFreq": 7000
}
```
Puedes eliminar los metadatos y la información de la versión.

Ahora, haz clic en el botón "Guardar". Después de guardar, el portal añadirá metadatos a la propiedad desired:

"desired": {
    "pollFreq": 7000,
    "$metadata": {
          "$lastUpdated": "2022-10-08T00:55:39.6799755Z",
          "$lastUpdatedVersion": 2,
          "pollFreq": {
               "$lastUpdated": "2022-10-08T00:55:39.6799755Z",
               "$lastUpdatedVersion": 2
          }
    },
    "$version": 2
}

El dispositivo recibirá el nuevo estado y empezará a informar en el intervalo que hayas establecido. En el ejemplo, el intervalo es de 7.000 milisegundos, o una vez cada 7 segundos. Deberías ver datos en la consola indicando que la propiedad se ha actualizado:
```
new desired properties received:{"pollFreq":7000,"$version":2}
```
De vuelta en el portal de Azure, navega hasta tu IoT Hub y selecciona "Consultas".
En el cuadro "Consulta", introduce la siguiente consulta SQL y haz clic en "Ejecutar consulta". Esta consulta seleccionará todos los dispositivos que tengan una propiedad deseada, pollFreq, establecida en 7.000, que probablemente sea sólo tu dispositivo:
```
SELECT * FROM devices WHERE devices.properties.desired.pollFreq = 7000
```
Puedes cambiar la consulta si quieres consultar las propiedades notificadas o cualquier otra propiedad de los datos de hermanamiento. Experimenta con diferentes consultas.

La consulta al IoT Hub de los datos de hermanamiento funciona para muchos casos de uso. Si la implementación de un dispositivo utiliza varios Hubs IoT, no existe una forma integrada de consultar los datos de hermanamiento en varios Hubs IoT. Podrías consultar cada hub, pero eso podría ser lento si existen muchos dispositivos. También requiere que estas consultas separadas se filtren o agreguen en la aplicación de llamada. Además, si hay que unir o agregar los datos de alguna manera, tampoco hay forma de hacerlo. En estos casos, es necesario exportar los datos a un almacén de datos externo para gestionar los datos de hermanamiento a través de una base de datos centralizada.

Las bases de datos de hermanamiento pueden ser de cualquier tipo, pero uno de los formatos más utilizados para rastrear datos de hermanamiento es una base de datos gráfica , representada en la Figura 4-4. Si no estás familiarizado con una base de datos gráfica, es bastante sencilla de entender, pero sus posibilidades son profundas. Una base de datos gráfica está formada por un número indefinido de nodos y perímetros.

Los nodos son esencialmente objetos que tienen propiedades, expresadas normalmente como un par clave-valor para cada propiedad. Un perímetro es una conexión entre dos nodos. El propio perímetro también puede tener propiedades, también expresadas como pares clave-valor. El poder de una base de datos de grafos es que permite que cualquier nodo se conecte a otro nodo mediante una arista. No hay límite al número de nodos con los que puede relacionarse un mismo nodo. Este tipo de base de datos permite relaciones arbitrarias entre distintos nodos.

IoT funciona bien con esta base de datos porque los datos de hermanamiento suelen expresarse como un conjunto de pares clave-valor. Cada dispositivo de la base de datos actúa como un nodo. Los dispositivos IoT pueden conectarse a muchas otras cosas de la base de datos. Pueden ser otros nodos que representen geografías, edificios, redes, otros dispositivos (IoT o de otro tipo) y dispositivos de perímetro, entre otros. Estas conexiones crean un gráfico atravesable, de modo que se pueden devolver conjuntos de datos para mostrar las relaciones entre todos los dispositivos y permitir experimentos para cuando los datos de un dispositivo puedan cambiar. Azure Digital Twin y Azure Cosmos DB son dos herramientas excelentes para hacer precisamente esto con bases de datos de gráficos.

Gemelo digital Azure

Azure Digital Twin (ADT) es la solución llave en mano de software como servicio (SaaS) para este fin. Sirve como base de datos gráfica centralizada que rastrea los datos de hermanamiento de los dispositivos desplegados, pero también permite topologías complejas que reflejan cómo están conectados los dispositivos y otros activos, como edificios, redes, ciudades y perímetros, más allá de los meros datos de hermanamiento. Estas topologías permiten a los usuarios realizar simulaciones con datos de hermanamiento en ADT para responder a escenarios "qué pasaría si" sobre los dispositivos.

Aunque ADT es llave en mano, en el momento de escribir este libro no proporciona ninguna integración nativa con IoT Hub para integrar los cambios de hermanamiento de dispositivos en ADT. Para ello, el usuario tiene que definir algo que pueda responder a los eventos del ciclo de vida de un dispositivo que se pasa a IoT Hub y registrar los resultados en la base de datos.

Azure Cosmos DB

Si ADT no parece una buena opción para tu aplicación, puedes crear una base de datos gráfica utilizando la API gráfica de Azure Cosmos DB de . La Graph API se basa en Gremlin, un lenguaje de consulta para recorrer grafos. La Graph API de Cosmos DB permite que las aristas y los nodos almacenen datos de pares clave-valor en el nodo o la arista para lo que represente.

El capítulo 6 abordará las opciones de bases de datos, examinando cómo funcionan los distintos paradigmas y arquitecturas de bases de datos con las cargas de trabajo de IoT, incluyendo Cosmos DB y Azure Digital Twin .

Más allá del hermanamiento, hay otro tipo de actualización: las actualizaciones de software. En este libro ya se ha aludido a ello, pero ahora es el momento de verlo más de cerca .

Actualizaciones

Conoces las actualizaciones del dispositivo si tienes un smartphone o un ordenador. De vez en cuando, recibirás una notificación diciéndote que tu teléfono tiene una actualización que hay que descargar e implementar en el dispositivo. Muchos de nosotros lo posponemos porque parece ocurrir en el peor momento. Al final, dejas a regañadientes que el dispositivo descargue las actualizaciones e inutilizas tu dispositivo durante algún tiempo hasta que se completa. A veces, la actualización falla, y puede que tu dispositivo deje de funcionar. En cualquier caso, nunca es una experiencia divertida.

Las actualizaciones son necesarias sobre todo para requisitos no funcionales, como corregir errores de software o mejorar la seguridad. Ocasionalmente, las actualizaciones pueden añadir funcionalidad a un dispositivo que no venía en él, pero esto está dentro de las limitaciones del hardware que ya está en el dispositivo.

A pesar de no ser divertidas, las actualizaciones de los dispositivos son un salvavidas para ellos. A través de las actualizaciones, los dispositivos reciben mejoras de software, nuevas funciones, parches de seguridad y otros mantenimientos de software muy necesarios que deberían hacer que un dispositivo funcione mejor y de forma más segura. Las actualizaciones de IoT no son diferentes. Los dispositivos necesitan que se les apliquen actualizaciones ocasionales por las mismas razones por las que los portátiles y los teléfonos necesitan actualizaciones de software. La mayor diferencia, sin embargo, es que los dispositivos IoT no suelen tener un componente de usuario para la actualización y, por tanto, deben gestionarse casi en su totalidad mediante herramientas de gestión remota.

Los dispositivos necesitan diferentes tipos de actualizaciones de software:

Actualizaciones del sistema operativo: Sistema operativo Las actualizaciones del sistema se aplican al sistema operativo que se ejecuta en el dispositivo, si tiene uno. Algunos dispositivos limitados no tienen un SO, pero incluso éstos pueden tener un sistema operativo en tiempo real (RTOS). Otros dispositivos necesitan actualizaciones del SO que pueden actualizar los controladores de hardware, los parches del núcleo y las correcciones de seguridad del SO, entre muchas otras. A menudo, este tipo de actualizaciones se gestionan a través del gestor de paquetes del dispositivo, si tiene uno, como Aptitude para Ubuntu o Windows Update en Windows.
Actualizaciones de la plataforma: Plataforma actualiza parches, mejoras y correcciones para todo lo relacionado con los archivos necesarios para tu aplicación, como un parche para Node.js o .NET. A veces se gestionan a través del gestor de paquetes de la misma forma que se gestionan las actualizaciones del SO. Si no es así, puede que tengas que considerar cómo afecta esto a la entrega de tu aplicación. Las plataformas construidas en torno a contenedores tienen un amplio conjunto de herramientas para empaquetar plataformas con una aplicación y entregarlas eficientemente a un dispositivo.
Actualizaciones de software: Software las actualizaciones se refieren a cualquier código que escribas y mantengas. Esto puede ir desde simples scripts o agentes encargados de recopilar y transmitir datos a la nube hasta algo más robusto con una experiencia de usuario completa y una lógica compleja. En cualquier caso, es probable que tu aplicación necesite parches con el tiempo.
Rotaciones clave: Rotar las claves de seguridad y los certificados de es una buena práctica de seguridad y funciona de forma similar a como funcionan otras actualizaciones. El ciclo de actualización puede enviar periódicamente nuevas claves que sustituyan a las antiguas, del mismo modo que el software nuevo sustituye al antiguo. Estas nuevas claves permiten la conectividad con la plataforma, mientras que las antiguas suelen revocarse una vez que las nuevas claves están en su lugar.

Desde finales de 2022, Azure tiene una función en vista previa para que realiza actualizaciones "over the air" (OTA). Estas actualizaciones proporcionan tres tipos diferentes de actualizaciones para dispositivos, a través del agente de actualización de dispositivos instalado como parte del código en un dispositivo restringido o como demonio en dispositivos no restringidos.

El agente de actualización de dispositivos de Azure sigue un patrón utilizado para actualizar dispositivos, según el cual un dispositivo ejecutará un programa o demonio independiente que no forma parte del software principal, normalmente un proceso totalmente distinto, que se encarga de realizar las actualizaciones. Utilizar un agente de actualización garantiza que las actualizaciones puedan aplicarse de forma más fiable a un dispositivo. Si falla una actualización, el agente puede reiniciarla o recuperarla.

Aplicar actualizaciones al dispositivo de muestra en un contenedor Docker

Contenedores es una de las muchas formas de implementar el código de un dispositivo y es una manera de hacer que una plataforma sea más extensible, de forma similar a como funciona IoT Edge. Aunque IoT Edge se trata en el Capítulo 6, aquí verás cómo podrías hacerlo con Docker en un dispositivo sin restricciones. Anteriormente en el capítulo, viste una forma de implementar código en contenedores utilizando Ubuntu Core con un snap a través de Snapcraft. Aquí, simplemente harás una compilación Docker con el dispositivo, lo empujarás a un registro de contenedores Azure y lo desplegarás en un host Linux. Más allá de esto, verás cómo Docker también puede servir de agente, utilizando el proyecto Watchtower, un contenedor Docker que busca actualizaciones y las aplica a tu entorno Docker.

Para ejecutar esto, primero necesitarás una máquina virtual con Ubuntu o una Raspberry Pi con Ubuntu. Puedes utilizar Ubuntu Desktop para esto, pero Ubuntu Server es probablemente el más fácil de configurar y utilizar. Si no quieres molestarte con una máquina virtual local, una máquina virtual de Azure funciona igual de bien. Implementa una máquina virtual de Ubuntu en Azure utilizando la imagen del mercado:

Antes de empezar, necesitarás cierta información del Registro de Contenedores de Azure que se implementó con la plantilla ARM que ejecutaste cuando creaste el Servicio de Aprovisionamiento de Dispositivos y el IoT Hub. Busca tu Registro de Contenedores en el grupo de recursos con tu IoT Hub, navega hasta Claves de Acceso y toma nota de los campos "Nombre de usuario", "Contraseña" y "Servidor de inicio de sesión". Tal vez quieras mantener la pestaña abierta o copiar los valores en un editor de texto.
Una vez que tengas lista tu máquina virtual y estés conectado a ella, obtén acceso root con el comando sudo: sudo -i.
A continuación, instala Docker y sus dependencias. Puedes utilizar el script del repositorio para instalarlo. Utiliza el siguiente comando:
```
bash <(curl -s \ 
    https://raw.githubusercontent.com/theonemule/
        azure-iot-architecture/main/Chapter%203/install-docker.sh)
```
Puedes comprobar la instalación de Docker con docker ps para asegurarte de que todo está bien instalado.
Ahora estás preparado para construir un contenedor. Clona el repositorio de código de GitHub con un comando git:
```
git clone https://github.com/theonemule/azure-iot-architecture.git
```
Esto clonará el código en la carpeta raíz de inicio.
Cambia de directorio al directorio del Capítulo 2:
```
cd azure-iot-architecture/Chapter\ 2
```
Ahora, puedes construir la imagen. Ejecuta el siguiente comando Docker, pero sustituye <loginserver> por el valor de "Servidor de inicio de sesión" del paso 1:
```
docker build -t <loginserver>/device-sample:latest
```
Antes de enviar la imagen, tienes que iniciar sesión en tu Registro de Contenedores Azure con Docker. De nuevo, sustituye <loginserver> por el valor de "Servidor de inicio de sesión" del paso 1:
```
docker login <loginserver>
```
Ahora, puedes empujar la imagen. De nuevo, sustituye <loginserver> por el valor de "Servidor de inicio de sesión" del paso 1. No es necesario empujar el contenedor para ejecutarlo localmente, pero Watchtower comprueba el registro en busca de actualizaciones para poder aplicarlas una vez publicadas:
```
docker push <loginserver>/device-sample:latest
```
Ejecuta el contenedor:
```
docker run --name devicesample -it \
         -e POLLFREQ=7000 <loginserver>/device-sample
```
El contenedor utiliza variables de entorno para configurar el dispositivo. Puedes jugar con estos valores utilizando el parámetro -e seguido de la variable y el valor (es decir, -e POLLFREQ=7000):

COMENZAR

El tipo de conexión. Puede ser "dps", "connection_string" u "offline". "dps" requiere que establezcas PROVISIONINGHOST, IDSCOPE, SYMMETRICKEY y REGISTRATIONID con los valores del Servicio de Aprovisionamiento de Dispositivos, como hiciste en la sección de reclamación y aprovisionamiento. "cadena_de_conexión" requiere que se proporcione una cadena de conexión del dispositivo desde el IoT Hub y que se rellene en CONNSTR. El valor por defecto es "offline".

TELEMETRÍA

Establece "dispositivo" para telemetría real o "simulador" para datos simulados.

CÁMARA

Establece "dispositivo" para la cámara del dispositivo o "simulador" para una cámara simulada. Esto sólo funcionará si la cámara está conectada y mapeada al host, y luego mapeada al contenedor. En caso contrario, utiliza el simulador.

POLLFREQ

Es un valor en milisegundos para la frecuencia con la que quieres que los dispositivos soliciten datos. El valor por defecto es 5000.

CONNSTR

Utilízalo para la cadena de conexión de un dispositivo del IoT Hub para el dispositivo si START está configurado como "cadena_de_conexión".

APROVISIONAMIENTOHOST

Obtén el nombre de host de aprovisionamiento del Servicio de Aprovisionamiento de Dispositivos si START está configurado como "dps".

IDSCOPE

Obtén el ámbito de ID del Servicio de Aprovisionamiento de Dispositivos si START está configurado como "dps".

SYMMETRICKEY

Obtén la clave simétrica del Servicio de Aprovisionamiento de Dispositivos si START está configurado como "dps".

REGISTRATIONID

Crea un ID para tu dispositivo para identificarlo con el Servicio de Aprovisionamiento de Dispositivos .
Una vez que el contenedor esté en marcha, estarás listo para empezar a utilizar Watchtower. Watchtower toma una serie de parámetros que se explican en la documentación. Baste decir que el más relevante es WATCHTOWER_POLL_INTERVAL. Este parámetro establece la frecuencia con la que Watchtower sondeará el registro en busca de cambios. En el siguiente ejemplo, está configurado para cada 60 segundos. En un entorno de producción, puede que quieras comprobarlo con menos frecuencia, quizás una vez al día o una vez cada par de horas:
```
docker run --detach --name watchtower \
   --volume /var/run/docker.sock:/var/run/docker.sock \
   -e WATCHTOWER_DEBUG=true \
   -e WATCHTOWER_NOTIFICATIONS_LEVEL=debug \
   -e WATCHTOWER_CLEANUP=true \
   -e WATCHTOWER_POLL_INTERVAL=60 \
   -e WATCHTOWER_NO_PULL=false \
   -e WATCHTOWER_MONITOR_ONLY=false \
   containrrr/watchtower
```
Observa los tiempos de ejecución actuales del contenedor devicesample y de los contenedores watchtower con docker ps -a. El comando enumera los contenedores en ejecución. En este punto, el contenedor devicesample debería llevar más tiempo en ejecución que el contenedor watchtower.
Ahora, haz un cambio trivial en el código del contenedor. Puedes editar settings.json y añadir una línea al principio del archivo con nano:
```
nano settings.json
```
Cambia el archivo y pulsa Ctrl + O para guardarlo. Pulsa Ctrl + X para salir de nano y volver a la CLI.

Reconstruye el contenedor:

docker build -t <loginserver>/device-sample:latest

Vuelve a empujar el contenedor:

docker push <loginserver>/device-sample:latest

Espera unos minutos. Al cabo de un momento, vuelve a ejecutar docker ps -a. Deberías ver que tu contenedor devicesample se ha reiniciado. Esto se debe a que Watchtower, tu agente de actualización, detectó un cambio en el registro de tu contenedor. A partir de ahí, extrajo la última imagen y reinició tu muestra de dispositivo con la última imagen.

Las actualizaciones de Docker son bastante sencillas . La única discrepancia es que Docker no tiene una forma automática de comprobar si hay nuevos contenedores mientras se están ejecutando. Watchtower desempeña esta función esencial y actúa como agente de actualización de dispositivos para contenedores en tu host Docker.

Las actualizaciones del dispositivo forman parte de la secuencia principal del dispositivo, junto con las actualizaciones de hermanamiento y la mensajería. Una vez que la secuencia principal llega a su fin, un dispositivo acabará fallando o cayendo en la obsolescencia. En cualquier caso, también es bueno tener una estrategia de salida para los dispositivos, como medio para desprovisionar un dispositivo .

Desaprovisionamiento

Ningún dispositivo de durará para siempre. Con el tiempo, un dispositivo se averiará, o el hardware se quedará anticuado hasta el punto de que no pueda ejecutar el software más reciente. No hay ninguna regla sobre cuánto tiempo debe estar en servicio un dispositivo. Algunos aparatos tienen una vida relativamente corta, medida en semanas o incluso días, y otros pueden durar años. Independientemente del tiempo que dure el dispositivo, éste necesita un proceso de desaprovisionamiento para garantizar que se borra y se da de baja.

Desaprovisionar un dispositivo requiere algunos pasos. En primer lugar, si hay claves almacenadas en el dispositivo, estas claves deben ser revocadas. La revocación de las claves garantiza que el dispositivo no podrá conectarse a una plataforma en la nube, ni para intentar enviar y recibir un mensaje, ni para intentar reprovisionarse como un nuevo dispositivo. En segundo lugar, si el dispositivo almacena datos, éstos deben borrarse. Borrar un dispositivo garantiza que los datos residuales que queden en él no puedan extraerse para un uso nefasto o filtrarse accidentalmente.

Azure puede revocar claves sin ningún problema, pero Azure no proporciona servicios específicos que puedan borrar remotamente un dispositivo. Esta funcionalidad debería estar integrada en el dispositivo y ser activable desde la nube al dispositivo.

Por último, como parte del aprovisionamiento del dispositivo, éste necesita una eliminación adecuada . Un plan de fabricación responsable incluye garantizar que el dispositivo se recicle o se elimine de forma segura. Muchos dispositivos contienen sustancias químicas y materiales tóxicos que no deben acabar en los vertederos. La mejor forma de proceder es el reciclaje, que normalmente extrae los componentes reutilizables de un dispositivo, como las pilas, elimina cualquier otro componente con materiales nocivos y se deshace del resto.

Resumen

La gestión del ciclo de vida de los dispositivos es un tema muy amplio, que abarca todo tipo de consideraciones que debes tener en cuenta al fabricar un dispositivo, hasta el punto de que conseguir que un dispositivo realice su función principal puede parecer la parte fácil.

Como has visto, el viaje desde el inicio hasta el desaprovisionamiento comienza con la investigación y el diseño y pasa por la fabricación hasta que, finalmente, se reclama y se envía un dispositivo. A partir de ahí, un dispositivo se aprovisiona y entra en su secuencia primaria, donde se comunica con la nube, recibe actualizaciones y envía y recibe estado a través del hermanamiento. En algún momento (¡como en este capítulo!), finalmente termina. He aquí algunos puntos a tener en cuenta de este capítulo:

La gestión del ciclo de vida de un dispositivo es una parte crucial de su diseño y fabricación. Empieza a pensar en ello mucho antes de construir un dispositivo.
La investigación y el desarrollo es una fase interactiva que lleva el dispositivo desde su concepción hasta un producto mínimamente viable para su fabricación.
Una vez que se envía un dispositivo, necesita una forma de registrarse en la nube. Este proceso es el aprovisionamiento de dispositivos. Azure proporciona el Servicio de Aprovisionamiento de Dispositivos para asociar tu dispositivo a un Hub IoT.
Mientras tus dispositivos están en funcionamiento, necesitan recibir actualizaciones de software y de configuración. Las actualizaciones de configuración se gestionan mediante hermanamiento, y las de software, mediante demonios en el dispositivo que descargan e instalan software.

Tras haberte dotado de los conocimientos esenciales para tomar decisiones cruciales y comprender el apoyo integral de Microsoft en el viaje de creación de dispositivos, este capítulo no hace más que arañar la superficie. Prepárate, ya que el próximo capítulo profundiza en el intrincado funcionamiento de la secuencia principal de un dispositivo, descifrando la intrincada red de detalles de mensajería. Aunque centrado, este debate es un eje, que se entreteje en las operaciones del dispositivo e influye profundamente en cómo los elementos del lado de la nube gestionan las salidas del dispositivo. Tu viaje al corazón de la orquestación de dispositivos continúa. Aún estás en la gestión de dispositivos en el Paisaje IoT, pero no pierdas la oportunidad de desvelar los detalles cruciales que te esperan.

¹ Jeff Prosise, Aprendizaje automático aplicado e IA para ingenieros (O'Reilly, 2022).

Get Arquitectura de soluciones IoT en Azure now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Capítulo 4. El ciclo de vida del dispositivo

Gestión del ciclo de vida de los dispositivos

Figura 4-1. Gestión del ciclo de vida de los dispositivos en el panorama del IoT

Figura 4-2. Gestión del ciclo de vida de los dispositivos

Investigación y diseño

Tres fases de I+D

Figura 4-3. Del diseño a la fabricación

Prueba de concepto

Prototipo

Producto mínimo viable

Hardware

Calcula

Elementos de seguridad

IA y ML

Conectividad

Ethernet

WiFi

Celular

Bluetooth

Otros

Software

Sistemas operativos

Elementos de seguridad

Compatibilidad

Simplicidad

Coherencia

SDKs

Aislamiento de la aplicación

Construir, probar y liberar

Fabricación

Envío

Reclamación y aprovisionamiento

Aprovisiona Dispositivos con un Hub IoT a través del Servicio de Aprovisionamiento de Dispositivos

Secuencia principal

Comunicación

Hermanamiento

Hermanamiento de dispositivos con IoT Hub

Figura 4-4. Base de datos gráfica con nodos y perímetros

Gemelo digital Azure

Azure Cosmos DB

Actualizaciones

Aplicar actualizaciones al dispositivo de muestra en un contenedor Docker

Desaprovisionamiento

Resumen

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly