Descubriendo problemas ocultos: reales

Jacob de Benín | 30 de agosto de 2023

Hoy en día, una de las capacidades más subestimadas en el desarrollo de software integrado es el seguimiento de una aplicación de sistema operativo en tiempo real (RTOS). Los RTOS han llegado a casi todos los dispositivos IoT y a muchos dispositivos desconectados. Cuando los desarrolladores prueban sus sistemas, a menudo observan el comportamiento del sistema externo para evaluar si funciona correctamente. El problema con este enfoque es que muchos sistemas tienen comportamientos que deben ocurrir de manera determinista en escalas de tiempo de menos de 50 milisegundos. Sin seguimiento, usted podría creer que el sistema está funcionando, sólo para descubrir, cuando está en manos de sus clientes, que tiene fallas y no funciona correctamente en todas las circunstancias. En esta publicación, lo guiaré a través de algunas capacidades de rastreo y compartiré ejemplos de cómo detecté problemas que tal vez no se descubrieron hasta que los dispositivos estuvieron en el campo.

Antes de ver algunos ejemplos específicos, resulta útil comprender cómo rastrear una aplicación RTOS. Normalmente, hay dos partes: una biblioteca de grabación que rastrea eventos en la aplicación RTOS en el destino y una GUI de visualización que recibe y muestra los datos del evento. Varias herramientas permiten a los desarrolladores capturar estos datos, como Percepio Tracealyzer, SEGGER SystemView y Microsoft Azure RTOS TraceX. Hay muchos otros, pero la herramienta que utilice dependerá del RTOS que esté utilizando y de sus necesidades de visualización.

Por lo general, instalaría la biblioteca de registro de seguimiento de herramientas, que a menudo crea una tarea de seguimiento. Esta tarea de baja prioridad toma los datos del evento grabado y los transmite a la aplicación host (al menos en modo de transmisión). Menciono esto porque cuando instrumentas tu código de esta manera, es importante tener en cuenta que se dedicarán ciclos adicionales de CPU a registrar los datos de seguimiento. En mi experiencia al usar estas herramientas, la sobrecarga es tan mínima que no la notas (al menos en cualquier aplicación en la que haya trabajado). Es importante saberlo para decidir si dejará el registrador de seguimiento en su versión de firmware. Si no lo hace, pruebe y valide su aplicación con el firmware de su versión.

Recientemente entrené a un equipo de ingenieros que habían comenzado las pruebas de validación de su producto. Hicieron sus pruebas y creyeron que su sistema funcionaba sin problemas. Me dijeron que su sistema estaba listo para enviarse; vieron un problema menor con la sincronización de telemetría de su sistema, no es gran cosa. En mi experiencia, no existen problemas menores. Los problemas menores suelen ser la punta del iceberg que se convierten en problemas titánicos cuando llegan a manos del cliente. Entonces, configuramos Percepio Tracealyzer para rastrear la aplicación y ver cómo funcionaba su sistema sin problemas.

Si observa la Figura 1 a continuación, puede ver una representación de la utilización de la CPU del sistema. Cada color en el diagrama es una tarea diferente. El eje x es el tiempo y el eje y es la utilización de la CPU. ¿Parece un sistema validado listo para llegar a manos de los clientes?

Figura 1. Un ejemplo de gráfico de utilización de CPU donde la carga de la CPU alcanza el 100% todo el tiempo.

Desafortunadamente, el sistema en cuestión utilizaba el 100% de la CPU. Tras un examen más detenido, no cumplía plazos críticos y no operaba de manera determinista. La observación humana fue inútil para descubrir estos problemas al rastrear la aplicación. Si el producto se hubiera enviado así, los clientes habrían tenido problemas. Al tomar algunas pistas simples, podemos ver un problema y remediar la situación. Profundizando un poco más, identificamos algunas causas pequeñas que tardaron menos de medio día en solucionarse, y la utilización de CPU resultante pasó de la Figura 1 a algo así como la Figura 2.

Figura 2. Un ejemplo de gráfico de utilización de CPU más adecuado para un sistema de producción.

La utilización mejorada de la CPU es mucho menor y deja margen para agregar funciones futuras y garantizar que el cliente tenga un sistema que pueda responder y cumplir con sus plazos.

El seguimiento de RTOS no sólo detecta problemas con el rendimiento de la CPU. ¡Actúa como un osciloscopio para software! Cuando se visualizan los hilos, puede detectar diferentes patrones en su sistema e identificar inconsistencias. El resultado es que puede encontrar problemas como inversiones de prioridad, interbloqueos y falta de tareas. Veamos un ejemplo.

Después de solucionar el problema de utilización de la CPU, surgió la tentación de celebrar. El sistema se veía bien, ¿verdad? El hecho de que la utilización de su CPU parezca buena no significa que todos los subprocesos se estén comportando correctamente. Después de examinar los informes y seguimientos del desempeño de las tareas, noté algo interesante. Una de las tareas (amarilla) que se suponía que debía ejecutarse periódicamente no lo fue. Se ejecutaría tres veces casi correctamente, haría una pausa larga y luego se reanudaría, como se muestra en la Figura 3.

Figura 3. Las vistas de tareas pueden revelar inconsistencias en la periodicidad de las tareas, como se ve en la tarea amarilla.

Usando la herramienta de seguimiento, resultó que había una variación del 50% en la periodicidad de la tarea. ¿Un humano notaría esto sin rastrearlo? No. ¿Afectaría el funcionamiento de este sistema y causaría problemas en el campo? ¡Sí! Una vez más, después de ver el problema, ¡nos tomó menos de una hora localizarlo y resolverlo! Sin embargo, sin la herramienta de rastreo, el producto habría entrado en funcionamiento, habría tenido problemas y habría generado clientes enojados y ciclos de depuración potencialmente largos al tratar de identificar la causa raíz.

Si está escribiendo una aplicación que utiliza un RTOS, debe rastrear su aplicación. No deberías rastrearlo justo antes de que llegue a manos de tus clientes, sino a lo largo de todo el ciclo de desarrollo. Si puede detectar un cambio de software que causa un problema de inmediato, puede solucionarlo rápidamente y ahorrar tiempo y dinero al intentar encontrarlo más adelante en el ciclo de desarrollo. Realmente no puedes entender lo que está haciendo tu sistema hasta que lo rastreas, y solo entonces puedes determinar si se está comportando como crees que debería. He estado usando herramientas de rastreo durante media década o más, y no puedo decir cuántas veces me han ayudado a detectar problemas que de otra manera no habría detectado. Al igual que las pruebas unitarias, el rastreo me parece una herramienta indispensable y creo que usted también lo será.

Más información sobre formatos de texto