Conceitos de configuração de métricas

As configurações de métricas definem as campanhas de telemetria que o serviço de telemetria executa. Uma configuração de métricas é uma instância de uma mensagem de buffer de protocolo (protobuf) MetricsConfig. As configurações de métricas especificam como coletar, processar e gerar relatórios de dados. Os OEMs podem ativar configurações de métricas pela API do serviço de telemetria. Várias configurações podem ser executadas simultaneamente.

Antes de começar, familiarize-se com a arquitetura do SDV, que é uma arquitetura orientada a serviços em que os serviços publicam dados como mensagens protobuf. Essas mensagens se comunicam usando a pilha de comunicação do SDV por RPC ou publicação-assinatura.

Termos-chave

Uma configuração de métricas organiza a coleta de dados definindo fontes de dados, regras de processamento e mecanismos de geração de relatórios. Um dos principais benefícios desse processamento de borda é a redução do uso de dados móveis. Ao processar dados de alta frequência no dispositivo e fazer upload apenas de agregações ou insights, você reduz significativamente a quantidade de dados transmitidos para a nuvem.

A definição de uma configuração de métricas começa listando as fontes de dados a serem usadas na configuração. São serviços que disponibilizam dados pela pilha de comunicação do SDV. Quando você ativa uma configuração, o serviço de telemetria se conecta a essas fontes para transmitir ou buscar dados conforme necessário.

O núcleo de uma configuração é a capacidade de processamento de dados de borda, gerenciada por agregadores de dados com estado. Cada agregador usa um criador de mensagens que mantém uma instância de mensagem proto com estado. Cada campo nessa mensagem é preenchido avaliando uma expressão, definindo quais dados ler de outras fontes de dados ou agregadores e quais operações matemáticas, lógicas ou de agregação aplicar aos dados. É possível aplicar outras agregações ao resultado de uma expressão.

Os acionadores são essenciais para controlar esse processo. Eles podem ser acionados periodicamente, em resposta a novos dados ou quando as condições baseadas em dados são atendidas. Os gatilhos determinam quando os agregadores avaliam o criador de mensagens e quando os relatórios de métricas são gerados. Eles também podem influenciar o ciclo de vida da configuração, por exemplo, iniciando ou interrompendo a coleta de dados.

Os relatórios de métricas são a saída final. Cada relatório inclui o payload de dados definido por um criador de mensagens, além de metadados como carimbos de data/hora e ID do relatório. É possível gerar relatórios em momentos específicos do ciclo de vida da configuração, como quando uma configuração é ativada ou desativada. Os relatórios gerados são armazenados na memória, e o cliente é notificado para recuperação pelo canal de notificação de status do relatório.

A figura a seguir mostra um exemplo conceitual de como os componentes podem interagir em uma configuração de métricas:

Figura 1. Fontes de dados, processamento e geração de relatórios em uma configuração de métricas.

Componentes da configuração de métricas

É possível usar configurações de métricas para definir tarefas de coleta de dados e pipelines de processamento complexos no dispositivo. Esta seção detalha os componentes principais usados para definir uma campanha de métricas. Os componentes são apresentados na ordem em que os dados fluem pelo sistema, da entrada à saída. É possível definir esses componentes em qualquer ordem. O processamento de dados com agregadores e o gerenciamento do ciclo de vida são opcionais.

• Definir fontes de dados
• Processar dados com agregadores
• Controlar o fluxo de execução com gatilhos
• Gerar relatórios de métricas
• Gerenciar o ciclo de vida da coleta de dados

Definir fontes de dados

A base de qualquer campanha de métricas são os dados. Em uma configuração de métricas, o mecanismo de recebimento de dados é abstraído, e você precisa especificar apenas o nome pelo qual uma fonte de dados pode ser identificada e o modo de conexão (assinatura ou sob demanda). As fontes de dados podem ser qualquer serviço que disponibilize dados pela pilha de comunicações do SDV ou se registre no Registro de editores configuráveis, que permite a coleta de dados de apps em que o middleware do SDV não está disponível. Cada fonte de dados precisa ter um nome exclusivo na configuração para que possa ser referenciada por outros componentes de configuração de métricas, como gatilhos ou agregadores. É possível configurar como ele se conecta, com que frequência recebe dados e fornecer um objeto de configuração específico do serviço.

Configuração de fontes de dados

O serviço de telemetria pode se conectar a uma fonte de dados de duas maneiras:

• Getter:esse método busca dados sob demanda sempre que uma expressão definida na configuração de métricas precisa ler dados dessa fonte. Isso é útil para fontes de dados que não fornecem um fluxo contínuo ou quando você precisa de snapshots de dados pouco frequentes.
• Assinatura:é o método padrão. Ele estabelece um fluxo de dados contínuo da origem. Esse tipo de conexão é necessário se você pretende usar um gatilho de dados que é acionado quando novas mensagens chegam dessa fonte.

Ao usar uma assinatura, você pode configurar:

• Subamostragem:para evitar a ingestão de dados com muita frequência, defina um intervalo de tempo mínimo entre mensagens consecutivas da mesma fonte. Se a fonte publicar dados mais rápido do que esse intervalo, o serviço de telemetria vai limitar as notificações, e os gatilhos de dados serão ativados apenas para mensagens recebidas após a limitação. Isso faz uma subamostragem dos dados.
• Recuperação inicial de mensagens:é possível configurar o serviço para recuperar a mensagem mais recente da origem quando ele estabelecer a assinatura. Como resultado, a fonte de dados é preenchida com um valor imediatamente, se um estiver disponível, em vez de esperar a publicação da primeira nova mensagem. Isso é útil em acionadores ou agregadores condicionais que exigem um estado inicial ou quando a fonte de dados publica com pouca frequência.

Seja qual for o tipo, as mensagens são armazenadas em cache internamente. Se várias expressões ou agregadores precisarem de dados da mesma fonte durante um único ciclo de avaliação, o sistema vai buscar os dados apenas uma vez, seja do cache se uma nova mensagem chegar usando uma assinatura, ou usando uma única chamada sob demanda.

Processar dados com agregadores

Enquanto as fontes de dados fornecem dados brutos, os agregadores realizam o processamento de dados de estado e de borda. Eles consomem dados de fontes de dados ou outros agregadores, transformam esses dados e disponibilizam o resultado para leitura por relatórios de métricas ou processamento adicional por outros agregadores. Isso permite criar pipelines de processamento de várias etapas, por exemplo, calcular estatísticas de velocidade em um agregador e usar essas estatísticas em outro componente que detecta padrões de comportamento de direção.

Os agregadores são acionados para realizar os cálculos por um ou mais acionadores. Cada vez que um dos gatilhos é acionado, o agregador avalia as regras e atualiza o estado interno.

É possível configurar um agregador para redefinir o estado depois que o valor for lido por outro componente, o que é útil para calcular estatísticas em janelas de tempo não sobrepostas.

Um criador de mensagens define a estrutura e a lógica de um agregador. Um criador de mensagens especifica como construir uma instância de uma mensagem proto descrevendo como gerar dados para cada um dos campos. Para cada campo, uma expressão define como ler dados de fontes de dados e agregadores e aplicar operações a esses dados. Além disso, é possível aplicar uma agregação, que é um cálculo ou uma operação de coleta aplicada aos resultados da expressão ao longo do tempo.

Há suporte para os seguintes tipos de agregação:

• Matemática:calcula estatísticas (média, mínimo, máximo, soma, desvio padrão e delta) nos valores retornados por uma expressão em cada acionador. Delta é a diferença entre o valor numérico atual e o anterior retornado por uma expressão.
• Lista:coleta em uma lista os valores retornados por uma expressão. É possível limitar o tamanho da lista para criar uma janela contínua (buffer circular) de valores recentes.
• Contagem:caso especial em que nenhuma expressão é especificada. Conta quantas vezes o campo é avaliado (ou seja, quantas vezes o agregador ou relatório é acionado).
• Passagem direta:usa o resultado de uma expressão diretamente, sem aplicar uma agregação. Isso é útil em configurações de relatórios para acessar valores finais de agregadores.

A figura a seguir é um diagrama conceitual que ilustra a avaliação do agregador:

Figura 2. Avaliação do agregador.

Realizar cálculos ou definir condições usando expressões

As expressões são usadas em criadores de mensagens e acionadores condicionais para realizar cálculos ou definir condições. Ao usar o Gerador de configuração de métricas (MCG) para criar objetos JSON de configuração de métricas, as expressões são escritas como strings legíveis por humanos que usam a notação de ponto para acessar campos da fonte de dados (por exemplo, vehicle_speed.speed_value) e aplicam uma ampla variedade de operações. O MCG traduz essas strings em uma estrutura de árvore otimizada, análoga a uma árvore de sintaxe abstrata (AST), para uma avaliação eficiente no dispositivo na mensagem final do protobuf MetricsConfig.

Operadores e funções

As expressões aceitam o seguinte conjunto de operadores e funções:

• Aritmética:oferece suporte a adição, subtração (binária e unária), multiplicação, divisão, módulo e potência.
• Lógica:oferece suporte a AND, OR, NOT e XOR.
• Relacional:aceita verificação de igualdade e comparação "maior que" e "menor que".
• Lista:verifica se uma lista contém ou não um valor específico.
• Timestamp:retorna o carimbo de data/hora no momento da avaliação em microssegundos. O tipo de relógio pode ser de tempo real, tempo monotônico desde a inicialização (incluindo o tempo de suspensão) ou tempo monotônico desde a inicialização ou a última retomada.
• Valor absoluto:retorna o valor absoluto de um número.
• Arredondamento:arredonda para o número inteiro mais próximo (round), retorna o maior número inteiro menor ou igual a um número (floor) ou retorna o menor número inteiro maior ou igual a um número (ceil).

Confira um exemplo de expressão que lê duas fontes de dados e avalia como true se a velocidade do veículo exceder 100 km/h e não houver um aviso de pressão dos pneus:

(vehicle_speed.speed_value * 3.6) > 100 && tire_pressure.warning == false

Controlar o fluxo de execução com gatilhos

Os gatilhos são os organizadores de uma configuração de métricas. Eles controlam quando os dados são processados e quando os relatórios são gerados. Cada gatilho precisa ter um nome exclusivo.

Há três tipos de gatilhos:

• Gatilhos de dados:são acionados quando uma fonte de dados com uma conexão de assinatura publica uma nova mensagem (após a subamostragem, se configurada).
• Acionadores periódicos:são disparados em um intervalo de tempo fixo.
• Gatilhos condicionais:são disparados quando uma condição lógica especificada é atendida.

Gatilhos condicionais

Os acionadores condicionais ficam atentos a outros acionadores (de dados, periódicos ou outros acionadores condicionais) e, quando um deles é acionado, avaliam uma expressão. O gatilho condicional é disparado somente se o resultado da expressão atender a uma condição específica.

É possível configurar um acionador condicional para disparar com base em vários tipos de condição:

• Valor:quando a expressão é avaliada como true (ou diferente de zero) ou false (ou zero).
• Borda de subida:quando uma expressão booleana muda de false para true ou um valor numérico aumenta.
• Borda de queda:quando uma expressão booleana muda de true para false ou um valor numérico diminui.
• Na mudança:sempre que o resultado da expressão for diferente do valor anterior.

Filtrar mudanças de estado ruidosas

Para gatilhos baseados em borda ou em mudança, é possível filtrar mudanças de estado breves ou ruidosas (falhas) exigindo que a condição permaneça no novo estado por uma duração mínima antes do acionamento.

Por exemplo, é possível configurar um gatilho para ser acionado somente se vehicle_speed > 100 se tornar true e permanecer true por pelo menos 5 segundos. Isso evita que o gatilho seja acionado devido a um pico momentâneo na leitura de velocidade. Você também pode exigir que todos os valores vistos durante esse período de retenção sejam exatamente iguais.

Gerar relatórios de métricas

Depois que os dados são processados, você define como e quando eles são agrupados em relatórios.

Os relatórios são definidos usando configurações de relatório de métricas, que usam criadores de mensagens para definir a estrutura e o conteúdo da saída. Quando um dos gatilhos do relatório é acionado, o criador de mensagens avalia as atribuições de campo para construir o payload de dados do relatório.

Cada relatório gerado é uma instância de uma mensagem MetricsReport Protobuf, que encapsula a saída do criador de mensagens em um campo payload e adiciona metadados. O serviço de telemetria adiciona automaticamente os seguintes metadados a cada MetricsReport:

• Um identificador universalmente exclusivo (UUID) para o relatório.
• Um número de relatório sequencial, que aumenta para cada relatório gerado por essa configuração de relatório.
• O carimbo de data/hora do momento em que o relatório foi gerado
• O motivo da geração (por exemplo, acionada por uma regra ou gerada no desligamento)
• O UUID e a versão da configuração de métricas que gerou o relatório
• O nome da configuração do relatório de métricas

Controle de geração de relatórios

Embora os relatórios sejam gerados em resposta a acionadores, também é possível configurá-los para serem gerados em momentos específicos do ciclo de vida da configuração das métricas:

• Relatório sobre a ativação:se ativado, o sistema gera um relatório inicial imediatamente quando a configuração de métricas é ativada.
• Relatório final:se ativado, o sistema gera um relatório final quando a coleta de dados é pausada ou interrompida ou quando o serviço de telemetria é desligado. Esse relatório contém os dados agregados até esse ponto, ajudando a garantir que nenhum dado seja perdido no final de uma sessão.

Gerenciar o ciclo de vida da coleta de dados

Por padrão, uma configuração de métricas começa a coletar e processar dados assim que é ativada por um cliente e continua até ser desativada por ele. No entanto, é possível controlar esse ciclo de vida de maneira mais granular definindo gatilhos que iniciam ou interrompem a coleta de dados ou a configuração de métricas:

• Acionador de início:se definido, a coleta de dados começa apenas quando esse acionador é disparado. Se a coleta tiver sido pausada por um gatilho de parada, o gatilho de início vai retomar o processo.
• Gatilho de parada:se definido, esse gatilho pausa a coleta de dados. As agregações e a geração de relatórios são interrompidas até que o gatilho de início seja acionado novamente.
• Desativar gatilho:esse gatilho desativa a configuração de métricas da mesma forma que uma chamada deactivate_metrics_config do cliente.

Por exemplo, é possível definir um gatilho condicional que é acionado quando vehicle_state muda para DRIVING como gatilho de início e outro que é acionado quando vehicle_state muda para PARKED como gatilho de parada. Isso ajuda a garantir que os dados sejam coletados apenas enquanto o veículo está em movimento.