RideView: Servicios de backend y API

La avanzada plataforma de vídeo telemática RideView de LightMetrics funciona mediante la combinación de un SDK que se ejecuta en un dispositivo periférico y servicios API backend que se ejecutan en la nube. Un dispositivo de borde puede ser un smartphone, una tableta o una cámara de salpicadero instalada en un vehículo. El dispositivo de borde ejecuta una aplicación que utiliza el SDK/las API de cliente de RideView y genera medios de eventos y metadatos para un viaje. A continuación, se cargan en el backend y se exponen a terceros mediante nuestros servicios API.

‍

Nuestros servicios de backend y API son la columna vertebral de toda nuestra oferta, ya que unen todos los componentes y los empaquetan para su consumo por parte de los usuarios finales. Echemos un vistazo a los componentes que hacen funcionar nuestro backend.

‍

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 las solicitudes y cualquier filtrado adicional de las mismas. Tras la autenticación, las solicitudes son gestionadas por nuestros microservicios. Estos microservicios interactúan con bases de datos alojadas en la nube y servicios de almacenamiento.

‍

La forma recomendada de crear aplicaciones con RideView se ilustra en la figura 2. Una aplicación de dispositivo se construye utilizando el SDK de dispositivo RideView. El SDK se comunica con los servicios de la API de Lightmetrics - la creación de un viaje, la obtención de configuraciones de activos son ejemplos de servicios invocados por el SDK. Los datos apropiados se crean en la base de datos, que está disponible a través de los puntos finales de la API web. Las API web 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, etc.

‍

Los principios básicos en torno a los que se articula el backend son:

• La información sobre un viaje debe estar disponible de inmediato y actualizarse con frecuencia.
• Los vídeos y otros metadatos deben estar disponibles cuando los usuarios finales quieran 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 tiene dos clases de API: internas, consumidas por el SDK, y externas, que los usuarios pueden consumir en sus aplicaciones (móviles o web). Los puntos finales de la API interna soportan principalmente la creación y actualización de datos de viajes y eventos. Aquí se producen dos clases de datos:

• Metadatos del viaje o del evento como (latitud, longitud), velocidad, hora, etc. Esto se escribe como un documento NoSQL.
• Datos multimedia: Video clip o imagen incidente, que se carga en el almacenamiento de objetos S3.

‍

El otro conjunto de API proporciona acceso a los datos producidos durante el viaje y está disponible para su consumo en aplicaciones front-end web o móviles. Permiten un amplio conjunto de funciones a nivel de flota, conductor, viaje y activo, que pueden combinarse para crear cuadros de mando de seguridad de flotas sensibles y perspicaces.

‍

Aplicación

Los servicios de backend se desarrollan con NodeJS y Python, y se ejecutan 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 trabajan en tándem, con recursos que residen en varios proveedores de servicios en la nube. Un servidor proxy inverso(NGINX) actúa como pasarela de la API, mientras que la lógica central de los puntos finales de la API se implementa como microservicios con NodeJS. Aparte de la base de datos y la infraestructura informática, nuestro backend utiliza otros servicios en la nube como notificación, mensajería y lambda para habilitar diversas funciones. Hay casos de uso que requieren funciones como servicio para implementar ciertas tareas coordinadas y utilizamos funciones lambda para ello. Las funciones lambda son un marco popular sin servidor disponible en AWS y uno puede ejecutar funciones aisladas cuando sea necesario. Mientras que las funciones lambda se ejecutan y devuelven el control, hay situaciones que exigen la ejecución de trabajos por lotes coordinados, lo que es posible gracias a un servicio llamado Step function en AWS. La función step espera a que se complete un trabajo 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 a la hora de habilitar nuestras API. Los principales datos consultados y agregados son los metadatos del viaje y se almacenan como un documento NoSQL en IBM Cloudant (basado en Apache CouchDB). Este servicio de base de datos tiene incorporada la funcionalidad MapReduce que permite realizar consultas y agregaciones complejas sobre los datos sin que el usuario tenga que preocuparse por la escalabilidad y la disponibilidad. Algunas de las API permiten la ordenación y agregación de datos en diferentes claves y utilizan internamente la función MapReduce incorporada. Los datos multimedia se guardan en el almacenamiento de objetos S3 y se puede acceder a ellos a través de las URL asignadas a las API con periodos de caducidad preestablecidos. Los vídeos de eventos consisten principalmente en clips generados automáticamente basados en ADAS, DMS y el procesamiento del sensor G en el borde. Además, también consisten en solicitudes a la carta desde el backend (DVR). Éstas pueden solicitarse una vez finalizado un viaje y se envía una notificación push al SDK para satisfacer la solicitud. Sin embargo, la carga de vídeo está sujeta a la disponibilidad de la red, y el SDK tiene incorporada una lógica de reintento para los datos de viaje y vídeo, mientras que los webhooks asociados (descritos a continuación) notifican a los usuarios el cumplimiento de la solicitud.

‍

Nuestro servidor API procesa actualmente más de 1 millón de solicitudes al día, a través de múltiples clientes en diferentes geografías. Una amplia infraestructura de monitorización constituye los ojos y los oídos para garantizar que el backend goza de buena salud y está disponible a escala. Utilizamos la popular pila ELK (Elasticsearch + Logstash + Kibana) para supervisar las solicitudes. Los patrones de las solicitudes se supervisan regularmente y las alarmas se activan en caso de que se detecten patrones inusuales. Esto se suma a las herramientas de supervisión predeterminadas proporcionadas por los propios proveedores de servicios en la nube.

‍

Características principales

‍

Webhooks

Los webhooks son una excelente forma de activar flujos de trabajo personalizados de forma asíncrona para determinados eventos. Esto permite a un usuario registrar un punto final personalizado que se invoca en determinados eventos. La figura 3 ilustra la arquitectura de alto nivel de la función webhook. En el contexto actual, un evento puede ser la finalización de un viaje o la disponibilidad de un vídeo de evento cargado. A modo de ejemplo, es necesario activar un flujo de trabajo concreto cuando se completa un viaje. Este flujo de trabajo se implementa en el servidor del TSP. El TSP registra el webhook (que es un POST REST API endpoint). Al finalizar el viaje (cuando se apaga el motor), el SDK invoca los webhooks registrados, que a su vez ejecutan código personalizado para activar el flujo de trabajo. Actualmente, admitimos webhooks para eventos relacionados con viajes, DVR y diagnósticos.

‍

Aprovisionamiento y configuraciones

El primer paso para configurar nuestro servicio es aprovisionar flotas y activos. Proporcionamos API para crear flotas, cargar activos vinculados y etiquetarlos con el nivel de servicio adecuado, el tipo de servicio del vehículo y el estado de pago (piloto/pagado). Los eventos generados por nuestro SDK ofrecen una amplia capacidad de configuración, que se consigue mediante API que configuran los umbrales de los eventos, el control de las notificaciones a los conductores y los parámetros de vídeo de los eventos: duración, resolución, calidad y formato.

‍

DVR, DVR con lapso de tiempo, eDVR

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

‍

Inteligencia colectiva

La plataforma RideView, instalada en miles de vehículos, procesa cada mes 15 millones de kilómetros de datos de vídeo, GPS y sensores (y sigue creciendo rápidamente). Los puntos de interés (POI), como las señales de velocidad y de stop, 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. Estos datos se consumen actualmente a través de API internas en nuestro SDK, ayudando a aumentar el rendimiento de nuestros motores ADAS en situaciones en las que la detección visual es un reto. En el futuro, estamos trabajando en la exposición de nuestros datos crowdsourced como un servicio de API independiente que puede ser consumido por terceros, incluso fuera de la plataforma RideView.

‍

Nuestra pila de backend evoluciona continuamente para satisfacer las necesidades de una creciente base de clientes globales que confían en ella para ofrecer soluciones estables y escalables, y también nuevas funciones que se añaden para ofrecer más valor a los usuarios finales. Incorporar los últimos avances, las herramientas más populares y las mejores prácticas, sin sacrificar la flexibilidad, la estabilidad y la escalabilidad es un reto, pero estamos bien posicionados para afrontarlo.

‍

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