Rastreamento de software em dispositivos implantados em campo

O rastreamento de software é uma ferramenta importante na caixa de ferramentas de cada desenvolvedor incorporado, especialmente quando combinado com a visualização avançada. A maioria dos sistemas embarcados tem muitos padrões cíclicos, nos quais a mesma sequência se repete indefinidamente. Ao depurar, muitas vezes você deseja encontrar as anomalias, ou seja, desvios do comportamento cíclico normal onde algo fora do comum aconteceu.

No entanto, o rastreamento de software em si é apenas uma forma de coleta de dados. Procurar um problema em um tesouro de dados de log textuais ou numéricos é semelhante a procurar uma agulha em um palheiro, mas com a visualização adequada, a busca é transformada em um problema de reconhecimento de padrão visual, algo que o cérebro humano está particularmente bem equipado para fazer . Gráficos interativos mostrando tempos de execução, tempos de resposta, troca de tarefas, troca de mensagens entre tarefas - tudo isso permite que um desenvolvedor localize rapidamente anomalias na execução de seu firmware, onde se aprofundar.

As ferramentas para diagnóstico de traços visuais já existem há pelo menos uma década e provaram ser úteis para desenvolvimento e depuração em laboratório. Com mais e mais desenvolvedores de software incorporado adicionando conectividade em nuvem "internet das coisas" segura, é bastante natural considerar o uso de rastreamento em dispositivos implantados no campo, a fim de capturar problemas do mundo real que foram perdidos durante o teste. Afinal, o rastreamento baseado em software não requer nenhum hardware adicional e um dispositivo IoT conectado obviamente é capaz de carregar dados de rastreamento de diagnóstico, da mesma forma que os dados de aplicativo normais. Dessa forma, os desenvolvedores podem se tornar rapidamente cientes de quaisquer problemas de software remanescentes que causem problemas durante a operação no mundo real e também obter diagnósticos detalhados para entender a causa.

Nesse cenário, o rastreamento de software é comparável a um “gravador de vôo” virtual, como os usados ​​em aviões de passageiros em caso de acidentes. É uma parte integrante do produto que está sempre gravando, fornecendo informações vitais em caso de algum problema. Mas, ao contrário das caixas de gravador de vôo reais, é uma solução de software e destinada a problemas de software.

Uma solução para esse tipo de monitoramento de dispositivo IoT é o DevAlert da Percepio (figura 1), que consiste em três partes:um monitor de firmware, uma pequena biblioteca que você adiciona ao seu firmware para permitir o rastreamento e upload de alertas; nossa ferramenta Tracealyzer para diagnóstico de traços visuais; e um serviço de nuvem, responsável por categorizar e armazenar alertas, notificar desenvolvedores, filtrar alertas duplicados e muito mais.

Figura 1. O Percepio DevAlert fornece aos desenvolvedores de IoT feedback instantâneo sobre erros em seus dispositivos conectados à nuvem, permitindo a melhoria contínua rápida do software do dispositivo.
(Clique na imagem para ampliar)

A versão inicial é executada em AWS e se destina a aplicativos RTOS usando o núcleo AWS IoT, mas a solução pode ser adaptada para outras plataformas de nuvem.

Rastreamento de software e conectividade em nuvem
Rastrear no laboratório de desenvolvimento e rastrear dispositivos implantados são duas coisas diferentes. Se você está usando o diagnóstico de rastreamento visual no laboratório hoje e pretende expandi-lo para o campo, existem algumas coisas que você precisa pensar.

Comparada a uma conexão física direta como USB ou Ethernet, uma conexão em nuvem oferece largura de banda limitada e tempos de resposta muito mais longos. Carregar, digamos, 5 KB de dados pode exigir dezenas ou centenas de milissegundos em uma interface sem fio. No entanto, nesta abordagem, os rastreamentos não são transmitidos continuamente, mas apenas quando um alerta é gerado e apenas um pequeno rastreamento dos eventos mais recentes. Os alertas destinam-se apenas a coisas incomuns, mas importantes, por exemplo, se um erro foi detectado no código do aplicativo, como uma falha na verificação de integridade, falha de hardware ou redefinição do watchdog.

Qualquer dispositivo conectado à Internet precisa ser seguro. Portanto, é importante não introduzir nenhum novo vetor de ataque. Resolvemos isso no DevAlert contando com a conectividade existente na nuvem, em vez de introduzir uma nova conexão. Isso alavanca a segurança da AWS e de outros provedores líderes de IoT / nuvem, que oferece SDKs verificados para conectividade em nuvem que são protegidas de acordo com as melhores práticas, como autenticação de dispositivo usando certificados X.509 e comunicação criptografada usando TLS. Isso tornaria os uploads do DevAlert tão seguros quanto os dados do aplicativo IoT normais e, para aumentar a segurança, ele só precisa de comunicação unilateral:nunca escuta as mensagens de entrada.

Nessa abordagem, os alertas são carregados para a mesma conta na nuvem normalmente usada pelo dispositivo e com o mesmo nível de segurança. Uma vez na nuvem, uma pequena parte dos dados é fornecida ao serviço em nuvem. Isso não inclui os dados de rastreamento reais, que podem ser considerados informações confidenciais e, portanto, permanecem na conta de nuvem do dispositivo. As Figuras 2a e 2b mostram o fluxo de dados e as barreiras de segurança em mais detalhes.

Figura 2a. O fluxo de dados começa no software do dispositivo, onde os desenvolvedores adicionam alertas ao código-fonte. Cada alerta que é carregado para a conta de nuvem do dispositivo inclui um pequeno rastreamento com os eventos mais recentes anteriores ao alerta. Finalmente, uma assinatura de metadados é encaminhada para o serviço de nuvem DevAlert. (Clique na imagem para ampliar)

Figura 2b. O serviço de nuvem compara os alertas recebidos com os alertas anteriores de toda a frota de dispositivos do cliente e notifica os desenvolvedores sobre quaisquer novos problemas. Os alertas duplicados são contados e armazenados, mas nenhuma notificação é enviada. Dessa forma, as caixas de entrada dos desenvolvedores não são inundadas se o mesmo alerta for disparado em vários dispositivos. (Clique na imagem para ampliar)

Os custos operacionais para receber alertas em uma conta na nuvem são normalmente baixos, embora dependam naturalmente do volume. Para começar, enquanto nenhum problema for detectado, nenhum alerta será enviado. Em geral, os provedores de nuvem também cobram muito pouco pelo envio e armazenamento de mensagens de alerta ocasionais. A maioria dos aplicativos de IoT gera muito mais dados, o que se reflete no preço dos serviços de IoT / nuvem. Por exemplo, o envio de 1 milhão de mensagens MQTT para o núcleo AWS IoT custa US $ 1.

A maior parte do processamento de alertas é feita no serviço de nuvem, um serviço totalmente gerenciado hospedado pela Percepio. Apenas o processamento inicial é feito na conta da nuvem do desenvolvedor do dispositivo, o que mantém os custos da nuvem baixos e simplifica a integração.

O envio de atualizações over-the-air para corrigir os erros relatados pode custar um pouco mais, já que você precisa transferir muito mais dados e para todos os dispositivos. A AWS fornece um exemplo de preço em que o custo de atualização de uma frota de 600.000 dispositivos é de US $ 1.275. No entanto, isso não é muito caro em relação ao custo de deixar um bug permanecer sem correção - experiência do cliente danificada, avaliações mais baixas de revisão do produto, vendas mais baixas ou até mesmo acidentes e ações legais.

DevOps para desenvolvimento incorporado
Habilitar seus dispositivos IoT para "telefonar para casa" em caso de problemas de software tem uma vantagem significativa. A percepção direta de erros e diagnósticos detalhados criam um ciclo de feedback entre os desenvolvedores e o código implantado, permitindo que os desenvolvedores corrijam bugs mais rápido e forneçam firmware atualizado com mais rapidez - consulte a Figura 3. Essa assim chamada filosofia DevOps tem sido o padrão no desenvolvimento de dispositivos móveis e aplicativos em nuvem, e com a introdução de plataformas IoT seguras baseadas em nuvem, tornou-se possível para o desenvolvimento integrado funcionar dessa maneira também.

Figura 3. O painel DevAlert no Tracealyzer lista os alertas e rastreamentos relatados mais recentes.
(Clique na imagem para ampliar)

De uma perspectiva de negócios, esse monitoramento no estilo DevOps se traduz em menos clientes insatisfeitos, uma vez que menos usuários finais serão afetados por bugs no código de produção. A maioria dos softwares embarcados contém alguns bugs perdidos no lançamento, apesar de todos os esforços de verificação, mas eles normalmente não aparecem diretamente para todos. Geralmente, há algum tempo para corrigir o problema antes que muitos clientes sejam afetados, se você souber disso o quanto antes. Idealmente, os desenvolvedores devem ser notificados segundos após o primeiro alerta e o diagnóstico de rastreamento fornecido permite uma análise e correção rápidas. Os desenvolvedores podem então enviar uma atualização automática pelo ar para corrigir o problema. O reconhecimento instantâneo e o diagnóstico de rastreamento podem reduzir muito o tempo de reparo e minimizar o número de clientes afetados.

A confiabilidade aprimorada do dispositivo reduz os riscos de responsabilidade e também os custos de suporte ao cliente, devoluções e depuração. O diagnóstico fornecido torna muito mais fácil para os desenvolvedores reproduzir os problemas dos clientes, uma vez que eles obtêm informações diretamente do dispositivo e não precisam depender do usuário para descrever as circunstâncias. Sem feedback automático, você confia em seus usuários finais para relatar quaisquer problemas e fornecer informações suficientemente detalhadas. Um relatório de erro vago como “o sistema para de responder” não é muito útil e pode levar semanas para encontrar uma causa provável. E mesmo assim, é apenas o seu melhor palpite - você não pode realmente saber se resolveu o problema certo.

Não apenas bugs
Uma coisa a observar é que os alertas não precisam ser apenas sobre bugs perdidos e os erros resultantes. Como os desenvolvedores são livres para decidir onde e por que os alertas devem ser gerados, eles também podem usá-los para monitorar as principais métricas de desempenho do aplicativo e ver o motivo de problemas ocasionais de desempenho.

O monitoramento da interface do usuário também pode revelar informações interessantes. Digamos que você tenha uma situação em que o usuário abre um menu em uma tela de toque, por exemplo, nos sistemas de infoentretenimento de um carro, e então hesita para saber onde prosseguir. Para detectar esses problemas, o desenvolvedor do aplicativo pode iniciar um cronômetro após cada evento de entrada e gerar um alerta se nenhuma entrada for recebida em, digamos, 5 segundos. Se muitos alertas forem recebidos sobre a mesma parte da interface do usuário, este pode ser um feedback importante que pode ajudar sua organização a criar produtos melhores.

Em suma, o uso de rastreamento de software e alertas baseados em nuvem em dispositivos implantados traz grandes benefícios e não é complicado. No entanto, para abraçar totalmente um fluxo de trabalho estilo DevOps requer capacidade para atualizações over-the-air e uma organização de desenvolvimento responsiva que entenda as limitações dos testes de software e a importância da melhoria contínua também após o lançamento.