Seguimiento de software en dispositivos implementados en el campo

El rastreo de software es una herramienta importante en la caja de herramientas de todos los desarrolladores integrados, especialmente cuando se combina con visualización avanzada. La mayoría de los sistemas integrados tienen muchos patrones cíclicos, donde la misma secuencia se repite una y otra vez. Al depurar, a menudo desea encontrar las anomalías, es decir, desviaciones del comportamiento cíclico normal donde sucedió algo fuera de lo común.

Sin embargo, el rastreo de software en sí mismo es solo una forma de recopilación de datos. Buscar un problema en un tesoro de datos de registro textuales o numéricos es similar a buscar una aguja en un pajar, pero con una visualización adecuada, la búsqueda se transforma en un problema de reconocimiento visual de patrones, algo para lo que el cerebro humano está particularmente bien equipado. . Gráficos interactivos que muestran los tiempos de ejecución, los tiempos de respuesta, los cambios de tareas, el paso de mensajes entre tareas:todo esto permite al desarrollador detectar rápidamente anomalías en la ejecución de su firmware, dónde profundizar.

Las herramientas para el diagnóstico de trazas visuales existen desde hace al menos una década y han demostrado ser útiles para el desarrollo y la depuración en el laboratorio. Con cada vez más desarrolladores de software integrado que agregan conectividad segura en la nube de "Internet de las cosas", es bastante natural considerar el uso del rastreo en los dispositivos implementados en el campo, para capturar problemas del mundo real que se pasaron por alto durante las pruebas. Después de todo, el rastreo basado en software no requiere ningún hardware adicional y un dispositivo IoT conectado es obviamente capaz de cargar datos de rastreo de diagnóstico, de la misma manera que los datos de aplicaciones normales. De esta manera, los desarrolladores pueden darse cuenta rápidamente de cualquier problema de software restante que cause problemas durante la operación en el mundo real y también obtener diagnósticos detallados para comprender la causa.

En este escenario, el rastreo de software es comparable a un "registrador de vuelo" virtual, como los que se utilizan en los aviones de pasajeros en caso de accidentes. Es una parte integrada del producto que siempre está grabando, proporcionando información vital en caso de un problema. Pero a diferencia de las cajas registradoras de vuelo reales, es una solución de software y está pensada para problemas de software.

Una solución para este tipo de monitoreo de dispositivos de IoT es DevAlert de Percepio (figura 1), que consta de tres partes:un monitor de firmware, una pequeña biblioteca que agrega a su firmware para permitir el seguimiento y la carga de alertas; nuestra herramienta Tracealyzer para diagnósticos de trazas visuales; y un servicio en la nube, responsable de categorizar y almacenar alertas, notificar a los desarrolladores, filtrar alertas duplicadas y más.

Figura 1. Percepio DevAlert proporciona a los desarrolladores de IoT comentarios instantáneos sobre los errores en sus dispositivos conectados a la nube, lo que permite una mejora rápida y continua del software del dispositivo.
(Haga clic en la imagen para ampliarla)

La versión inicial se ejecuta en AWS y está diseñada para aplicaciones RTOS que utilizan AWS IoT core, pero la solución se puede adaptar para otras plataformas en la nube.

Seguimiento de software y conectividad en la nube
El seguimiento en el laboratorio de desarrollo y el seguimiento de los dispositivos implementados son dos cosas diferentes. Si actualmente utiliza diagnósticos de rastreo visual en el laboratorio y desea expandirlo al campo, hay algunas cosas que debe considerar.

En comparación con una conexión física directa como USB o Ethernet, una conexión en la nube ofrece un ancho de banda limitado y tiempos de respuesta mucho más largos. La carga de 5 KB de datos puede requerir decenas o cientos de milisegundos a través de una interfaz inalámbrica. Sin embargo, en este enfoque, las trazas no se transmiten continuamente, sino solo cuando se genera una alerta y solo una pequeña traza de los eventos más recientes. Las alertas solo están destinadas a cosas inusuales pero importantes, por ejemplo, si se ha detectado un error en el código de la aplicación, como una verificación de cordura fallida, una falla grave o un reinicio del perro guardián.

Cualquier dispositivo conectado a Internet debe ser seguro. Por tanto, es importante no introducir nuevos vectores de ataque. Resolvemos esto en DevAlert confiando en la conectividad en la nube existente en lugar de introducir una nueva conexión. Esto aprovecha la seguridad de AWS y otros proveedores líderes de IoT / nube, que ofrecen SDK verificados para la conectividad en la nube que están asegurados de acuerdo con las mejores prácticas, como la autenticación de dispositivos mediante certificados X.509 y la comunicación cifrada mediante TLS. Esto haría que las cargas de DevAlert sean tan seguras como los datos de aplicaciones de IoT normales y, para mayor seguridad, solo necesita comunicación unidireccional:nunca escucha los mensajes entrantes.

En este enfoque, las alertas se cargan en la misma cuenta en la nube que utiliza normalmente el dispositivo y con el mismo nivel de seguridad. Una vez en la nube, una pequeña parte de los datos se proporciona al servicio en la nube. Esto no incluye los datos de seguimiento reales, que pueden considerarse información confidencial y, por lo tanto, permanecen en la cuenta en la nube del dispositivo. Las figuras 2a y 2b muestran el flujo de datos y las barreras de seguridad con más detalle.

Figura 2a. El flujo de datos comienza en el software del dispositivo, donde los desarrolladores agregan alertas al código fuente. Cada alerta que se carga en la cuenta de la nube del dispositivo incluye un breve seguimiento con los eventos más recientes que preceden a la alerta. Finalmente, se envía una firma de metadatos al servicio en la nube DevAlert. (Haga clic en la imagen para ampliar)

Figura 2b. El servicio en la nube compara las alertas entrantes con las alertas anteriores de toda la flota de dispositivos del cliente y notifica a los desarrolladores sobre cualquier problema nuevo. Las alertas duplicadas se cuentan y almacenan, pero no se envían notificaciones. De esta forma, las bandejas de entrada de los desarrolladores no se inundan si se activa la misma alerta en varios dispositivos. (Haga clic en la imagen para ampliar)

Los costos operativos para recibir alertas en una cuenta en la nube suelen ser bajos, aunque, naturalmente, dependen del volumen. Para empezar, mientras no se detecten problemas, no se envían alertas. En general, los proveedores de la nube también cobran muy poco por enviar y almacenar mensajes de alerta ocasionales. La mayoría de las aplicaciones de IoT generan muchos más datos, lo que se refleja en el precio de los servicios de IoT / en la nube. Por ejemplo, enviar 1 millón de mensajes MQTT al núcleo de AWS IoT cuesta 1 dólar.

La mayor parte del procesamiento de alertas se realiza en el servicio en la nube, un servicio totalmente administrado alojado por Percepio. Solo el procesamiento inicial se realiza en la cuenta en la nube del desarrollador del dispositivo, lo que mantiene bajos los costos de la nube y simplifica la integración.

El envío de actualizaciones inalámbricas para corregir los errores informados puede costar un poco más, ya que necesita transferir muchos más datos a todos los dispositivos. AWS proporciona un ejemplo de precios en el que el costo de actualizar una flota de 600.000 dispositivos es de 1.275 dólares estadounidenses. Sin embargo, esto no es muy costoso en relación con el costo de dejar que un error permanezca sin corregir:experiencia del cliente dañada, calificaciones más bajas de reseñas de productos, ventas más bajas o incluso accidentes y acciones legales.

DevOps para desarrollo integrado
Permitir que sus dispositivos de IoT "llamen a casa" en caso de problemas de software tiene una ventaja significativa. El conocimiento directo de los errores y los diagnósticos detallados crean un circuito de retroalimentación entre los desarrolladores y el código implementado, lo que permite a los desarrolladores corregir errores más rápido y enviar el firmware actualizado más rápido; consulte la Figura 3. Esta llamada filosofía DevOps ha sido durante mucho tiempo el estándar en el desarrollo de dispositivos móviles y aplicaciones en la nube, y con la introducción de plataformas de IoT seguras basadas en la nube, el desarrollo integrado también puede funcionar de esta manera.

Figura 3. El panel de DevAlert en Tracealyzer enumera las alertas y los seguimientos notificados más recientes.
(Haga clic en la imagen para ampliar)

Desde una perspectiva empresarial, este monitoreo estilo DevOps se traduce en menos clientes insatisfechos, ya que menos usuarios finales se verán afectados por errores en el código de producción. La mayoría del software integrado contiene algunos errores perdidos en el lanzamiento, a pesar de todos los esfuerzos de verificación, pero por lo general no se muestran directamente para todos. A menudo, hay algo de tiempo para solucionar el problema antes de que muchos clientes se vean afectados, si lo sabe con anticipación. Idealmente, los desarrolladores deben ser notificados en cuestión de segundos después de la primera alerta y los diagnósticos de seguimiento proporcionados permiten un análisis y una corrección rápidos. Los desarrolladores pueden enviar una actualización automática por aire para solucionar el problema. La detección instantánea y los diagnósticos de rastreo pueden reducir en gran medida el tiempo de reparación y minimizar la cantidad de clientes afectados.

La confiabilidad mejorada del dispositivo reduce los riesgos de responsabilidad y también reduce los costos de soporte al cliente, devoluciones y depuración. Los diagnósticos proporcionados hacen que sea mucho más fácil para los desarrolladores reproducir los problemas de los clientes, ya que obtienen información directamente del dispositivo y no tienen que depender del usuario para describir las circunstancias. Sin comentarios automáticos, confía en sus usuarios finales para informar cualquier problema y proporcionar información suficientemente detallada. Un informe de error vago como "el sistema deja de responder" no es muy útil y puede llevar semanas encontrar una causa probable. E incluso entonces, es tu mejor suposición:realmente no puedes saber si resolviste el problema correcto.

No solo errores
Una cosa a tener en cuenta es que las alertas no tienen que ser solo sobre errores perdidos y los errores resultantes. Dado que los desarrolladores son libres de decidir dónde y por qué se deben generar las alertas, también podrían usarlas para monitorear las métricas clave de rendimiento de la aplicación y ver el motivo de problemas ocasionales de rendimiento.

La supervisión de la interfaz de usuario también puede revelar información interesante. Supongamos que tiene una situación en la que el usuario abre un menú en una pantalla táctil, p. Ej. en los sistemas de información y entretenimiento de un automóvil, y luego duda dónde proceder. Para detectar estos problemas, el desarrollador de la aplicación puede iniciar un temporizador después de cada evento de entrada y generar una alerta si no se recibe ninguna entrada en, digamos, 5 segundos. Si luego se reciben muchas alertas sobre la misma parte de la interfaz de usuario, estos pueden ser comentarios importantes que pueden ayudar a su organización a crear mejores productos.

En general, aprovechar el seguimiento de software y las alertas basadas en la nube en los dispositivos implementados tiene grandes beneficios y no es complicado. Sin embargo, para adoptar completamente un flujo de trabajo estilo DevOps requiere capacidad para actualizaciones inalámbricas y una organización de desarrollo receptiva que comprenda las limitaciones de las pruebas de software y la importancia de la mejora continua también después del lanzamiento.