RideView: Servicios de backend y API

RideView, la plataforma avanzada de telemática de video de LightMetrics, funciona mediante la combinación de un SDK que se ejecuta en un dispositivo periférico y servicios de API backend que operan en la nube.

Ilustración sobre el funcionamiento de las API

RideView, la plataforma avanzada de telemática de video de LightMetrics, funciona mediante la combinación de un SDK que se ejecuta en un dispositivo periférico y servicios de API backend que operan en la nube. Un dispositivo periférico puede ser un teléfono inteligente, una tableta o una cámara de tablero instalada en un vehículo. El dispositivo ejecuta una aplicación que utiliza el SDK/API de cliente de RideView y genera archivos multimedia y metadatos de eventos para cada viaje. Estos se cargan posteriormente al backend y se ponen a disposición de terceros mediante nuestros servicios de API.

Nuestros servicios de backend y API constituyen la columna vertebral de toda nuestra oferta, integrando los distintos componentes y empaquetándolos para su consumo por parte de los usuarios finales. Echemos un vistazo al funcionamiento interno de las piezas que hacen que nuestro backend sea eficiente.

Arquitectura y uso

La Figura 1 muestra los elementos clave del backend de Lightmetrics. Un servidor proxy inverso recibe las solicitudes de varios clientes. Este servidor adicional también se utiliza para habilitar el almacenamiento en caché de solicitudes y cualquier filtrado adicional necesario. Tras la autenticación, las solicitudes son gestionadas por nuestros microservicios, los cuales interactúan con bases de datos y servicios de almacenamiento alojados en la nube.

Figura 1

La forma recomendada de crear aplicaciones con RideView se ilustra en la Figura 2. La aplicación del dispositivo se construye utilizando el SDK de dispositivo de RideView. El SDK se comunica con los servicios de API de Lightmetrics; la creación de un viaje o la obtención de configuraciones de activos son ejemplos de servicios invocados por el SDK. Se crean los datos correspondientes en la base de datos, los cuales quedan disponibles a través de puntos finales de API web. Las API web de LM están disponibles para su consumo, a través del servidor TSP, en la aplicación web orientada al usuario. Estas API proporcionan servicios para obtener viajes, infracciones, estadísticas agregadas, detalles de viajes y más.

Figura 2

Los principios fundamentales sobre los que se estructura el backend son:

  • La información sobre un viaje debe estar disponible de inmediato y actualizarse con frecuencia.
  • Los videos y otros metadatos relacionados deben estar disponibles cuando los usuarios finales deseen revisarlos.
  • Diagnósticos fácilmente disponibles sobre el estado de la conexión, el montaje de la cámara y otros puntos de fallo.

El backend cuenta con dos tipos de API: internas, consumidas por el SDK, y externas, que los usuarios pueden utilizar en sus propias aplicaciones (móviles o web). Los endpoints de la API interna sirven principalmente para crear y actualizar datos de viajes y eventos. Aquí se generan dos clases de datos:

  • Metadatos de viajes o eventos, como latitud, longitud, velocidad, tiempo, etc. Estos se almacenan como documentos NoSQL.
  • Datos multimedia: videoclips o imágenes de incidentes, que se cargan en el almacenamiento de objetos S3.

El otro conjunto de API proporciona acceso a los datos generados durante el viaje y está disponible para su consumo en aplicaciones web o móviles. Estas permiten una amplia gama de funciones a nivel de flota, conductor, viaje y activo, que pueden combinarse para crear paneles de control de seguridad de flotas dinámicos y detallados.

Implementación

Los servicios de backend se desarrollan utilizando NodeJS y Python, ejecutándose como PaaS o servicios de computación elástica en las nubes de AWS e IBM. El backend de LightMetrics se basa en una combinación de servicios en la nube que funcionan en conjunto, con recursos distribuidos entre múltiples proveedores. Un servidor proxy inverso (NGINX) actúa como puerta de enlace de API, mientras que la lógica central de los endpoints se implementa mediante microservicios con NodeJS. Además de la infraestructura de base de datos y computación, nuestro backend utiliza otros servicios en la nube, como notificaciones, mensajería y funciones lambda, para habilitar diversas características. Existen casos de uso que requieren "función como servicio" para ejecutar tareas coordinadas, para lo cual empleamos funciones lambda. Las funciones lambda son un marco de trabajo sin servidor muy popular en AWS que permite ejecutar funciones aisladas cuando es necesario. Aunque las funciones lambda se ejecutan y devuelven el control, hay situaciones que requieren trabajos por lotes coordinados, lo cual es posible gracias al servicio Step Functions de AWS. Esta función espera a que un trabajo se complete antes de pasar al siguiente.

El servicio de base de datos subyacente utilizado para almacenar los datos de los viajes desempeña un papel fundamental en el funcionamiento de nuestras API. Los datos principales que se consultan y agregan son los metadatos de los viajes, los cuales se almacenan como documentos NoSQL en IBM Cloudant (basado en Apache CouchDB). Este servicio de base de datos cuenta con una funcionalidad MapReduce integrada que permite realizar consultas y agregaciones complejas sin que el usuario deba preocuparse por la escalabilidad o la disponibilidad. Algunas de nuestras API permiten ordenar y agregar datos según diferentes claves, utilizando internamente esta función MapReduce. Los datos multimedia se almacenan en el almacenamiento de objetos S3 y son accesibles a través de API mediante URL con periodos de caducidad preestablecidos. Los videos de eventos consisten principalmente en clips generados automáticamente mediante el procesamiento en el borde (edge) de ADAS, DMS y sensores G. Además, incluyen solicitudes bajo demanda desde el backend (DVR). Estas pueden solicitarse una vez finalizado el viaje, enviando una notificación push al SDK para completar la petición. La carga de videos depende de la disponibilidad de la red, por lo que el SDK cuenta con una lógica de reintento integrada para los datos de viajes y videos, mientras que los webhooks asociados (descritos más adelante) notifican a los usuarios sobre el cumplimiento de la solicitud.

Nuestro servidor de API procesa actualmente más de 1 millón de solicitudes al día, provenientes de múltiples clientes en diferentes regiones geográficas. Una infraestructura de monitoreo exhaustiva actúa como ojos y oídos para garantizar que el backend sea saludable y esté disponible a gran escala. Utilizamos la popular pila ELK (Elasticsearch + Logstash + Kibana) para monitorear las solicitudes. Los patrones de solicitud se supervisan regularmente y se activan alarmas si se detecta cualquier comportamiento inusual. Esto se suma a las herramientas de monitoreo predeterminadas que ofrecen los propios proveedores de servicios en la nube.

Características principales

Webhooks

Webhooks son una excelente forma de activar flujos de trabajo personalizados de manera asíncrona ante determinados eventos. Esto permite al usuario registrar un endpoint personalizado que se invoca cuando ocurren ciertos eventos. La Figura 3 ilustra la arquitectura general de la funcionalidad de webhooks. En el contexto actual, un evento puede ser la finalización de un viaje o la disponibilidad de un video de evento cargado. Por ejemplo, es necesario activar un flujo de trabajo específico cuando se completa un viaje. Este flujo de trabajo se implementa en el servidor del TSP. El TSP registra el webhook (que es un endpoint de API REST de tipo POST). Al finalizar el viaje (cuando se apaga el motor), el SDK invoca los webhooks registrados, lo que a su vez ejecuta el código personalizado para activar el flujo de trabajo. Actualmente, admitimos webhooks para eventos relacionados con viajes, DVR y diagnósticos.

Figura 3

Aprovisionamiento y configuraciones

El primer paso para configurar nuestro servicio es el aprovisionamiento de flotas y activos. Proporcionamos APIs para crear flotas, cargar activos vinculados y etiquetarlos con el nivel de servicio, el tipo de servicio del vehículo y el estado de pago (piloto/pagado) correspondientes. Los eventos generados por nuestro SDK ofrecen una amplia capacidad de configuración, lograda mediante APIs que configuran los umbrales de eventos, el control de notificaciones al conductor y los parámetros de video del evento: duración, resolución, calidad y formato.

DVR, DVR de lapso de tiempo, eDVR

La funcionalidad básica que todo sistema telemático de video debe admitir es la solicitud remota de clips de video desde los dispositivos, también conocida como DVR. Esto permite a un administrador de flota solicitar un clip de video de una ubicación o ventana de tiempo específica dentro de un viaje, para revisar contenido de interés: un accidente, una queja de un conductor, etc. La plataforma RideView admite DVR y dos de sus variantes: DVR de lapso de tiempo (Time-Lapse) y eDVR. eDVR permite solicitar de forma remota versiones de mayor calidad de videos de eventos ya capturados. El DVR de lapso de tiempo permite una revisión rápida de todo el video de un viaje, mediante la creación y carga de un video en lapso de tiempo de todo el trayecto. Al igual que con los videos de eventos, todas las solicitudes de DVR cuentan con una amplia capacidad de configuración en cuanto a resolución, calidad y formato de video.

Inteligencia colectiva

La plataforma RideView, implementada en miles de vehículos, procesa 15 millones de millas de datos de video, GPS y sensores cada mes (y esta cifra crece rápidamente). Los puntos de interés (POI), como señales de velocidad y de pare, se extraen de los documentos de viaje, se agregan, se mantienen en una base de datos SQL independiente y se procesan para generar nuestro propio almacén de datos de POI de inteligencia colectiva. Actualmente, estos datos se consumen a través de APIs internas en nuestro SDK, ayudando a mejorar el rendimiento de nuestros motores ADAS en situaciones donde la detección visual resulta compleja. De cara al futuro, estamos trabajando para exponer nuestros datos de inteligencia colectiva como un servicio de API independiente que pueda ser consumido por terceros, incluso fuera de la plataforma RideView.

Nuestra infraestructura de backend evoluciona constantemente para satisfacer las necesidades de una creciente base de clientes global que confía en ella para obtener soluciones estables y escalables, además de nuevas funcionalidades que aportan mayor valor a los usuarios finales. Incorporar los últimos avances, herramientas populares y mejores prácticas, sin sacrificar la flexibilidad, la estabilidad ni la escalabilidad, es un reto que estamos perfectamente preparados para afrontar.

Para obtener más información sobre nuestras API, escríbanos a info@lightmetrics.co.