Hiba Állapot Menedzsment

Az entitások állapotának és hibaeseményeinek értékelése

Amint azt a Oldal 2,említettük, a hibaprofilok mindig az üzemekhez vannak rendelve, és ennek következtében az entitás Status csak ettől a hierarchikus szinttől kezdve változhat. Ha egy hibaeseményt azonosítanak és aktiválnak egy bizonyos hierarchikus szinten, akkor az összes hierarchikus felsőbbrendű entitáshoz eljut (az üzemi szinttől kezdve) és ez azt jelenti, hogy az Status ezek entitásai egységesen megváltoznak; ezt a viselkedést a hierarchikus állapotterjesztés elveként azonosítják.

A GET Status API lehetővé teszi egy Status a Plant, Logger és/vagy Device (a hierarchikus szinttől és a csomagtól függően).
Ennek az API-nak a sajátossága a dinamikus válasz: mindig visszaadja a hierarchikusan alacsonyabb entitások robbanását, amelyeknek Status eltér a NORMAL, ól, így azt jelzi, hogy melyeket érintik az aktív hibaesemények (de nem az esemény tényleges hibatípusát).

Vegyük példának a következő hierarchikus sémát, és tegyük fel, hogy ellenőrizni akarjuk az Status az Plant 1, hogy megértsük, vannak-e aktív hibaesemények:

Az üzem hierarchikus szintjén hívjuk meg a GET Plant Status API:

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

Ha nincs aktív hibaesemény, akkor olyan választ kapunk, amelyben az Status az Plant 1 egyenlő lesz a NORM (értékkel ami egyenértékű a NORMAL):

Ha van legalább egy aktív hibaesemény, az azt jelenti, hogy az Plant 1, regisztrált eszközök legalább egyikéhez, amelyek tehát az utóbbi hierarchikus utódjai, aktív hibaesemény van társítva; ebben az esetben az API válasza dinamikusan alkalmazkodik az Status az Plant 1 jának felrobbanásával, de az összes olyan hierarchikus alárendelt entitáséval is, amelyek Status különbözik a NORM:

Láthatjuk, hogyan strukturáltabb a válasz, és hogy az Plant 1 állapota most egyenlő a MEDIUM, értékkel, ami azt jelzi, hogy bizonyos esetekben egy hibaesemény aktív alacsonyabb hierarchikus szintű entitások. Ez a hibaesemény az Inverter 1, esetében aktív, mivel az API robbantott választ ad nekünk az Plant 1 (LVL 3) kezdve minden hierarchikus szinten az Inverter 1 (LVL 5). Ezért mindhárom entitás Status oegyenlő a MEDIUM, értékkel, a hierarchikus terjedés elve miatt, amelyet az oldal tetején említettünk.

A dinamikus válaszok GET Status API-val történő kezelésének elve az alacsonyabb hierarchikus szinteken is jelen van.
Ha a fenti példában a GET Logger Status fogjuk hívni, a visszaküldött válasz a következő lesz:

Láthatjuk, hogy a válasz pontosan ugyanolyan szerkezetű, mint a GET Plant Status API val kapott válasz, ahol a Logger 1 és az Inverter 1 egyaránt Status egyenlő a MEDIUM értékkel. Az egyetlen különbség az eggyel kevesebb hierarchikus szint jelenléte (mert alacsonyabb hierarchikus szintű célzott erőforrásaink vannak).

Ezért láttuk, hogyan érvényesül a hierarchikus terjedés elve: minden olyan eszköz, amelynek aktív hibaeseménye van, ami miatt az Status eltér a NORMAL, egyidejűleg megváltoztatja a az összes hierarchikusan felsőbbrendű entitás Status (az üzemi szinttől kezdve). Ez lehetővé teszi a hibák meglétének vagy hiányának azonnali megkülönböztetését a GET Plant Status API kihasználásával.

Nyilvánvalóan, ha megbizonyosodtunk a hibaesemények jelenlétéről, kíváncsiak vagyunk arra, hogy mik ezek a hibaesemények. Ehhez használhatjuk a GET Events API amely lehetővé teszi egy Plant, Logger és/vagy Device hibaesemények beszerzését (attól függően, hogy milyen hierarchikus szintre vagyunk kíváncsiak) speciális szűréssel: kategória, típus, állapot és előfordulás.

Nézzük meg a teljes API-kérést, majd bontsuk le, hogy részletesen elemezhessük:

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}

Az path, amely lehetővé teszi, hogy a kívánt erőforrásokra mutasson, mindig megkövkódot, és a hierarchikus szinttől és a programcsomagtól függően lehet Plant, Logger vagy Device EID:

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

Az API mindig szüksége van az {eventsKind} lekérdezési paraméterre, hogy meg tudja különböztetni a meghívandó hibaesemények típusát.
Ennek a paraméternek két különböző értéke lehet:

• Profile: lehetővé teszi a profiltípusú hibaesemények beszerzését, azaz azokat, amelyeket az Aurora Vision a hibaprofil alapján aktivál, annak konfigurált szabályaival, a vizsgált üzemhez társítva (vagy az egyik eszközhöz hierarchikusan az utóbbi gyermekei)
• Source: lehetővé teszi a forrás típusú hibaesemények beszerzését, azaz az eszköz által azonosított géphibákat, amelyek ezután közöljük az Aurora Vision (amely a küldő eszköz alapján modellezi őket)

Korábban azt mondtuk, hogy a hibaprofilban meghatározott bármely kategóriába tartozó hiba aktiválása az adatok és/vagy a forrásesemények meglététől/hiányától függhet. Profile hibaesemények aktiválhatók, ha bizonyos feltételek észlelik az adatokon, vagy amikor egy eszköz közli az Aurora Visionnal egy Source hibaesemény azonosítását, amely a profilhiba kategóriák egyikébe esik. Figyelembe véve, hogy a forrásesemények nehezebben érthetők, mint a profilesemények, mivel rövidítésekből állnak, amelyek eszközről eszközre változhatnak, és hogy az Aurora Vision implicit módon kezeli ezen események modellezését hibakategóriákban, hogy aktiválja a megfelelő profilhibát. esemény esetén tanácsos az API mindig a következőképpen szűrni:

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

Bár a többi queryParameters nem szükséges a válasz megszerzéséhez, a hibaesemények kezelésekor mindig hasznos lehet a típus, az előfordulás és az állapot szűrése:

• eventsType: lehetővé teszi a profilhiba-események típusának szűrését; egyszerre csak egy típusú hibaesemény szűrhető ki (a hibaesemények típusainak teljes táblázatát lásd a Oldal 4). Ha nincs beillesztve az API-ba, akkor minden eseménytípus visszaadásra kerül;
• eventsOccurrence: lehetővé teszi a hibaesemények előfordulásának szűrését; Az elfogadott értékek a következők 24H, 24 órás időablakhoz, 7D, 7 napos időablakhoz, vagy 30D, egy ideig 30 napos ablak. Ha nincs beillesztve az API-ba, akkor az üzem élettartamát lefedő összes esemény visszaadásra kerül;
• eventsState: lehetővé teszi a hibaesemények állapotának szűrését; Az elfogadott értékek az ACTIVE, az aktív események esetében, amelyeknek ezért nem volt záró időbeli szingularitásuk, a CLOSED, a zárt eseményeknél, vagy az ALL, a kérésnél aktív és zárt események egyszerre. Ha nincs beillesztve az API-ba, akkor minden aktív és zárt esemény visszaküldésre kerül;

Jelenleg minden eszközünk rendelkezésre áll, hogy megértsük, mely hibaesemények aktívak az Plant 1:

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

Az plant EID-jének megadásával Plant 1 (12345678), az ACTIVE hiba események lekérésével a hierarchikus szintjére helyeztük magunkat. az utolsó 24H:

A válaszból láthatjuk, hogy két profil típusú hibaesemény aktív: egy DEVCOM az Inverter 1 esetén és egy LOGCOM a Logger 1 naplózó. A két hibaesemény különböző időpontokban aktiválódik, és a definíciókra hivatkozva feltételezhetjük, hogy az Inverter 1 leállította az adatok küldését a Logger 1 nek az eventStart időpontban; taz utóbbi továbbra is megfelelően kommunikált az Aurora Vision, de ezt követően az eventStart nál abbahagyta.

A hierarchikus állapotterjesztés elve az ilyen típusú API-kra is érvényes, így megerősítve, hogy ha egy hibaeseményt azonosítanak és aktiválnak egy bizonyos hierarchikus szinten, akkor az a hierarchikusan magasabb rendű entitásokhoz is eljut; ez azt jelenti, hogy egy eszközt érintő hibaesemény az üzemi hierarchia szintjén is megjelenik, amint azt a fenti példából jól érzékelhetjük.