Event Processing

Event Processing

Event Processing complète le travail avec les rulechains lorsque des logiques récurrentes d'alarmes et d'événements ne doivent pas être construites manuellement à chaque fois sous forme de structure de nœuds propre.

Deux types de règles peuvent être gérés dans cette section :

• Calculate alarm rules pour le calcul et la génération automatiques d'alarmes à partir de la télémétrie entrante
• Enrich alarm rules pour l'enrichissement d'alarmes déjà générées avec des métadonnées supplémentaires

La vue tableau affiche toutes les règles Event Processing existantes. En haut à gauche, Create permet de créer une nouvelle règle. En haut à droite, les règles cochées peuvent être supprimées.

La colonne d'actions d'une règle existante offre en outre les fonctions suivantes :

• Consulter le contenu de la règle
• Réassigner la règle à des appareils
• Supprimer la règle

Principe de base

Event Processing simplifie des workflows d'alarmes qui devraient autrement être construits manuellement.

Pour les règles d'alarme, la logique correspond pour l'essentiel au déroulement suivant :

La définition tabulaire de la règle détermine donc quelle télémétrie est surveillée, quand une alarme est active et quelles informations supplémentaires sont transmises.

Créer une nouvelle règle

Lors de la création d'une nouvelle règle Event Processing, le type est d'abord sélectionné.

Les choix proposés sont :

• Calculate Alarm Rules
• Enrich Alarms

Un fichier de règles est ensuite téléversé, puis, à l'étape suivante, assigné à des appareils, des listes d'appareils, des types d'appareils ou au projet actuel.

L'assignation peut se faire via les types de regroupement suivants :

• Single entity
• Entity list
• Entity name
• Device type
• Current project

Une règle ne s'applique ainsi qu'aux appareils sélectionnés ou au groupe d'appareils défini.

Calculate Alarm Rules

Les Calculate Alarm Rules servent à définir de manière déclarative des conditions d'alarme à partir de données de télémétrie, au lieu de modéliser une rulechain propre pour chaque alarme.

Après l'importation, le tableau lu peut être vérifié directement dans optiCLOUD.

Structure du fichier de règles

Le fichier d'importation est structuré sous forme de tableau. Les colonnes obligatoires sont :

Colonne	Signification
telemetry_key	Canal de télémétrie auquel la règle est appliquée
state_0	Condition ou état cible pour le statut 0
state_1	Condition ou état cible pour le statut 1
error_value	Indique quel statut est considéré comme une alarme (state 0 ou state 1)
alarm_type	Nom ou type de l'alarme à générer
alarm_active	Active ou désactive la règle

Il est possible d'ajouter en option un nombre quelconque de colonnes de métadonnées supplémentaires :

• meta_field_<NAME> pour des métadonnées définies indépendamment du statut
• meta_field_<NAME>_value_0 pour des métadonnées uniquement avec state_0
• meta_field_<NAME>_value_1 pour des métadonnées uniquement avec state_1

Les préfixes meta_field_ ainsi que les suffixes _value_0 et _value_1 sont imposés.

Calculs de règle

Les états peuvent contenir de simples valeurs fixes ou des expressions. En voici des exemples :

• x == 1
• x >= 15
• x > 15 && x < 30
• x * 1.25 >= 100
• text == "myText"

Il est ainsi possible de représenter aussi bien des seuils numériques que des conditions logiques plus complexes, « x » étant la variable qui représente la valeur de télémétrie entrante.

Exemple

telemetry_key	state_0	state_1	error_value	alarm_type	alarm_active	meta_field_Description_EN	meta_field_Description_DE
Temperature	x>5	x<=5	0	Temperature_Alarm	Y	Temperature above 5	Temperature über 5
Pressure	x>5	x<=5	0	Pressure_Alarm	Y	Pressure above 5	Druck über 5
Humidity	x>5	x<=5	0	Humidity_Alarm	Y	Humidity above 5	Feuchtigkeit über 5

L'exemple peut être téléchargé ici (conversion en .xlsx nécessaire)

Réassigner à des appareils

Les règles déjà créées peuvent être rouvertes ultérieurement et assignées à d'autres appareils ou groupes.

C'est utile lorsque la même définition de règle doit s'appliquer à d'autres appareils, sans qu'il faille créer un second fichier de règles.

Intégrer à la Root Rule Chain

Pour que la règle devienne active, elle doit en outre être intégrée à la Root Rule Chain.

Pour cela, le nœud Complex Alarm est utilisé dans la Root Rule Chain sous Event Rule.

Le nœud est inséré après Save Timeseries et relié par la relation Success.

Une valeur de télémétrie entrante est ainsi d'abord enregistrée, puis évaluée à l'aide des règles d'alarme.

Résultat sur l'appareil

Après l'enregistrement de la Root Rule Chain, les alarmes générées apparaissent sur l'appareil concerné dans la section Notifications. Dans la ligne de chaque alarme, l'icône Details permet de consulter l'intégralité du contenu de l'alarme.

Enrich Alarms

Les Enrich Alarms servent à compléter, d'après leur alarm_type, les alarmes que l'appareil envoie directement à Opticloud avec des informations supplémentaires, par exemple des consignes d'utilisation, des messages de service ou d'autres mesures recommandées. C'est utile lorsque l'appareil transmet par exemple à la cloud des alarmes d'un automate, mais que ces alarmes contiennent peu d'informations. OptiCloud peut alors les enrichir directement avec des informations existantes, ce qui simplifie l'affichage dans les dashboards ainsi que l'analyse ultérieure des alarmes.

Le processus de création est identique : sélectionner le type, téléverser le fichier, définir les appareils ou groupes cibles.

Après sa création, la règle apparaît également dans la vue d'ensemble générale d'Event Processing.

Après l'importation, le tableau lu peut également être consulté directement.

Structure du fichier de règles

Les colonnes obligatoires sont :

Colonne	Signification
alarm_type	Type d'alarme à enrichir
alarm_active	Active ou désactive la règle concernée

Les métadonnées supplémentaires sont ajoutées sous forme de colonnes supplémentaires au format meta_field_<NAME>.

Exemple

alarm_type	alarm_active	meta_field_servermessage	meta_field_description	meta_field_remedysteps
TemperatureDeviceAlarm	y	Temperature Alarm on Valve 10	Please look in Service Manual Page 56	Reset Temperature Valve 10
PressureDeviceAlarm	y	Pressure Alarm on Valve 10	Please look in Service Manual Page 56	Reset Pressure Valve 10
HumidityDeviceAlarm	y	Humidity Alarm on Valve 10	Please look in Service Manual Page 56	Reset Humidity Valve 10

L'exemple peut être téléchargé ici (conversion en .xlsx nécessaire)

Activer la règle d'enrichissement

Pour le traitement dans la Root Rule Chain, le nœud Enrich Alarm est utilisé sous Event Rule.

Le nœud est raccordé après Save Alarms, afin que l'alarme soit d'abord enregistrée, puis complétée avec les champs supplémentaires.

Résultat dans les détails de l'alarme

Après l'activation, les informations supplémentaires peuvent être consultées dans la vue de l'appareil, sous Notification, via les détails de l'alarme.

Il est ainsi possible d'afficher directement, pour une alarme, des informations contextuelles telles que la description, le message serveur ou les mesures recommandées.

Résumé

Dans optiCLOUD, Event Processing sert d'interface simplifiée pour deux workflows d'alarmes récurrents :

• calculer des alarmes à partir de conditions de télémétrie
• enrichir des alarmes existantes avec des métadonnées supplémentaires

Les deux types de règles sont d'abord importés et assignés à des appareils. Elles ne deviennent actives qu'une fois que le nœud Event Rule approprié a été intégré à la Root Rule Chain et enregistré.