RideView: Serviços de back-end e API

A plataforma avançada de telemática de vídeo RideView da LightMetrics é ativada por meio da combinação de um SDK executado em um dispositivo de borda e serviços de API de back-end executados na nuvem. Um dispositivo de borda pode ser um smartphone, um tablet ou uma câmera de painel instalada em um veículo. O dispositivo de borda executa um aplicativo que usa as APIs do SDK/cliente do RideView e gera mídia de evento e metadados para uma viagem. Em seguida, esses dados são carregados no back-end e expostos a terceiros usando nossos serviços de API.

‍

Nossos serviços de backend e API funcionam como a espinha dorsal de toda a nossa oferta, unindo todos os diferentes componentes e empacotando-os para consumo pelos usuários finais. Vamos dar uma olhada nas partes constituintes que fazem nosso backend funcionar.

‍

Arquitetura e uso

A Figura 1 mostra os principais elementos do backend da Lightmetrics. As solicitações são recebidas de vários clientes por um servidor proxy reverso. Esse servidor adicional também é usado para habilitar o cache de solicitações e qualquer filtragem adicional nas solicitações. Após a autenticação, as solicitações são tratadas por nossos microsserviços. Esses microsserviços interagem com bancos de dados hospedados na nuvem e serviços de armazenamento.

‍

A maneira recomendada de criar aplicativos usando o RideView é ilustrada na Figura 2. Um aplicativo de dispositivo é criado usando o SDK do dispositivo RideView. O SDK se comunica com os serviços da API da Lightmetrics - a criação de uma viagem e a busca de configurações de ativos são exemplos de serviços invocados pelo SDK. Os dados apropriados são criados no banco de dados, que é disponibilizado por meio de pontos de extremidade da API da Web. As APIs da Web do LM estão disponíveis para consumo, por meio do servidor TSP, no aplicativo da Web voltado para o usuário. Essas APIs fornecem serviços para buscar viagens, violações, estatísticas agregadas, detalhes da viagem e muito mais.

‍

Os princípios básicos em torno dos quais o back-end é arquitetado são:

• As informações sobre uma viagem devem estar disponíveis imediatamente e ser atualizadas com frequência.
• Vídeos e outros metadados devem estar disponíveis quando os usuários finais quiserem revisá-los.
• Diagnósticos prontamente disponíveis sobre o status da conexão, montagem da câmera e outros pontos de falha.

‍

O backend tem duas classes de APIs: interna, consumida pelo SDK, e externa, que os usuários podem consumir em seus aplicativos (móveis ou da Web). Os pontos de extremidade da API interna suportam principalmente a criação e a atualização de dados de viagens e eventos. Há duas classes de dados produzidas aqui:

• Metadados de viagem ou evento, como (lat, long), velocidade, tempo, etc. Isso é escrito como um documento NoSQL.
• Dados de mídia: Videoclipe ou imagem incidente, que é carregado no armazenamento de objetos S3.

‍

O outro conjunto de APIs fornece acesso aos dados produzidos durante a viagem e está disponível para consumo em aplicativos front-end da Web ou móveis. Elas possibilitam um rico conjunto de recursos no nível da frota, do motorista, da viagem e do ativo, que podem ser combinados para criar painéis de segurança da frota responsivos e perspicazes.

‍

Implementação

Os serviços de backend são desenvolvidos usando NodeJS e Python, executados como PaaS ou serviços de computação elástica nas nuvens AWS e IBM. O backend da LightMetrics depende de uma combinação de serviços de nuvem que trabalham em conjunto, com recursos que residem em vários provedores de serviços de nuvem. Um servidor proxy reverso(NGINX) atua como um gateway de API, enquanto a lógica central dos pontos de extremidade da API é implementada como microsserviços com NodeJS. Além do banco de dados e da infraestrutura de computação, nosso backend usa vários outros serviços de nuvem, como notificação, mensagens e lambda, para habilitar vários recursos. Há casos de uso que exigem função como serviço para implementar determinadas tarefas coordenadas e usamos funções lambda para isso. As funções lambda são uma estrutura sem servidor popular disponível no AWS e é possível executar funções isoladas quando necessário. Embora as funções lambda executem e retornem o controle, há situações que exigem a execução de trabalhos em lote coordenados, o que é possível com um serviço chamado Step function no AWS. O recurso de função de etapa aguarda a conclusão de um trabalho antes de passar para o próximo.

‍

O serviço de banco de dados subjacente usado para armazenar dados de viagem desempenha um papel central na habilitação de nossas APIs. Os principais dados consultados e agregados são os metadados da viagem e são armazenados como um documento NoSQL no IBM Cloudant (baseado no Apache CouchDB). Esse serviço de banco de dados tem a funcionalidade MapReduce integrada que permite consultas complexas e agregações de dados sem que o usuário precise se preocupar com escalabilidade e disponibilidade. Algumas das APIs permitem a classificação e a agregação de dados em diferentes chaves e utilizam internamente o recurso MapReduce integrado. Os dados de mídia são armazenados no armazenamento de objetos S3 e podem ser acessados por meio de URLs atribuídos a APIs com períodos de validade predefinidos. Os vídeos de eventos consistem principalmente em clipes gerados automaticamente com base no processamento do ADAS, do DMS e do sensor G na borda. Além disso, eles também consistem em solicitações sob demanda do back-end (DVR). Elas podem ser solicitadas após a conclusão de uma viagem e uma notificação push é enviada ao SDK para atender à solicitação. No entanto, o upload do vídeo está sujeito à disponibilidade da rede, e o SDK tem uma lógica de repetição integrada para os dados de viagem e vídeo, enquanto os webhooks associados (descritos abaixo) notificam os usuários sobre o atendimento da solicitação.

‍

Nosso servidor de API processa atualmente mais de 1 milhão de solicitações por dia, em vários clientes de diferentes regiões geográficas. Uma ampla infraestrutura de monitoramento forma os olhos e ouvidos para garantir que o backend esteja saudável e disponível em escala. Usamos a popular pilha ELK (Elasticsearch + Logstash + Kibana) para monitorar as solicitações. Os padrões de solicitações são monitorados regularmente e os alarmes são acionados caso sejam detectados padrões incomuns. Isso é um acréscimo às ferramentas de monitoramento padrão fornecidas pelos próprios provedores de serviços em nuvem.

‍

Principais recursos

‍

Webhooks

Os webhooks são uma ótima maneira de acionar fluxos de trabalho personalizados de forma assíncrona para determinados eventos. Isso permite que um usuário registre um ponto de extremidade personalizado que é chamado em determinados eventos. A Figura 3 ilustra a arquitetura de alto nível do recurso de webhook. No contexto atual, um evento pode ser a conclusão de uma viagem ou a disponibilidade de um vídeo de evento carregado. Como exemplo, um determinado fluxo de trabalho precisa ser acionado quando uma viagem é concluída. Esse fluxo de trabalho é implementado no servidor do TSP. O TSP registra o webhook (que é um ponto de extremidade da API POST REST). Após a conclusão da viagem (quando a ignição é desligada), o SDK invoca os webhooks registrados, que, por sua vez, executam o código personalizado para acionar o fluxo de trabalho. Atualmente, oferecemos suporte a webhooks para eventos relacionados a viagens, DVR e diagnósticos.

‍

Provisionamento e configurações

A primeira etapa na configuração de nosso serviço é o provisionamento de frotas e ativos. Fornecemos APIs para criar frotas, carregar ativos vinculados e marcá-los com o nível de serviço apropriado, o tipo de serviço do veículo e o status de pagamento (piloto/pago). Os eventos gerados pelo nosso SDK oferecem ampla configurabilidade, obtida por APIs que configuram limites de eventos, controle de notificação de motoristas e parâmetros de vídeo de eventos - duração, resolução, qualidade e formato.

‍

DVR, DVR com lapso de tempo, eDVR

A funcionalidade básica que todo sistema de telemática de vídeo precisa suportar é a solicitação remota de clipes de vídeo dos dispositivos, também conhecida como DVR. Isso permite que um administrador de frota solicite um videoclipe em um determinado local ou período de tempo em uma viagem, para analisar algum conteúdo de interesse - um acidente, uma reclamação do motorista etc. A plataforma RideView suporta DVR e duas de suas variantes: Time-Lapse DVR e eDVR. O eDVR permite a solicitação remota de versões de alta qualidade de vídeos de eventos já capturados. O DVR com lapso de tempo permite a revisão rápida de todo o vídeo de uma viagem, criando e carregando um vídeo com lapso de tempo de toda a viagem. Da mesma forma que os vídeos de eventos, todas as solicitações de DVR vêm com ampla capacidade de configuração de resolução, qualidade e formato de vídeo.

‍

Inteligência de crowdsourcing

A plataforma RideView, implantada em milhares de veículos, processa 15 milhões de milhas de dados de vídeo, GPS e sensores por mês (e está crescendo rapidamente). Os pontos de interesse (POI), como velocidade e sinais de parada, são extraídos dos documentos de viagem, agregados, mantidos em um banco de dados SQL separado e processados para gerar nosso próprio armazenamento de dados de POI de crowdsourcing. Atualmente, esses dados são consumidos por meio de APIs internas em nosso SDK, ajudando a aumentar o desempenho de nossos mecanismos ADAS em situações em que a detecção visual é desafiadora. No futuro, estamos trabalhando para expor nossos dados de crowdsourcing como um serviço de API independente que pode ser consumido por terceiros, mesmo fora da plataforma RideView.

‍

Nossa pilha de back-end está em constante evolução para atender às necessidades de uma crescente base global de clientes que depende dela para fornecer soluções estáveis e dimensionáveis, além de novos recursos que estão sendo adicionados para agregar mais valor aos usuários finais. Incorporar os mais recentes desenvolvimentos, ferramentas populares e práticas recomendadas, sem sacrificar a flexibilidade, a estabilidade e o dimensionamento, é um desafio, mas estamos bem posicionados para enfrentá-lo.

‍

Para saber mais sobre nossas APIs, escreva para nós em info@lightmetrics.co.