Fehler Status Verwaltung

Allgemeine Struktur der Fehlerprofile

Um mehr klarheit zu schaffen, werden wir das standardfehlerprofil analysieren, das Aurora Vision für jedes portfolio erstellt (das nicht bearbeitet werden kann ).

Auf Aurora Vision wird ein Fehlerprofil immer durch einen Namen, ein Akronym und einen Ersteller identifiziert und enthält darin eine reihe von Fehlerkategorien die dazu dienen, das Vorliegen von Fehlerereignissen für die Anlagen, denen das Profil zugeordnet ist, auszuwerten und so die Aktivierung von Profile ereignissen zu erzeugen:

Der Administrator eines portfolios hat je nach seinen bedürfnissen und den Anlagen, denen das fehlerprofil zugeordnet werden muss, völlige freiheit bei der erstellung von fehlerprofilen und dem hinzufügen spezifischer fehlerkategorien darin und kann auch die bewertungsparameter für jedes einzelne festlegen fehlerkategorien.

Es gibt 4 hauptparameter, die bearbeitet werden könnens that can be edited:

  • Verstrichene Zeit: gibt die zeit an, die vergehen muss, bevor Aurora Vision, sobald der fehler erkannt wurde, ihn anhebt, um ihn den betroffenen hierarchieebenen als aktiv anzuzeigen. Der mindestwert, der zugewiesen werden kann, um das Auslösen falscher fehler zu vermeiden, beträgt 15 minuten;
  • Bewertung: gibt das zeitfenster an, für das Aurora Vision die anwesenheit oder abwesenheit bewertet von fehlern in bezug auf diese bestimmte kategorie gemäß den eingestellten parametern. Es können verschiedene zeitfenster gewählt werden, aber es muss beachtet werden, dass Aurora Vision außerhalb des definierten fensters diese spezifische fehlerkategorie, die zu diesem fehlerprofil gehört, nicht auswertet;
  • Schweregrad: gibt den schweregrad des fehlers an, der eins zu eins dem Status der vom fehler betroffenen hierarchischen entität zugeordnet wird. Es gibt 4 schweregrade: INFO (informationsereignis ), LOW (ereignis mit niedrigem schweregrad ), MEDIUM (ereignis mit mittlerem schweregrad ), HIGH (ereignis mit hohem schweregrad );
  • Schwellenwert: Das fehlerereignis wird nur aktiviert, wenn der angegebene schwellenwert überschritten wird. Dieser parameter ist nicht bei allen fehlerkategorien vorhanden (weitere details finden Sie auf Seite 3 ).

Zum beispiel setzt sich der fehler Power Off (PWROFF) aus den folgenden parametern zusammen:

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

Das bedeutet, dass Aurora Vision das Vorhandensein eines PWROFF fehlerereignisses nur bei tageslicht, zwei stunden nach sonnenaufgang und zwei stunden vor sonnenuntergang auswertet; es aktiviert den fehler nur, wenn der schwellenwert 100 W/m2 überschreitet, und zwar 8 stunden nach der erkennung, wodurch der Status der betroffenen hierarchischen einheiten auf MEDIUM, entsprechend dem eingestellten schweregrad.

Fehlerprofile sind immer werken zugeordnet und folglich kann sich der Status einer entität erst ab dieser hierarchieebene ändern; Es gibt jedoch fehlerkategorien, die nur auf Plant Level (LVL 3) und/oder auf Logger level (LVL 4) und/oder auf Device level (LVL 5). Wenn ein fehler auf einer bestimmten hierarchischen ebene erkannt und aktiviert wird, wird dieser an alle hierarchisch übergeordneten einheiten (ab werksebene ) weitergegeben und dies führt dazu, dass die Status dieser entitäten wird einheitlich geändert.

Schauen wir uns ein beispiel an:

Hierarchische Weitergabe des Status von Entitäten

Nehmen wir als Beispiel einen Teil des hierarchischen Schemas aus dem Kapitel „Hierarchische Struktur“ und nehmen wir an, dass Plant 1 dem standardfehlerprofil zugewiesen wurde:


Für Inverter 1,wurde zu einem bestimmten zeitpunkt ein PWROFF fehler ausgelöst; das bedeutet, dass sein Status von NORMAL (keine fehler ) auf MEDIUM (gemäß der schweregrad, der vom standardprofil dem PWROFF-fehler zugewiesen wird ).
Jedoch ist, Inverter 1 teil einer hierarchie, die, wenn sie hochskaliert wird, aus Logger 1 und Plant 1.
Folglich, wenn man bedenkt, dass ein fehlerprofil ab anlagenhierarchieebene zugewiesen wird, der Status von Logger 1 und Plant 1 ist ebenfalls von NORMAL auf MEDIUM.

Das obige beispiel macht uns verständlich, dass eine zusammenfassung die bewertung des vorhandenseins/fehlens von fehlern kann direkt auf der anlagenhierarchieebene erfolgen. Weitere details finden sie auf Page 4, wo wir ein konkretes beispiel der API GET Plant Status analysieren werden.

Seiten: 1 2 3 4