Construindo um Sistema de Rastreamento de Carros inovador com Things Expert


Com o desafio de criar uma solução de rastreamento de carros como mercado-alvo as companhias de aluguel de carro, a Datora Telecom, empresa que opera no mercado de comunicação provendo serviços de terminação e sinalização de chamadas eficientes, e pioneira no uso da tecnologia de transmissão de pacote de voz (VoIP) na América Latina, viu na Microsoft um importante e decisivo parceiro para revolucionar o mercado de rastreamento, culminando em uma nova oportunidade de negócio e entrada em mercado de atuação diferente, alavancada em sua infraestrutura existente. Confira este caso de sucesso!

Cliente

A Things Expert é uma subsidiária da Datora Telecom que se concentra em pesquisa e inovação. A Datora Telecom atua no mercado de comunicações, fornecendo aos seus clientes serviços eficientes de terminação de chamadas, transporte e terceirização, sempre com a mais moderna tecnologia disponível. Pioneira no uso da tecnologia de transmissão de voz por pacotes (VoIP) na América Latina, a Datora Telecom é uma experiente provedora de serviços para as maiores empresas de telefonia do Brasil, tendo ainda operações em Portugal, Espanha, EUA, Itália, Guatemala e diversas cidades brasileiras. A Datora possui infraestrutura como torres e antenas, e trabalhando com a Things Expert, sua divisão de inovação, eles pretendem desenvolver novos negócios com a tecnologia que já possuem.

A Things Expert se concentra em criar soluções direcionadas que fornecem dados através de sensores, conectividade, inteligência artificial, tratamento de dados e big data, e podem ser customizadas de acordo com as necessidades de cada cliente.

 

Para esse projeto, o time da Microsoft e da Things Expert era composto por:

  • Caio Garcez – Microsoft, Evangelista Técnico
  • Tati Fontes – Microsoft, Gerente de Marketing de Audiência
  • Thiago Oliveira – Microsoft, Estagiário de Marketing de Audiência
  • Allan Targino – Microsoft, Estagiário como Evangelista Técnico
  • Carmen Pedrossian – Microsoft, Estagiário de Inovação e Transformação Digital
  • Christiano Faig – Microsoft, Gerente de Inovação e Transformação Digital
  • Daniel Fuchs – Things Expert, Fundador e CIO
  • Thiago Schuber – Things Expert, Desenvolvedor

Descrição do Problema:

Cenário Inicial

A Things Expert queria criar uma solução de rastreamento de carros que fosse mais eficiente que as soluções já existentes no mercado. A solução teria como mercado-alvo empresas de aluguel de carros, que implementam dispositivos de rastreamento em seus veículos para obter discontos significativos das seguradoras. As soluções de rastreamento de carros que estão atualmente no mercado baseiam-se na instalação de dispositivos GPS nos veículos. Essa prática tem duas desvantagens: elevado consumo de bateria e alta utilização de conexão de dados (resultando em encargos com a operadora). A Microsoft e a Things Expert queriam melhorar uma solução de mercado existente. Para isso, precisávamos superar quatro barreiras:

  • Consumo de bateria
  • Alta utilização de dados
  • Escalabilidade para suportar, inicialmente, cerca de 200.000 carros
  • Integridade das mensagens, de modo que nenhuma das mensagens enviadas para a nuvem fosse perdida

Em nossa primeira reunião, discutimos a arquitetura da solução e as tecnologias necessárias. Foi decidido que os modems GSM seriam acoplados ao carro. Eles fariam um telefonema, mas assim que a chamada chegasse no call center seria interceptada, o que não geraria taxas ou qualquer tipo de custo, pelo fato da chamada não ter sido realizada por um número válido – seria, na verdade, apenas incorporadas informações de latitude e longitude. O call center que recebe a chamada é de propriedade da Datora Telecom, o que dá viabilidade à solução esperada.

Com essa ideia em mente, nós projetamos o esquema da solução:

  1. O modem GSM embutido no carro faz uma chamada para o call center
  2. O call center identifica quem está chamando e quem deve ser chamado, e extrai as informações de latitude e longitude embutidas no número de telefone
  3. O call center pesquisa em um banco de dados interno para identificar a empresa associada ao carro que está fazendo a chamada
  4. O call center traduz o modem GSM (o carro) em um dispositivo virtual do IoT Hub. Se esta for a primeira vez, o centro insere a informação; caso contrário, envia os dados para o Hub IoT
  5. O Stream Analytics formata os dados e os envia para a tabela do Azure Storage

Essa estrutura descreve o primeiro passo da solução – a inserção e manipulação de dados. A segunda parte, referente ao consumo de dados, também foi projetada durante a reunião inicial. Funcionaria assim:

  • O cliente teria duas APIs para consultar seus dados: uma apresentando uma visão de longo prazo, a outra de curto prazo
  • A API de curto prazo custaria menos ao cliente
  • Se um cliente quisesse consultar informações anteriores a um período de 7 dias (tempo caracterizado como longo prazo), eles pagariam um preço mais alto

Essa arquitetura inicial tinha alguns problemas que perceberíamos posteriormente. O primeiro é que ter o call center da Datora identificando o número que está chamando e o relacionando com a empresa de carro não seria muito produtivo. Além disso, o uso de IoT Hub levantou algumas perguntas sobre os custos da solução. (Mais tarde, descobrimos que o custo com o Event Hub seria cerca de 100 vezes mais barato que com o IoT Hub, pelas mensagens serem mais curtas e os envios serem em baixas frequências.) Finalmente, o gerenciamento da API se tornou uma coisa só, devido aos diferenciados e flexíveis modelos de plano de cobrança, intrinsecamente presentes nele.

Com isso em mente, fizemos algumas mudanças na estrutura original. A função de relacionar as empresas aos números de telefone foi transferida para o Stream Analytics, as duas APIs de consultas transformaram-se em apenas uma, e o IoT Hub foi substituído pelo Event Hub com a intenção de obter uma solução mais econômica.

Com a revisão desse projeto, resolvemos todos os problemas identificados anteriormente:

  • O consumo de bateria seria baixo, porque os modems GSM não requerem muita energia
  • A solução não consumiria dados porque as chamadas seriam feitas via telefone (e não hveriam encargos porque as chamadas seriam interceptadas pelo call center antes que elas fossem concluídas)
  • A escalabilidade e integridade necessárias seriam alcançadas através do Event Hub

A solução que criamos precisa ser escalável e flexível o bastante para receber mensagens de todos os carros, já que o parceiro havia estimado um número de até 200.000 carros se utilizando da solução.

Soluções, etapas e entregas

Nós viemos com muitas ideias em nossa primeira reunião de brainstorming. Basicamente, eles já tinham desenvolvido esse framework envolvendo sua infraestrutura móvel e mensagens através de sua rede, mas precisavam conectá-lo à nuvem.

Ao perceber que seu servidor já era capaz de enviar mensagens HTTP, começamos a projetar a parte de conexão em nuvem da solução. Veja o resultado na Figura 2.

fig1

Figura 1. Rascunho do primeiro brainstorming

fig2

Figura 2. Arquitetura de inserção de dados.

 

Event Hub, Stream Analytics e Tabelas de Storage

Depois que a mensagem do carro chega ao servidor de sinalização móvel deles, ele envia uma mensagem HTTP para Event Hub com os dados de GPS e campos de ID adicionais. Uma típica mensagem enviada pelos carros é mostrada abaixo (Código Snippet 1). Essencialmente ele carrega o campo Id_thing (relacionado ao número IMEI ou IMSI do modem GSM) e informações de latitude e longitude.

{
"anum":"21960101935",
	"bnum":"008102980000000180014",
"cgi":"724030041128843",
"id_thing":"724180050340589",
	"lat":"-23.5813055556",
	"long":"-46.62425"
}

Trecho de Código 1. Mensagem típica enviada pelos carros.

Quando uma mensagem entra no Event Hub, o Stream Analytics usa dados de referência estática para descobrir a empresa a que pertence o carro, comparando a ID do carro (id_thing) com o ID da empresa (account number). A topologia e o código do Stream Analytics são os seguintes:

fig3

Figura 3. Topologia de entradas e saídas do Stream Analytics.

--Processing
WITH ProcessedInput AS (
    SELECT
        CASE
            WHEN LEN(id_thing) = 17 THEN CONCAT('90', id_thing)
            WHEN LEN(id_thing) = 15 THEN CONCAT('8000', id_thing)
            ELSE CONCAT('X', id_thing)
        END AS id_thing, System.TimeStamp AS datetime_event, lat AS latitude, long AS longitude, dts AS date_event, tts AS time_event, anum AS numA, bnum AS numB, cgi AS CGI
    FROM
        Labcom01in
)

--Output: xDR
SELECT
    PI.id_thing, PI.datetime_event, Ref.account, PI.latitude, PI.longitude, PI.date_event, PI.time_event, PI.numA, PI.numB, PI.CGI
INTO
    xDRout
FROM
    ProcessedInput PI
JOIN
    Idthingrdin Ref
ON
    PI.id_thing = Ref.id_thing

Trecho de Código 2. Código de consulta do Stream Analytics

 

Como mostram as imagens acima, o Stream Analytics armazena os dados processados em uma tabela do Azure Storage para que posteriormente possam ser consultados pela nossa API.

 

Azure AD, App Service and API Management

Com a etapa de inserção completa, era hora de desenvolver a API que as empresas de carro iriam usar. Ela deveria ser suficientemente segura para fornecer acesso e dados somente a usuários autorizados, com seus respectivos números de conta associados. A equipe da Things Expert decidiu usar o Azure Active Directory (Azure AD) tanto para gerenciar os usuários quanto para proteger a API. Eles também decidiram usar propriedades extensíveis, com o objetivo de estender o esquema do AD e armazenar as informações do número da conta, associando cada usuário com um número de conta (exclusivo para cada empresa – desta forma, uma única empresa pode ter vários usuários autorizados).

Escolhemos a API Web ASP.NET como nossa principal tecnologia para criar a API, devido à fácil integração com o Azure AD usando o plug-in OpenID. Foi muito rápido construir uma API que recupera o conteúdo de uma tabela do Azure Storage e o envia em formato JSON para o solicitante.

Combinando a API Web ASP.NET e as propriedades extensíveis do Azure AD no controlador da solução, nós obtivemos o respectivo número de conta do usuário autenticado e recuperamos as informações do carro da tabela do Azure Storage. Por exemplo, aqui estão os modelos usados e uma ação no controlador principal que recupera as informações:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace ZeroMegaAPI.Models
{
public class ThingEntity : TableEntity
{
// Your entity type must expose a parameter-less constructor
public ThingEntity() { }

// Define the PK and RK
public ThingEntity(string id_thing, string datetime_event)
{
this.PartitionKey = id_thing;
this.RowKey = datetime_event;
}


public string id_thing { get; set; }

public DateTime datetime_event { get; set; }

public string account { get; set; }

public string cgi { get; set; }

public string latitude { get; set; }

public string longitude { get; set; }

public string numa { get; set; }

public string numb { get; set; }
}
}

Trecho de Código 3. Modelo ThingEntity, referenciando a maneira exata como os dados são armazenados na tabela.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace ZeroMegaAPI.Models
{
public class ThingPosition
{
public string IDThing { get; set; }

public DateTime DateTimeEvent { get; set; }

public string Latitude { get; set; }

public string Longitude { get; set; }

}
}

Trecho de Código 4. Modelo ThingPosition, referenciando a maneira como os dados são apresentados pela API.

[Route("api/Position")]
public async Task<IEnumerable<ThingPosition>> Get() {
var user = getUPN();
var account = GetAccountId(user);

return await _repository.GetAllThingsPositions(account);
}

Trecho de Código 5 – Exemplo de uma ação do PositionController.

 

A etapa final de desenvolvimento consistiu apenas em hospedar nossa API Web em algum lugar, então escolhemos hospedá-la como uma API no Azure App Service, que nos dá a documentação da API usando o Swagger, sem nenhum esforço adicional.

fig4

Figura 4. Documentação do Swagger Automático para a API Web.

 

Depois disso, usando um ótimo artigo de Steve Danielson na documentação oficial do Azure (que pode ser encontrado aqui), criamos um ambiente de Gerenciamento de API, usamos nosso inquilino do Azure AD como um servidor de autorização do OAuth, e apenas adicionamos uma referência ao aplicativo Azure API usando o arquivo doc do Swagger.

O Gerenciamento de API nos deu um middleware para limitar e cobrar usuários por uso de API, proporcionando-nos excelentes dados para análises e insights.

fig5

Figura 5. Alguns membros da equipe assistindo a solução de trabalho após a fácil integração com o API Management.

 

Por fim, a arquitetura final de consulta de dados ficou da seguinte maneira:

fig6

Figura 6. Arquitetura de consulta de dados

Conclusão

Este projeto terminou com uma solução bem sucedida que deu aos parceiros o que eles precisavam e deu à Microsoft a chance de criar tecnologias inovadoras, como o Event Hub. O projeto foi implementado em três semanas com um evangelista técnico dedicado na conta, ajudando com quaisquer problemas que pudessem surgir.

Concluímos nosso objetivo de fazer uma solução de rastreamento mais econômica do que as já existentes no mercado e superamos as barreiras do projeto: o alto consumo de bateria, o alto uso de dados, a necessidade de escalabilidade e a integridade das mensagens. O consumo de bateria e o uso de dados não eram mais um problema quando usamos modems GSM e a integridade e escalabilidade foram alcançadas graças ao Event Hub.

Um ciclo completo de dados de inserção de modems GSM e o respectivo consumo de dados, a partir de uma API Web, foram construídos para suportar um cenário de localização de carros, porém, toda a solução poderia ser usada para enviar qualquer tipo de dado relevante, visto ser uma incrível alternativa para o mercado existente. Além disso, após alguns meses de recuperação de dados, poderíamos usar Machine Learning (Aprendizado de Máquina) para prever ou aprender muito mais sobre as informações que inicialmente tínhamos.

A boa relação construída durante o projeto resultou em uma porta aberta para a Microsoft no Things Expert e a possibilidade de desenvolver outras soluções, algumas já sendo discutidas pela equipe.

fig7

Figura 7. Finalizando a entrega da solução e determinando seu preço. Nós conseguimos!

Aqui está um relato do cliente:

 “Nossa parceria com a Microsoft no projeto Zero Mega, especialmente através da Carmen Pedrossian e do Allan Targino, foi um componente fundamental para capacitar nosso time técnico para trabalhar com as tecnologias do Azure e construir nosso sistema de rastreamento de carro. Esse sistema muda significativamente o modo como dispositivos de rastreamento de veículos se comunicam com um sistema central que recebe e armazena dados, enquanto permite também que usuários finais visualizem esses dados de maneira significativa. Essa nova abordagem traz consigo benefícios de performance e custo, e vai, definitivamente, alavancar nossas vendas nesse segmento. É disso que o mercado precisa: soluções que agregam valor ao mesmo tempo que reduzem custos para os clientes sem prejudicar nossa receita”.

Assita também ao video deste caso de sucesso:


Autor: Microsoft Tech