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

Resumen Técnico: Una Arquitectura de Procesamiento de Datos Nativa de Borde y Serverless para el Entrenamiento de Conducción Autónoma

Planteamiento del Problema
El desarrollo de la conducción autónoma depende fuertemente de grandes volúmenes de datos de sensores, sin embargo, el volumen de datos brutos por sí solo no garantiza una mejora en el rendimiento del modelo. Como señalan Makansi et al. [1] y Peng et al. [2], la distribución de los escenarios registrados es crítica; específicamente, la inclusión de eventos raros pero de seguridad crítica es esencial para la generalización del modelo. No obstante, capturar estos eventos infrecuentes requiere un tiempo de conducción extensivo, y realizar la selección de forma offline tras la grabación crea un exceso de sobrecarga de almacenamiento y etiquetado. Si bien la grabación selectiva en el vehículo (filtrado de datos basado en novedad, incertidumbre o criticidad) ofrece una solución, el despliegue de tales algoritmos en entornos vehiculares es un desafío. Los sistemas embebidos enfrentan restricciones estrictas de latencia, memoria y energía, además de necesitar la capacidad de adaptarse a pilas de hardware y software heterogéneas. Los motores de datos existentes y los marcos de aprendizaje activo a menudo asumen una computación centralizada en la nube con recursos abundantes, lo que los hace inadecuados para la ejecución en tiempo real a nivel de borde (edge).

Metodología
Los autores proponen el framework Lambda, una plataforma nativa de borde que adapta los principios de Función como Servicio (FaaS) a entornos automotrices con recursos limitados. El sistema tiene como objetivo separar la lógica de la aplicación (algoritmos de filtrado definidos por el usuario) de las preocupaciones de ejecución de bajo nivel, tales como la programación, el despliegue y el aislamiento.

• Arquitectura del Sistema: El framework consta de un Componente en la Nube (Cloud) y un Componente de Borde (Edge).
  • Nube: Gestiona los dispositivos de borde, mantiene el estado compartido (metadatos del vehículo, funciones desplegadas) y maneja el control de gestión de repositorios y despliegue.
  • Borde: Compuesto por un Orquestador y Runtimes de Lambda. El Orquestador (implementado en Rust) gestiona el ciclo de vida de las funciones, instanciando un proceso de runtime dedicado para cada una. Los Runtimes ejecutan las funciones definidas por el usuario (en Python o Rust) en procesos aislados.
  • Flujo de Datos: Los datos de los sensores se entregan mediante ROS 2 DDS (Data Distribution Service). El runtime emplea un modelo de concurrencia de muchos productores y un único consumidor. Los datos de alto volumen (ej. imágenes) utilizan buffers circulares libres de bloqueos (lock-free) con transferencia de copia cero (zero-copy) al runtime de Python, mientras que los datos de bajo volumen (ej. IMU) utilizan buffers circulares estándar.
• Modos de Ejecución: Las funciones Lambda operan en dos modos: periódico (intervalos fijos) o dirigido por eventos (activado por tópicos específicos de ROS 2). La implementación actual restringe cada función a un único tópico de activación para simplificar la programación determinista.
• API: El runtime expone operaciones para el acceso a datos, el disparo de acciones de grabación, inferencia ONNX y registro de logs.

Contribuciones Clave

1. Abstracción Serverless para el Borde: El artículo introduce una capa de abstracción inspirada en FaaS diseñada específicamente para el procesamiento de datos en vehículos, permitiendo a los desarrolladores centrarse en algoritmos de filtrado modulares y dirigidos por eventos sin gestionar la orquestación de bajo nivel.
2. Integración con ROS 2: El framework mantiene la compatibilidad con ROS 2 y los flujos de trabajo de grabación de datos existentes, utilizando DDS para la distribución de datos.
3. Aislamiento y Portabilidad: Mediante el uso de aislamiento de procesos y un orquestador centralizado, el sistema soporta el desarrollo rápido de algoritmos y la portabilidad a través de plataformas embebidas heterogéneas.
4. Evaluación de Rendimiento: Los autores proporcionan una evaluación comparativa del framework Lambda frente a despliegues nativos de ROS 2 en un NVIDIA Jetson Orin Nano.

Resultos Experimentales
El framework fue evaluado utilizando tres funciones lambda distintas:

1. IMU FFT: Análisis en el dominio de la frecuencia de las vibraciones de la superficie de la carretera.
2. Brake + Dark: Evaluación multisensorial que combina la aceleración de la IMU y el brillo de la cámara para detectar frenado en condiciones de baja luz.
3. YOLO Detector: Detección de objetos utilizando un modelo YOLO11m (ONNX) para identificar clases específicas (ej. peatones, bicicletas).

Métricas de Rendimiento:

• Latencia: El framework Lambda demostró un rendimiento competitivo, logrando una reducción de aproximadamente el doble en el Tiempo de Ida y Vuelta (RTT) promedio en comparación con las implementaciones nativas de ROS 2 para las cargas de trabajo de IMU FFT y YOLO Detector.
• Jitter: El framework exhibió un jitter reducido en la mayoría de los escenarios. Para el YOLO Detector, la implementación de Lambda mostró un jitter significativamente menor (MAD de 23.08 ms frente a 91.43 ms para la implementación nativa). En el escenario "Brake + Dark", aunque la implementación nativa tuvo una Desviación Absoluta de la Mediana (MAD) más baja, la implementación de Lambda mostró una distribución más estrecha en el percentil 95.
• Significancia Estadística: Prueas no paramétricas de Mann–Whitney U confirmaron que las reducciones de latencia fueron altamente significativas ($p \ll 0.001$).
• Uso de Recursos: El consumo de energía y RAM fue generalmente similar entre ambos enfoques, excepto en el caso del YOLO Detector, donde la implementación de Lambda mostró una distribución de potencia más amplia pero valores promedio más bajos.

Limitaciones y Alcance
Los autores reconocen varias limitaciones:

• La evaluación utilizó un método de medición de caja negra donde se excluyó el tiempo para enviar el mensaje RTT.
• Las pruebas se limitaron a dos modalidades de sensores (IMU y Cámara); no se probó la escalabilidad con sensores de mayor ancho de banda como LiDAR o más tópicos concurrentes.
• El Jetson Orin Nano alcanzó límites cercanos a sus recursos durante la carga de trabajo del detector YOLO, particularmente respecto a la RAM.
• La implementación actual restringe los activadores de eventos a un único tópico para evitar la complejidad de la arbitraje.

Significancia y Reivindicaciones
El artículo afirma que el framework Lambda demuestra con éxito la viabilidad de aplicar abstracciones basadas en serverless y lambda a sistemas de conducción autónoma embebidos y en tiempo real. Los resultados indican que tales abstracciones pueden soportar el procesamiento de datos en tiempo real sin comprometer los requisitos de temporización, ofreciendo una reducción de latencia y jitter en comparación con los despliegues nativos. Los autores posicionan este trabajo como una prueba de concepto para una arquitectura FaaS en pequeños sistemas de borde, validando que los desarrolladores pueden implementar un filtrado modular y dirigido por eventos manteniendo la compatibilidad con el middleware automotriz estándar como ROS 2. Los autores declaran explícitamente que la validación en despliegues reales en vehículos y la extensión a mecanismos de transporte alternativos quedan para trabajos futuros.