Componentes para actualizaciones de software basadas en la nube en IoT

La actualización de software (componentes) en dispositivos periféricos restringidos, así como en controladores y puertas de enlace más potentes, es un requisito común en la mayoría de los escenarios de IoT.

Tener capacidades de actualización de software garantiza un IoT seguro al darles a los proyectos de IoT una oportunidad de luchar contra la caja de Pandora, se abrieron en el momento en que sus dispositivos se se conectaron . A partir de ese momento, los dispositivos están a la vanguardia de las amenazas de seguridad de TI, que, históricamente, muchos desarrolladores de software integrado nunca tuvieron que enfrentar. En estos días, enviar, digamos, un dispositivo conectado a la web con tecnología Linux sin que se hayan aplicado actualizaciones de seguridad durante su vida útil es similar a un suicidio.

Un argumento más encantador para las actualizaciones de software es que permiten un desarrollo ágil de hardware y componentes relacionados con el hardware. Se pueden aplicar conceptos como el producto mínimo viable a los dispositivos, ya que no es necesario que todas las funciones estén listas en el momento de la fabricación. Los cambios en el lado de la nube de la solución de IoT también se pueden aplicar a los dispositivos en tiempo de ejecución.

A veces, la actualización de software es un modelo de negocio por derecho propio, ya que los dispositivos son mucho más atractivos para el cliente si se pueden actualizar. En otras palabras, los consumidores saben que no solo obtienen un conjunto fijo de funciones, sino que también pueden esperar beneficiarse de futuras actualizaciones de productos. Además, pueden surgir nuevas fuentes de ingresos de la posible monetización de las extensiones de funciones (p. Ej., aplicaciones ) sin necesidad de diseñar, fabricar y enviar un nuevo dispositivo (revisión).

Conectividad del dispositivo

Hay varias opciones para conectar un dispositivo a un servicio en la nube. Desde una perspectiva arquitectónica, se debe decidir si los dispositivos deben conectarse directamente al servicio de actualización de software o indirectamente a través de una capa de conectividad de dispositivo (por ejemplo, Bosch IoT Hub, AWS IoT, IBM Watson IoT, Azure IoT Hub, etc.), que en sí mismo también podría ser un servicio de solución de IoT. Yo mismo creo firmemente en el enfoque directo, y mi producto Bosch IoT Rollouts es compatible con ambos. Explicaré por qué a continuación.

Así que comencemos:la conectividad directa permitirá que las soluciones de IoT tengan una separación de preocupaciones al tener distintos canales para las actualizaciones de software además de su propio canal que las soluciones de IoT usan para los flujos y comandos de eventos del dispositivo.

Este es un enfoque interesante por dos razones: primero, hace que sea mucho más fácil mantener estable la API del canal de actualización de software si no tiene que preocuparse por todos los requisitos comerciales del otro canal . No debemos olvidar que hay escenarios en el IoT en los que los dispositivos conectados pueden pasar períodos prolongados sin contacto con el backend. En algunos casos pueden pasar años, especialmente entre la fabricación y la conectividad inicial. Mantener una capa de transporte estable durante ese período de tiempo es fácil, pero ciertamente no es el caso de la capa empresarial. Esto es especialmente cierto en IoT, donde muchas soluciones en la nube aún se encuentran en las primeras fases de madurez.

En segundo lugar, tener un canal separado también le permite tener una separación de la funcionalidad comercial y de actualización en el dispositivo mismo . Especialmente en una pila compleja (por ejemplo, en una puerta de enlace de IoT), ¿realmente desea arriesgarse a que una pila potencialmente rota tenga que actualizarse para solucionar el problema? ¿Y se puede garantizar que siempre podrá hacer eso? Imagine un escenario en el que tiene un tiempo de ejecución OSGi en su puerta de enlace con un paquete que causa excepciones de memoria insuficiente y su cliente de actualización de software se ejecuta en el mismo tiempo de ejecución. Podría ser muy difícil predecir el resultado.

Sin embargo, la separación tiene un precio:dos canales generalmente significan un mayor esfuerzo de implementación en el lado del dispositivo y, en algunos escenarios, también puede aumentar el consumo de tráfico o la duración de la batería.

La segunda opción es combinar los casos de uso en un solo canal. A esto lo llamamos indirecto integración con el servicio de actualización de software, ya que la capa de conectividad en la nube está realmente conectada al dispositivo y tiene que dividir la solución del tráfico de actualización en la nube.

Esto tiene el gran beneficio de una arquitectura de conectividad simplificada. También permite aprovechar los estándares de protocolo de administración de dispositivos de propósito general (por ejemplo, LWM2M, OMA-DM, TR-069), que generalmente incluyen actualizaciones de software solo como una subsección de sus estándares. Además, permite el uso de protocolos propietarios que son definidos por el propio dispositivo (fabricante).

Al final del día, el ingeniero de soluciones de IoT tiene que tomar una decisión:separación de preocupaciones versus simplicidad. Con nuestros despliegues de Bosch IoT, hemos decidido admitir ambas opciones y tenemos clientes que utilizan ambas. La conectividad directa resultó ser mucho más fácil de mantener para la solución de IoT, mientras que la conectividad indirecta agrega mucha complejidad a la arquitectura general.

Sin embargo, la mayoría de los ingenieros de IoT incluyen problemas de actualización de software en su proceso de diseño muy tarde en el proyecto, ya que en la mayoría de los casos no es parte de la función central del negocio y, cuando llegan a ella, no quieren hacer más cambios. a su arquitectura. Como resultado, la mayoría de las soluciones adoptan un enfoque indirecto y pueden sufrir las consecuencias después de la puesta en funcionamiento.

La segunda decisión para las actualizaciones de software basadas en la nube en IoT se relaciona con el protocolo. ¿Debería optar por un protocolo de gestión de dispositivos estándar o diseñar uno personalizado? Muchas soluciones de IoT en estos días favorecen MQTT con un protocolo personalizado en la parte superior. Además, muchas de las capas de conectividad de IoT en el mercado también ofrecen un protocolo propietario además de HTTP, MQTT o AMQP.

Personalmente, creo que algunos de los estándares tienen valor y al menos deberían tenerse en cuenta. OMA-DM v2 parece prometedor y también hemos tenido algo de experiencia con LWM2M. Como siempre, los estándares ofrecen un buen marco, pero generalmente vienen con un conjunto de restricciones; especialmente en las primeras etapas de un proyecto de IoT, esto puede agregar mucha complejidad. Sin embargo, un buen estándar que cubra las actualizaciones de software permitirá que la solución de IoT tenga actualizaciones de software como una función sin la necesidad de escribir ni siquiera una línea de código si tanto el dispositivo como el servicio de actualización de software lo admiten.

Por último, pero no menos importante, está la cuestión de la autenticación del dispositivo. Esta es, por supuesto, una pregunta general para todas las soluciones de IoT. Pero especialmente para la ruta de integración directa, se debe elegir si se puede usar el mismo mecanismo de autenticación para las actualizaciones de software y el canal de la solución de IoT. Por lo general, abogo por utilizar el mismo mecanismo. Esto es realmente fácil de implementar con autenticación asimétrica (por ejemplo, certificado X.509). Bosch IoT Rollouts admite esto para su API de integración directa de dispositivos, así como para la mayoría de las capas de conectividad que se utilizan normalmente en IoT. Si asimétrico no es una opción (que suele ser el caso de los dispositivos integrados restringidos), recomendaría optar por un almacén de claves central (simétrico) que pueda ser utilizado por los diferentes canales.

Como se señaló anteriormente, hay opciones que deben tomarse y preguntas que deben responderse. Desafortunadamente, IoT aún no se encuentra en un estado en el que hayamos encontrado una arquitectura que se ajuste al menos a la mayoría de los escenarios. Sin embargo, la buena noticia es que existen opciones y que funcionan.