Gestión Estado Error
Estructura General de los Perfiles de Error
Para brindar mayor claridad, analizaremos el perfil de error predeterminado que crea Aurora Vision para cada portfolio (que no se puede editar ).
En Aurora Vision, un perfil de error siempre se identifica con un Nombre, un Acrónimo y un Creador y contiene dentro de él una serie de Categorías de Error las cuales tienen como finalidad evaluar la presencia de eventos de error para las plantas a las que se les asigna el perfil generando así la activación de eventos Profile
:
El administrador de un portfolio, según sus necesidades y las plantas a las que debe asociar el perfil de error, tiene total libertad para crear perfiles de error y añadir categorías de error específicas dentro del mismo y también puede decidir los parámetros de evaluación para cada uno de los categorías de error.
Hay 4 parámetros principales que se pueden editar:
- Tiempo Transcurrido: indica el tiempo que debe transcurrir antes de que Aurora Vision, una vez detectado el error, lo levante para mostrarlo como activo a los niveles jerárquicos correspondientes. El valor mínimo que se puede asignar, para evitar la activación de falsos errores, es de 15 minutos;
- Evaluación: indica la ventana de tiempo en la que Aurora Vision evaluará la presencia o ausencia de errores relacionados con esa categoría en particular, de acuerdo con los parámetros establecidos. Se pueden elegir diferentes ventanas de tiempo, pero se debe tener en cuenta que fuera de la ventana definida Aurora Vision no evaluará esa categoría de error específica perteneciente a ese perfil de error;
- Gravedad:indica la gravedad del error, que se asigna uno a uno con el
Status
de la entidad jerárquica afectada por el error. Hay 4 niveles de gravedad:INFO
(evento informativo ),LOW
(evento de baja gravedad ),MEDIUM
(evento de gravedad media ),HIGH
(evento de gravedad alta ); - Umbral: el evento de error se activa solo si se supera el umbral indicado. Este parámetro no está presente para todas las categorías de errores (para obtener más detalles, consulte la Página 3 ).
Por ejemplo, el error Power Off
(PWROFF
) se compone de los siguientes parámetros:
- Elapsed Time: 8 hours
- Evaluation: During Daylight – 2 hours after sunrise and before sunset
- Severity: MEDIUM
- Threshold: 100 W/m2
Esto significa que Aurora Vision evaluará la presencia de un evento de error PWROFF
solo durante el día, dos horas después del amanecer y dos horas antes del atardecer; activará el error solo si el umbral supera los 100 W/m2 y lo hará 8 horas después de la detección, llevando el Status
de las entidades jerárquicas afectadas a MEDIUM
, de acuerdo con la severidad configurada.
Los perfiles de error siempre se asignan a las plantas y, en consecuencia, el Status
de una entidad solo puede cambiar a partir de este nivel jerárquico; sin embargo, hay categorías de error evaluadas solo a Plant level (LVL 3
) y/o a the Logger level (LVL 4
) y/o a Device level (LVL 5
). Cuando se identifica y activa un error en un determinado nivel jerárquico, se propaga a todas las entidades jerárquicamente superiores (desde el nivel de planta en adelante ) y esto significa que el Status
de estas entidades se cambia uniformemente.
Veamos un ejemplo:
Propagación Jerárquica del Estado de Entidades
Tomemos como ejemplo una parte del esquema jerárquico del capítulo «Estructura jerárquica» y supongamos que la Plant 1 ha sido asignada al perfil de error por defecto:
Para Inverter 1, en un momento determinado, se activó un error PWROFF
; esto significa que su Status
ha pasado de NORMAL
(sin errores ) a MEDIUM
(según el gravedad asignada por el perfil predeterminado al error PWROFF ).
Sin embargo, Inverter 1 es parte de una jerarquía que, si se subes, se compone de Logger 1 y Plant 1.
En consecuencia, recordando que se asigna un perfil de error a partir del nivel de jerarquía de la planta, el Status
de Logger 1 y Plant 1 también ha pasado de NORMAL
a MEDIUM
.
El ejemplo anterior nos hace entender que un resumen evaluación de la presencia/ausencia de errores se puede realizar directamente en el nivel jerárquico de la planta. Habrá más detalles disponibles en la Página 4, donde analizaremos un ejemplo concreto de la API GET Plant Status
.