Gerenciamento Status de Erro

Avaliação de Status de Entidades e Eventos de Erro

Conforme mencionado na Página 2, os perfis de erro são sempre atribuídos às plantas e, consequentemente, o Status de uma entidade só pode mudar a partir deste nível hierárquico. Quando um evento de erro é identificado e ativado em um determinado nível hierárquico, ele é propagado para todas as entidades hierarquicamente superiores (desde o nível da planta em diante) e isso significa que o Status dessas entidades é uniformemente alterada; esse comportamento é identificado como o princípio de propagação de status hierárquico.

A GET Status API permite obter o Status de uma Plant, Logger e/ou Device (dependendo do nível hierárquico e da suíte).
A peculiaridade desta API é sua resposta dinâmica: ela sempre retorna a explosão de todas as entidades hierarquicamente inferiores cujo Status é diferente de NORMAL, indicando quais são afetados por eventos de erro ativos (mas não o tipo de erro do evento real).

Vamos usar o seguinte esquema hierárquico como exemplo e supor que queremos verificar o Status da Plant 1, para entender se pode haver algum evento de erro ativo:

No nível hierárquico da planta, vamos chamar a API GET Plant Status:

https://api.auroravision.net/api/rest/v1/plant/{entityID}/status

Se não houver nenhum evento de erro ativo, obteremos uma resposta na qual o Status da Plant 1 será igual a NORM (que é equivalente a NORMAL):

Se houver pelo menos um evento de erro ativo, significa que pelo menos um dos dispositivos registrados na Plant 1, que são, portanto, filhos hierárquicos desta última, possui um evento de erro ativo associado; neste caso, a resposta da API se adapta dinamicamente explodindo o Status de Plant 1 mas também de todas as entidades filhas hierárquicas cujo Status é diferente de NORM:

Podemos ver como a resposta agora está mais estruturada e como o Status da Plant 1 agora é igual a MEDIUM, um sintoma de que um evento de erro está ativo para alguns entidades de nível hierárquico inferior. Este evento de erro está ativo para Inverter 1, porque a API nos fornece uma resposta explodida para todos os níveis hierárquicos, desde Plant 1 (LVL 3) para Inverter 1 (LVL 5). O Status de todas as três entidades é, portanto, igual a MEDIUM, devido ao princípio de propagação hierárquica que mencionamos no topo da página.

O princípio de manipulação de uma resposta dinâmica por uma API GET Status também está presente em níveis hierárquicos inferiores.
Se para o exemplo acima vamos chamar GET Logger Status, a resposta retornada será:

Podemos ver como a resposta tem exatamente a mesma estrutura que a obtida com a API GET Plant Status, onde tanto Logger 1 quanto Inverter 1 têm seu Status igual a MEDIUM. A única diferença é a presença de um nível hierárquico a menos (porque temos recursos direcionados de um nível hierárquico inferior).

Vimos, portanto, como se aplica o princípio da propagação hierárquica: qualquer dispositivo que tenha um evento de erro ativo, que faça com que seu Status seja diferente de NORMAL, altera simultaneamente o Status de todas as entidades hierarquicamente superiores (desde o nível da planta em diante). Isso permite discriminar imediatamente a presença ou ausência de erros simplesmente explorando a API GET Plant Status.

Obviamente, depois de verificarmos a presença de eventos de erro, estamos interessados ​​em saber quais são esses eventos de erro. Para isso podemos usar a API GET Events que permite obter os eventos de erro de uma Plant, Logger e/ou Device (dependendo do nível hierárquico que nos interessa) com filtragem avançada em: categoria, tipo, estado e ocorrência.

Vamos dar uma olhada na solicitação de API completa e, em seguida, vamos dividi-la para analisá-la em detalhes:

https://api.auroravision.net/api/rest/v1/{plant,logger,device}/{entityID}/events?eventsKind={Profile,Source}&eventsType={eventsType}&eventsState={ALL,ACTIVE,CLOSED}&eventsOccurrence={H24,D7,D30}&page={pageNumber}

O path, que permite apontar para os recursos desejados, se, com base no nível hierárquico e na suíte em que você está, pode ser um Plant, Logger ou Device EID:

https://api.auroravision.net/api/rest/v1/{plant,logger,device}/{entityID}/events

A API sempre requer o parâmetro de consulta {eventsKind} para discriminar o tipo de evento de erro a ser chamado.
Esse parâmetro pode ter dois valores diferentes:

  • Profile: permite obter eventos de erro do tipo perfil, ou seja, aqueles que são ativados pelo Aurora Vision com base no perfil de erro, com suas regras configuradas, associadas à planta considerada (ou para um dos dispositivos hierarquicamente filhos deste último)
  • Source: permite obter eventos de erro do tipo fonte, ou seja, erros de máquina identificados por um dispositivo e que são então comunicados à Aurora Vision (que os modela com base no dispositivo que os enviou)

Dissemos anteriormente que a ativação de um erro, pertencente a qualquer categoria definida em um Perfil de Erro, pode depender da presença/ausência de dados e/ou eventos de origem. Eventos de erro de Profile podem ser ativados quando condições específicas são detectados nos dados ou quando um dispositivo comunica ao Aurora Vision a identificação de um evento de erro Source que se enquadra em uma das categorias de erro do perfil. Considerando que os eventos de origem são mais difíceis de entender que os de perfil, pois são compostos por abreviações que podem variar de dispositivo para dispositivo, e que o Aurora Vision gerencia implicitamente a modelagem desses eventos em categorias de erro para ativar o erro de perfil correto evento, é aconselhável sempre filtrar a API da seguinte forma:

https://api.auroravision.net/api/rest/v1/{plant,logger,device}/{entityID}/events?eventsKind=Profile

Embora o resto dos queryParameters não sejam necessários para obter uma resposta, ao trabalhar com eventos de erro é sempre útil poder filtrar tipo, ocorrência e estado:

  • eventsTypepermite filtrar o tipo de eventos de erro do perfil; apenas um tipo de evento de erro pode ser filtrado por vez (para obter uma tabela completa sobre os tipos de eventos de erro, consulte a Página 4). Caso não seja inserido na API, todos os tipos de eventos serão retornados;
  • eventsOccurrence: permite filtrar a ocorrência de eventos de erro; os valores aceitos são 24H, para uma janela de 24 horas, 7D, para um tempo janela de 7 dias, ou 30D, para um tempo janela de 30 dias. Caso não seja inserido na API, todos os eventos que cobrem a vida útil da planta serão retornados;
  • eventsState: permite filtrar o estado dos eventos de erro; os valores aceitos são ACTIVE, para eventos ativos que, portanto, não possuem uma singularidade temporal de fechamento, CLOSED, para eventos fechados, ou ALL, para solicitação eventos ativos e fechados ao mesmo tempo. Caso não seja inserido na API, todos os eventos ativos e fechados serão retornados;

Neste ponto, temos todas as ferramentas para entender quais eventos de erro estão ativos para Plant 1:

https://api.auroravision.net/api/rest/v1/plant/12345678/events?eventsKind=Profile&eventsOccurrence=24H&eventsState=ACTIVE

Nos colocamos no nível hierárquico plant, inserindo o EID da Plant 1 (12345678), solicitando eventos de erro ACTIVE em as últimas 24H:

Podemos ver pela resposta que dois eventos de erro de tipo de perfil estão ativos: um DEVCOM para Inverter 1 e um LOGCOM para Logger 1. Os dois eventos de erro são ativados em momentos diferentes e, referindo-se às definições, podemos supor que o Inverter 1 parou de enviar dados para o Logger 1 em eventStart; o último ainda estava se comunicando corretamente com o Aurora Vision, mas posteriormente parou de fazê-lo em eventStart.

O princípio da propagação hierárquica de status também é válido para este tipo de API, confirmando assim que quando um evento de erro é identificado e ativado em um determinado nível hierárquico, ele é propagado para todas as entidades hierarquicamente superiores; isso significa que um evento de erro que afeta um dispositivo também é exibido no nível hierárquico da planta, como podemos perceber claramente no exemplo dado acima.

Pages: 1 2 3 4