Analisador

Os analisadores são entidades de configuração que definem como as mensagens de uma classe de mensagem de origem específica são analisadas e transformadas em registros de um tipo de destino específico.

Uma configuração de analisador tem os três componentes a seguir:

1. Associação de classe de mensagem de origem: um analisador processa mensagens de origem de uma única classe de mensagem de origem. Para mais informações, consulte Classes de mensagens de origem.
2. Associação de versão de tipo: um analisador emite registros proto de uma única versão de tipo. A configuração da versão do tipo define quais campos precisam estar presentes no registro proto emitido e determina a estrutura deles (esquema). Para mais informações, consulte Tipo.
3. Script do Whistle: os scripts do Whistle definem como transformar mensagens de origem em registros proto usando lógica de mapeamento, análise e transformação. Os scripts do Whistle são escritos pelos usuários, mas o Manufacturing Data Engine (MDE) fornece pacotes de configuração para casos de uso típicos. Para mais informações, consulte a seção a seguir.

Definição de apito

O Whistle é uma linguagem de mapeamento que pode ser usada para converter dados aninhados complexos de um esquema para outro. Na indústria, os modelos de dados podem ser complexos e conter muitas estruturas aninhadas e repetidas. Isso dificulta a expressão da lógica de mapeamento em um formato procedural. O Whistle resolve esse problema fornecendo uma linguagem declarativa que permite definir a lógica de mapeamento e transformação de maneira natural.

Por exemplo, é possível usar o Whistle para harmonizar vários modelos de dados de sensores em diferentes fábricas em um modelo unificado de tipo MDE. Os dados de origem podem conter estruturas aninhadas, como uma lista de componentes ou uma hierarquia de recursos. O Whistle permite expressar a lógica de mapeamento dessas estruturas aninhadas de maneira natural, sem precisar escrever código procedural.

O Whistle também oferece suporte a funções que permitem dividir mapeamentos complexos que envolvem estruturas repetidas em funções. Isso facilita a compreensão e a manutenção do código de mapeamento, além de facilitar a reutilização.

O Whistle oferece benefícios em relação às abordagens processuais. Veja o exemplo a seguir:

Aviso: este exemplo usa código incompleto para fins de demonstração e não tem garantia de funcionamento.

Considerando este payload de amostra:

{
  "payload": {
    "tag": "vibration-sensor"
  },
  "details": {
    "value": 0.24,
    "timestamp": "2023-06-26 12:19:20.046000 UTC"
  }
}

E o seguinte script do Whistle:

package mde

[{
    tagName: $root.payload.tag
    timestamps: {
        eventTimestamp: $root.details.timestamp
    }
    data: {
        numeric: $root.details.value
    }
}]

Aplicando o script Whistle anterior, o analisador geraria um registro proto como este:

[
  {
    "tagName": "vibration-sensor",
    "timestamps": {
      "eventTimestamp": "2023-06-26 12:19:20.046000 UTC"
    },
    "data": {
      "value": 0.24
    }
  }
]

Para mais informações sobre a sintaxe da linguagem Whistle e as funções disponíveis, consulte a documentação do Whistle.

Comportamento do ambiente de execução dos analisadores

Em tempo de execução, o analisador recebe todas as mensagens da classe de mensagem de origem com que está associado, aplica o script do Whistle configurado em cada mensagem e emite um ou mais registros proto do tipo configurado.

Os registros de protocolo emitidos precisam estar em conformidade com a configuração de tipo. Se não obedecerem, elas serão movidas para a fila de mensagens inativas.

Regras de associação

Um analisador só pode ser associado a uma única classe de mensagem e a um único tipo de versão. No entanto, um analisador pode emitir um ou mais registros, desde que sejam da versão de tipo a que ele está vinculado. A saída de um analisador é uma matriz de objetos de registro proto.

Emitir mais de um registro de um analisador é útil em cenários em que uma mensagem de origem contém uma matriz de leituras ou eventos que você quer desagregar. Os analisadores permitem "dividir" a mensagem de origem em vários registros proto para que cada leitura, por exemplo, se torne uma linha em uma tabela de registros no BigQuery.

Os registros proto emitidos podem fazer referência a qualquer nome de tag. Esse comportamento é uma mudança em relação às v1.1 e v1.2, em que os nomes das tags eram definidos para o tipo. Depois da v1.3, os registros proto do MDE emitidos por qualquer analisador podem

Esquema de registro proto

O esquema JSON a que os registros proto precisam obedecer depende de:

1. Arquétipo: o arquétipo específico associado ao tipo.
2. Configuração de tipo: as configurações definidas para o tipo.

O arquétipo define o esquema de base para registros. Por exemplo, um tipo na família de arquétipos discrete exige que os registros proto contenham valores para os seguintes atributos:

• tagName
• timestamps.eventTimestamp
• data.complex

O tipo pode impor mais restrições aos registros do protocolo. Por exemplo, é possível definir um esquema para o campo data ou exigir que os registros proto forneçam uma referência a uma instância de metadados.

Para mais informações, consulte a referência de registro proto.

Pesquisa de dados de referência

O MDE oferece uma função Whistle personalizada para pesquisar um valor para uma chave fornecida em um intervalo de pesquisa.

É possível pesquisar uma instância de bucket de pesquisa pela chave natural chamando a função mde::lookupByKey em um script do Whistle. A função usa o lookupbucketName, bucketVersion e naturalKey da instância como argumentos e retorna a instância de metadados mais recente para a chave natural fornecida. É possível usar a instância para preencher campos em um registro proto no analisador. Exemplo:

"data" : {
  "complex" : {
    "VIN" : mde::lookupByKey("vin-lookup-bucket", input.vinKey, 1).VIN,
    "vin_registration_time" : mde::lookupByKey("vin-lookup-bucket", input.vinKey, 1).vin_registration_time,
    "ResultValue" : 163.0482614,
  }
}

Aviso: o exemplo anterior usa código incompleto para fins de demonstração e pode não funcionar.

Restrições de nomenclatura para analisadores

Um nome de analisador pode conter:

• Letras (maiúsculas e minúsculas), números e os caracteres especiais - e _.
• Pode ter até 255 caracteres.

Você pode usar a seguinte expressão regular para validação: ^[a-z][a-z0-9\\-_]{1,255}$.

Se você tentar criar uma entidade que viole as restrições de nomenclatura, vai receber um 400 error.

Use a função mde::sanitizeTagName() para garantir que seu nome esteja em conformidade com as restrições de nomenclatura. Para mais informações, consulte Funções do Whistle MDE.