A Serverless Edge-Native Data Processing Architecture for Autonomous Driving Training

Resumo Técnico: Uma Arquitetura de Processamento de Dados Nativa de Borda e Serverless para Treinamento de Condução Autônoma

Declaração do Problema
O desenvolvimento de condução autônoma depende fortemente de grandes volumes de dados de sensores, mas o volume bruto de dados por si só não garante a melhoria do desempenho do modelo. Como observado por Makansi et al. [1] e Peng et al. [2], a distribuição dos cenários registrados é crítica; especificamente, a inclusão de eventos raros, porém críticos para a segurança, é essencial para a generalização do modelo. No entanto, capturar esses eventos infrequentes requer um tempo de condução extensivo, e realizar a seleção offline após a gravação cria um excesso de sobrecarga de armazenamento e rotulagem. Embora a gravação seletiva no veículo (filtragem de dados baseada em novidade, incerteza ou criticidade) ofereça uma solução, a implantação de tais algoritmos em ambientes veiculares é desafiadora. Sistemas embarcados enfrentam restrições rigorosas de latência, memória e energia, além de precisarem acomodar pilhas de hardware e software heterogêneas. Motores de dados existentes e frameworks de aprendizado ativo frequentemente assumem computação centralizada na nuvem com recursos abundantes, tornando-os inadequados para execução em tempo real no nível da borda (edge).

Metodologia
Os autores propõem o framework Lambda, uma plataforma nativa de borda que adapta os princípios de Função como um Serviço (FaaS) para ambientes automotivos com recursos limitados. O sistema visa separar a lógica da aplicação (algoritmos de filtragem definidos pelo usuário) das preocupações de execução de baixo nível, como agendamento, implantação e isolamento.

• Arquitetura do Sistema: O framework consiste em um Componente de Nuvem e um Componente de Borda.
  • Nuvem: Gerencia dispositivos de borda, mantém o estado compartilhado (metadados do veículo, funções implantadas) e lida com o gerenciamento de repositórios e controle de implantação.
  • Borda: Composta por um Orquestrador e Runtimes Lambda. O Orquestrador (implementado em Rust) gerencia o ciclo de vida das funções, instanciando um processo de runtime dedicado para cada uma. Os Runtimes executam as funções definidas pelo usuário (em Python ou Rust) em processos isolados.
  • Fluxo de Dados: Os dados dos sensores são entregues via ROS 2 DDS (Data Distribution Service). O runtime utiliza um modelo de concorrência de muitos produtores e um único consumidor. Dados de alto volume (ex: imagens) utilizam buffers circulares sem bloqueio (lock-free) com transferência zero-copy para o runtime Python, enquanto dados de baixo volume (ex: IMU) utilizam buffers circulares padrão.
• Modos de Execução: As funções Lambda operam em dois modos: periódico (intervalos fixos) ou baseado em eventos (disparado por tópicos específicos do ROS 2). A implementação atual restringe cada função a um único tópico de disparo para simplificar o agendamento determinístico.
• API: O runtime expõe operações para acesso a dados, acionamento de ações de gravação, inferência ONNX e registro de logs.

Principais Contribuições

1. Abstração Serverless para a Borda: O artigo introduz uma camada de abstração inspirada em FaaS projetada especificamente para o processamento de dados no veículo, permitindo que desenvolvedores foquem em algoritmos de filtragem modulares e orientados a eventos sem gerenciar a orquestração de baixo nível.
2. Integração com ROS 2: O framework mantém a compatibilidade com o ROS 2 e com as pipelines de gravação de dados existentes, utilizando DDS para distribuição de dados.
3. Isolamento e Portabilidade: Ao utilizar isolamento de processo e um orquestrador centralizado, o sistema suporta o desenvolvimento rápido de algoritmos e a portabilidade entre plataformas embarcadas heterogêneas.
4. Avaliação de Desempenho: Os autores fornecem uma avaliação comparativa do framework Lambda contra implantações nativas de ROS 2 em um NVIDIA Jetson Orin Nano.

Resultados Experimentais
O framework foi avaliado usando três funções lambda distintas:

1. IMU FFT: Análise de domínio de frequência de vibrações da superfície da estrada.
2. Brake + Dark: Avaliação multissensorial combinando aceleração de IMU e brilho da câmera para detectar frenagem em baixa luminosidade.
3. YOLO Detector: Detecção de objetos usando um modelo YOLO11m (ONNX) para identificar classes específicas (ex: pedestres, bicicletas).

Métricas de Desempenho:

• Latência: O framework Lambda demonstrou um desempenho competitivo, alcançando uma redução de aproximadamente duas vezes no Tempo de Ida e Volta (RTT) médio em comparação com as implementações nativas de ROS 2 para as cargas de trabalho IMU FFT e YOLO Detector.
• Jitter: O framework exibiu redução de jitter na maioria dos cenários. Para o YOLO Detector, a implementação Lambda mostrou um jitter significativamente menor (MAD de 23,08 ms vs. 91,43 ms para o nativo). No cenário "Brake + Dark", embora a implementação nativa tenha apresentado um Desvio Absoluto da Mediana (MAD) menor, a implementação Lambda mostrou uma distribuição mais estreita no percentil 95.
• Significância Estatística: Testes não paramétricos de Mann–Whitney U confirmaram que as reduções de latência foram altamente significativas ($p \ll 0,001$).
• Uso de Recursos: O consumo de energia e RAM foi geralmente semelhante entre as duas abordagens, exceto para o YOLO Detector, onde a implementação Lambda mostrou uma distribuição de potência mais ampla, mas valores médios menores.

Limitações e Escopo
Os autores reconhecem diversas limitações:

• A avaliação utilizou um método de medição de caixa preta (black-box), onde o tempo para enviar a mensagem de RTT foi excluído.
• Os testes foram limitados a duas modalidades de sensores (IMU e Câmera); a escalabilidade com sensores de maior largura de banda, como LiDAR, ou mais tópicos simultâneos não foi testada.
• O Jetson Orin Nano atingiu limites próximos aos de recursos durante a carga de trabalho do detector YOLO, particularmente em relação à RAM.
• A implementação atual restringe os gatilhos de eventos a um único tópico para evitar complexidade de arbitragem.

Significância e Alegações
O artigo afirma que o framework Lambda demonstra com sucesso a viabilidade de aplicar abstrações baseadas em serverless e lambda a sistemas de condução autônoma embarcados em tempo real. Os resultados indicam que tais abstrações podem suportar o processamento de dados em tempo real sem comprometer os requisitos de tempo, oferecendo redução de latência e jitter em comparação com implantações nativas. Os autores posicionam este trabalho como uma prova de conceito para arquitetura FaaS em pequenos sistemas de borda, validando que desenvolvedores podem implementar filtragem modular e orientada a eventos mantendo a compatibilidade com o middleware automotivo padrão, como o ROS 2. Os autores declaram explicitamente que a validação em implantações reais dentro de veículos e a extensão para mecanismos de transporte alternativos ficam para trabalhos futuros.