Error Status Management
Error Profiles General Structure
To provide greater clarity, we will analyze the default error profile that Aurora Vision creates for each portfolio (which cannot be edited ).
On Aurora Vision an error profile is always identified by a Name, an Acronym and a Creator and contains within it a series of Error Categories which have the purpose of evaluating the presence of error events for the plants to which the profile is assigned thus generating the activation of Profile
events:
The administrator of a portfolio, according to his needs and the plants to which the error profile must be associated, has complete freedom in creating error profiles and adding specific error categories within it and can also decide the evaluation parameters for each of the error categories.
There are 4 main parameters that can be edited:
- Elapsed Time: indicates the time that must pass before Aurora Vision, once the error has been detected, raises it to show it as active to the hierarchical levels concerned. The minimum value that can be assigned, to avoid the triggering of false errors, is 15 minutes;
- Evaluation: indicates the time window for which Aurora Vision will evaluate the presence or absence of errors related to that particular category, according to the parameters set. Different time windows can be chosen, but it must be kept in mind that outside the defined window Aurora Vision will not evaluate that specific error category belonging to that error profile;
- Severity: indicates the severity of the error, which is mapped one-to-one with the
Status
of the hierarchical entity affected by the error. There are 4 levels of severity:INFO
(informational event ),LOW
(low severity event ),MEDIUM
(medium severity event ),HIGH
(high severity event ); - Threshold: the error event is activated only if the indicated threshold is exceeded. This parameter is not present for all categories of errors (for more details please refer to Page 3 ).
For example the Power Off
(PWROFF
) error is composed of the following parameters:
- Elapsed Time: 8 hours
- Evaluation: During Daylight – 2 hours after sunrise and before sunset
- Severity: MEDIUM
- Threshold: 100 W/m2
This means that Aurora Vision will evaluate the presence of a PWROFF
error event only during daylight, two hours after sunrise and two hours before sunset; it will activate the error only if the threshold exceeds 100 W/m2 and it will do so 8 hours after detection, bringing the Status
of the hierarchical entities concerned to MEDIUM
, in accordance with the set severity.
Error profiles are always assigned to plants and, consequently, the Status
of an entity can only change from this hierarchical level onwards; however, there are error categories evaluated only at the Plant level (LVL 3
) and/or at the Logger level (LVL 4
) and/or at the Device level (LVL 5
). When an error is identified and activated at a certain hierarchical level, it is propagated to all the hierarchically superior entities (ranging from plant level onwards ) and this therefore means that the Status
of these entities is uniformly changed.
Let’s take a look at an example:
Entities Status Hierarchical Propagation
Let’s take as an example a part of the hierarchical scheme of the chapter “Hierarchical Structure” and let’s suppose that Plant 1 has been assigned to the default error profile:
For Inverter 1, at a certain moment in time, a PWROFF
error was triggered; this means that its Status
has passed from NORMAL
(no errors ) to MEDIUM
(according to the severity assigned by the default profile to the PWROFF error ).
However, Inverter 1 is part of a hierarchy which, if scaled-up, is made up of Logger 1 and Plant 1.
As a consequence, remembering that an error profile is assigned from plant hierarchy level onwards, the Status
of Logger 1 and Plant 1 has also passed from NORMAL
to MEDIUM
.
The example above makes us understand that a summary evaluation of the presence/absence of errors can be made directly at the plant hierarchical level. More details will be available on Page 4, where we will analyze a concrete example of the GET Plant Status
API.