Desvendando problemas ocultos: reais

Jacó do Benin | 30 de agosto de 2023

Hoje, um dos recursos mais subestimados no desenvolvimento de software embarcado é o rastreamento de uma aplicação de sistema operacional em tempo real (RTOS). Os RTOSs chegaram a quase todos os dispositivos IoT e a muitos dispositivos desconectados. Quando os desenvolvedores testam seus sistemas, eles geralmente observam o comportamento externo do sistema para avaliar se ele funciona corretamente. O problema com esta abordagem é que muitos sistemas têm comportamentos que devem ocorrer de forma determinística em escalas de tempo inferiores a 50 milissegundos. Sem rastreamento, você pode acreditar que o sistema está funcionando, apenas para descobrir, quando estiver nas mãos de seus clientes, que ele apresenta falhas e não funciona corretamente em todas as circunstâncias. Nesta postagem, mostrarei alguns recursos de rastreamento e compartilharei exemplos de como identifiquei problemas que podem não ter sido descobertos até que os dispositivos estivessem em campo.

Antes de examinarmos alguns exemplos específicos, é útil entender como rastrear uma aplicação RTOS. Normalmente, há duas partes: uma biblioteca de gravadores que rastreia eventos no aplicativo RTOS no destino e uma GUI de visualização que recebe e exibe os dados do evento. Diversas ferramentas permitem que os desenvolvedores capturem esses dados, como Percepio Tracealyzer, SEGGER SystemView e Microsoft Azure RTOS TraceX. Existem muitas outras, mas a ferramenta que você usará dependerá do RTOS que você está usando e de suas necessidades de visualização.

Geralmente, você instalaria a biblioteca do gravador de rastreio de ferramentas, que geralmente cria uma tarefa de rastreio. Esta tarefa de baixa prioridade pega os dados do evento gravado e os transmite para o aplicativo host (pelo menos em modo de streaming). Menciono isso porque quando você instrumenta seu código dessa forma, é importante observar que ciclos extras de CPU serão dedicados ao registro dos dados de rastreamento. Nas minhas experiências com essas ferramentas, a sobrecarga é tão mínima que você nem percebe (pelo menos em qualquer aplicativo em que trabalhei). É importante saber para decidir se você deixará o gravador de rastreamento em seu firmware de lançamento. Caso contrário, teste e valide seu aplicativo com o firmware de lançamento!

Recentemente treinei uma equipe de engenheiros que iniciou testes de validação em seus produtos. Eles realizaram os testes e acreditaram que o sistema estava funcionando perfeitamente. Eles me disseram que seu sistema estava pronto para ser enviado; eles viram um pequeno problema com o tempo de telemetria do sistema – nada demais. Na minha experiência, não existe problema menor. Problemas menores geralmente são a ponta do iceberg que se transformam em problemas titânicos quando chegam às mãos do cliente. Então, configuramos o Percepio Tracealyzer para rastrear o aplicativo e ver como o sistema estava funcionando perfeitamente.

Se você observar a Figura 1 abaixo, poderá ver uma representação da utilização da CPU do sistema. Cada cor no diagrama representa uma tarefa diferente. O eixo x é o tempo e o eixo y é a utilização da CPU. Isso parece um sistema validado e pronto para chegar às mãos dos clientes?

Figura 1. Um exemplo de gráfico de utilização da CPU em que a carga da CPU atinge 100% o tempo todo.

Infelizmente, o sistema em questão utilizava 100% da CPU. Após uma análise mais detalhada, constatou-se que não cumpria prazos críticos e não funcionava de forma determinística. A observação humana foi inútil para descobrir esses problemas através do rastreamento da aplicação. Se o produto fosse enviado assim, os clientes teriam problemas. Seguindo alguns traços simples, poderíamos ver um problema e remediar a situação. Indo um pouco mais fundo, identificamos algumas pequenas causas que levaram menos de meio dia para serem corrigidas, e a utilização resultante da CPU passou da Figura 1 para algo como a Figura 2.

Figura 2. Um exemplo de gráfico de utilização de CPU mais adequado para um sistema de produção.

A utilização aprimorada da CPU é muito menor e deixa espaço para adicionar recursos futuros e garantir que o cliente tenha um sistema que possa responder e cumprir seus prazos.

O rastreamento RTOS não detecta apenas problemas com o desempenho da CPU. Ele funciona como um osciloscópio para software! Quando os threads são visualizados, você pode identificar diferentes padrões em seu sistema e identificar inconsistências. O resultado é que você pode encontrar problemas como inversões de prioridade, impasses e falta de tarefas. Vejamos um exemplo.