Gerenciamento Status de Erro

Estrutura Geral dos Perfis de Erro

Para maior clareza, analisaremos o perfil de erro padrão que o Aurora Vision cria para cada portfólio (que não pode ser editado ).

No Aurora Vision, um perfil de erro é sempre identificado por um Nome, un Acrônimo e um Criador e contém uma série de Categorias de Erro que têm a finalidade de avaliar a presença de eventos de erro para as usinas às quais o perfil está atribuído, gerando assim a ativação de eventos de Profile :

O administrador de um portfólio, de acordo com suas necessidades e as plantas às quais o perfil de erro deve estar associado, tem total liberdade para criar perfis de erro e adicionar categorias de erro específicas dentro dele, podendo ainda decidir os parâmetros de avaliação para cada um dos categorias de erro.

Existem 4 parâmetros principais que podem ser editados:

  • Tempo Decorrido: indica o tempo que deve passar antes que o Aurora Vision, uma vez detectado o erro, o eleva para mostrá-lo como ativo aos níveis hierárquicos envolvidos. O valor mínimo que pode ser atribuído, para evitar o acionamento de falsos erros, é de 15 minutos;
  • Avaliação: indica a janela de tempo para a qual o Aurora Vision avaliará a presença ou ausência de erros relacionados a essa categoria em particular, de acordo com os parâmetros definidos. Diferentes janelas de tempo podem ser escolhidas, mas deve-se ter em mente que fora da janela definida, o Aurora Vision não avaliará essa categoria de erro específica pertencente a esse perfil de erro;
  • Gravidade: indica a gravidade do erro, que é mapeado um a um com o Status da entidade hierárquica afetada pelo erro. Existem 4 níveis de gravidade: INFO (evento informativo ), LOW (evento de baixa gravidade ), MEDIUM (evento de gravidade média ), HIGH (evento de alta gravidade );
  • Limiar: o evento de erro é ativado somente se o limite indicado for excedido. Este parâmetro não está presente para todas as categorias de erros (para mais detalhes, consulte a Página 3 ).

Por exemplo, o erro Power Off (PWROFF) é composto pelos seguintes parâmetros:

  • Elapsed Time: 8 hours
  • Evaluation: During Daylight – 2 hours after sunrise and before sunset
  • Severity: MEDIUM
  • Threshold: 100 W/m2

Isso significa que o Aurora Vision avaliará a presença de um evento de erro PWROFF somente durante o dia, duas horas após o nascer do sol e duas horas antes do pôr do sol; ele ativará o erro somente se o limite exceder 100 W/m2 e o fará 8 horas após a detecção, trazendo o Status das entidades hierárquicas em questão para MEDIUM, de acordo com a gravidade definida.

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; no entanto, existem categorias de erro avaliadas apenas no Plant level (LVL 3) e/ou no the Logger level (LVL 4) e/ou no Device level (LVL 5). Quando um 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 é alterado uniformemente.

Vamos dar uma olhada em um exemplo:

Propagação Hierárquica de Status de Entidades

Tomemos como exemplo uma parte do esquema hierárquico do capítulo “Estrutura Hierárquica” e vamos supor qtenha sido atribuída ao perfil de erro padrão:


Para Inverter 1, em um determinado momento, um erro PWROFF foi acionado; isso significa que seu Status passou de NORMAL (sem erros ) para MEDIUM (de acordo com o gravidade atribuída pelo perfil padrão ao erro PWROFF ).
No entanto, Inverter 1 faz parte de uma hierarquia que, se salendo, é composta de Logger 1 e Plant 1.
Como consequência, lembrando que um perfil de erro é atribuído a partir do nível de hierarquia da planta, o Status do Logger 1 e Plant 1 também passou de NORMAL para MEDIUM.

O exemplo acima nos faz entender que um resumo avaliação da presença/ausência de erros pode ser feita diretamente no nível hierárquico da planta. Mais detalhes estarão disponíveis na Página 4, onde analisaremos um exemplo concreto da API GET Plant Status.

Pages: 1 2 3 4