Gestion de l’état d’Erreur

Évaluation du Statut des Entités et des événements d’Erreur

Comme mentionné à la Page 2, les profils d’erreur sont toujours attribués aux usines et, par conséquent, le Statut d’une entité ne peut changer qu’à partir de ce niveau hiérarchique. Lorsqu’un événement d’erreur est identifié et activé à un certain niveau hiérarchique, il est propagé à toutes les entités hiérarchiquement supérieures (allant du niveau usine) et cela signifie donc que le Statut de ces entités est uniformément modifiée ; ce comportement est identifié comme le principe de la propagation hiérarchique des statuts.

L’API GET Status permet d’obtenir le Status d’une Plant, Logger et/ou Device (selon le niveau hiérarchique et la suite).
La particularité de cette API est sa réponse dynamique : elle renvoie toujours l’explosion de toutes les entités hiérarchiquement inférieures dont Status est différent de NORMAL, indiquant ainsi lesquels sont affectés par les événements d’erreur actifs (mais pas le type d’erreur d’événement réel).

Prenons le schéma hiérarchique suivant comme exemple et supposons que nous voulons vérifier le Status de Plant 1, afin de comprendre s’il peut y avoir des événements d’erreur actifs:

Au niveau hiérarchique de l’usine, appelons l’API GET Plant Status :

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

S’il n’y a pas d’événement d’erreur actif, nous obtiendrons une réponse dans laquelle le Status de Plant 1 sera égal à NORM (qui équivaut à NORMAL):

S’il y a au moins un événement d’erreur actif, cela signifie qu’au moins un des appareils enregistrés dans Plant 1, qui sont donc des enfants hiérarchiques de ce dernier, a un événement d’erreur actif associé ; dans ce cas, la réponse de l’API s’adapte dynamiquement en explosant le Status de Plant 1 mais aussi de toutes ces entités enfants hiérarchiques dont le Status est différent de NORM:

Nous pouvons voir comment la réponse est maintenant plus structurée et comment le statut de Plant 1 est maintenant égal à MEDIUM, un symptôme qu’un événement d’erreur est actif pour certains entités de niveau hiérarchique inférieur. Cet événement d’erreur est actif pour Inverter 1, car l’API nous fournit une réponse éclatée pour tous les niveaux hiérarchiques allant de Plant 1 (LVL 3) à Inverter 1 (LVL 5). Le Status des trois entités est donc égal à MEDIUM, en raison du principe de propagation hiérarchique que nous avons mentionné en haut de la page.

Le principe de gestion d’une réponse dynamique par une API GET Status est également présent aux niveaux hiérarchiques inférieurs.
Si pour l’exemple ci-dessus nous allons appeler le GET Logger Status, a réponse renvoyée sera:

Nous pouvons voir comment la réponse a exactement la même structure que celle obtenue avec l’API GET Plant Status , où Logger 1 et Inverter 1 ont leur Status égal à MEDIUM. La seule différence est la présence d’un niveau hiérarchique en moins (car nous avons ciblé des ressources d’un niveau hiérarchique inférieur).

Nous avons donc vu comment s’applique le principe de la propagation hiérarchique : tout équipement ayant un événement d’erreur actif, qui fait que son Status est différent de NORMAL, change simultanément le Status de toutes les entités hiérarchiquement supérieures (allant du niveau usine). Cela permet de discriminer immédiatement la présence ou l’absence d’erreurs simplement en exploitant l’API GET Plant Status.

Évidemment, une fois que nous avons vérifié la présence d’événements d’erreur, nous sommes intéressés à savoir quels sont ces événements d’erreur. Pour ce faire, nous pouvons utiliser l’API GET Events qui permet d’obtenir les événements d’erreur d’un Plant, Logger et/ou Device (selon le niveau hiérarchique qui nous intéresse) avec un filtrage avancé sur: catégorie, type, état et occurrence.

Regardons la demande d’API complète, puis décomposons-la pour l’analyser en détail:

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}

Le path, qui vous permet de pointer vers les ressources souhaitées, nécessite toujours le {entityID} et, en fonction du niveau hiérarchique et de la suite sur laquelle vous vous trouvez, il peut s’agir d’un Plant, Logger ou Device EID:

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

L’API requiert toujours le paramètre de requête {eventsKind} afin de discriminer le type d’événements d’erreur à appelerype of error events to call.
Ce paramètre peut avoir deux valeurs différentes:

• Profile: permet d’obtenir les événements d’erreur de type profil, c’est-à-dire ceux qui sont activés par Aurora Vision en fonction du profil d’erreur, avec ses règles configurées, associées à l’installation considérée (ou pour l’un des appareils hiérarchiquement fils de ce dernier)
• Source: permet d’obtenir les événements d’erreur de type source, c’est-à-dire les erreurs machine identifiées par un appareil et qui sont ensuite communiquées à Aurora Vision (qui les modélise en fonction de l’appareil qui les a envoyées)

Nous avons dit précédemment que l’activation d’une erreur, appartenant à n’importe quelle catégorie définie dans un profil d’erreur, peut dépendre de la présence/absence de données et/ou d’événements source. Les événements d’erreur Profile peuvent être activés lorsque des conditions spécifiques sont détectées sur les données ou lorsqu’un appareil communique à Aurora Vision l’identification d’une Source événement d’erreur qui tombe dans l’une des catégories d’erreur de profil. Considérant que les événements sources sont plus difficiles à comprendre que ceux du profil, car ils sont composés d’abréviations qui peuvent varier d’un appareil à l’autre, et qu’Aurora Vision gère implicitement la modélisation de ces événements dans des catégories d’erreur afin d’activer l’erreur de profil correcte événement, il est conseillé de toujours filtrer l’API comme suit:

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

Bien que les autres queryParameters ne soient pas nécessaires pour obtenir une réponse, lorsque vous travaillez avec des événements d’erreur, il est toujours utile de pouvoir filtrer le type, l’occurrence et l’état:

• eventsType: permet de filtrer le type d’événements d’erreur de profil ; un seul type d’événement d’erreur peut être filtré à la fois (pour un tableau complet sur les types d’événements d’erreur, veuillez vous référer à la Page 4). S’ils ne sont pas insérés dans l’API, tous les types d’événements seront renvoyés;
• eventsOccurrence: permet de filtrer l’occurrence des événements d’erreur ; les valeurs acceptées sont 24H, pour une fenêtre horaire de 24h, 7D, pour une fenêtre horaire de 7 jours, ou 30D, pour une durée fenêtre de 30 jours. S’ils ne sont pas insérés dans l’API, tous les événements qui couvrent la durée de vie de la centrale seront renvoyés;
• eventsState: permet de filtrer l’état des événements d’erreur ; les valeurs acceptées sont ACTIVE, pour les événements actifs qui n’ont donc pas eu de singularité temporelle de fermeture, CLOSED, pour les événements fermés, ou ALL, pour les requêtes événements actifs et fermés en même temps. S’ils ne sont pas insérés dans l’API, tous les événements actifs et fermés seront renvoyés;

À ce stade, nous disposons de tous les outils pour comprendre quels événements d’erreur sont actifs pour Plant 1:

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

Nous nous sommes placés au niveau hiérarchique plant en entrant l’EID de Plant 1 (12345678), en demandant des événements d’erreur ACTIVE dans les dernières 24H:

Nous pouvons voir à partir de la réponse que deux événements d’erreur de type de profil sont actifs : un DEVCOM pour Inverter 1 et un LOGCOM pour Logger 1. Les deux événements d’erreur sont activés à des moments différents et, en se référant aux définitions, nous pouvons supposer que Inverter 1 a cessé d’envoyer des données à Logger 1 à eventStart; ce dernier communiquait toujours correctement avec Aurora Vision, mais a ensuite cessé de le faire à eventStart.

Le principe de propagation hiérarchique du statut est également valable pour ce type d’API, confirmant ainsi que lorsqu’un événement d’erreur est identifié et activé à un certain niveau hiérarchique, il est propagé à toutes les entités hiérarchiquement supérieures ; cela signifie qu’un événement d’erreur qui affecte un appareil est également affiché au niveau hiérarchique de l’usine, comme nous pouvons clairement le voir dans l’exemple ci-dessus.