r-io suiter-io suiteinterceptor docs
← Model loading
Node interceptor / Interpretation

Sensor

Turns an active Sensor node into a deployed CEP rule or machine-learning configuration and resolves its impact on the collaborative model.

SN

SensorModelsPopulateInterceptor

Bridges collaborative sensor definitions and low-level interpretation.

beforeAdd · afterAdd · afterUpdate
TriggerExact core-model Sensor type with ACTIVE status. Subtype determines which configuration builder is used.
BEFORE ADDComplete 3D asset URL

When 3D model url is empty, it is derived from the modeling icon of the sensor (.png → .glb). A sensor without modeling icon (older use case, import) keeps an empty URL with a warning instead of aborting the publication.

AFTER ADDCompile and deploy

Creates the appropriate CEP or ML configuration through LowLevelInterpretationManager.

AFTER UPDATERedeploy

Rebuilds interpretation so runtime behavior follows the latest sensor definition. A partial update with no sensor subtype leaves deployed rules unchanged.

01 · Dispatch

Subtype selects the interpretation path

Quantitative / Dedicated

Builds numerical or domain-specific CEP rules from measure, threshold and interpretation properties.

Media

Builds a media-aware CEP configuration for observation events.

Others / Knowledge

Uses the generic knowledge interpretation path for model-driven observations.

Social: Messaging

Follows the sensor’s message processing: LLM (default) delegates to a machine-learning configuration in which the configured LLM provider looks for the dangers and risks of each message; Keywords builds one CEP rule per row of the thresholds table, raised by a message containing one of its keywords (case ignored); None deploys nothing and the messages are only stored. When the processing changes, the rules generated for the other processing are removed; rules written by hand in the project are kept.

ACTIVE Sensortyped properties
Select builderCEP or ML
Compileruntime configuration
Deployinterpretation manager
Resolve impactgraph + probabilities
02 · Runtime effects

Detection updates the collaborative graph

The generated interpretation does more than recognize an event. Its resolution path can create or update problems, connect them with Impacts or Fixed_Onto, maintain Near lineage and propagate probability values used by potentialities.

add / updateconceptual flow
if node.type != Sensor or node.status != ACTIVE: return
configuration = switch sensor subtype:
    quantitative | dedicated | media | knowledge -> build CEP
    messaging, message processing = LLM         -> build ML
    messaging, message processing = Keywords    -> build CEP (one rule per keywords row)
    messaging, message processing = None        -> nothing (messages stored)
deploy(configuration)
on detection:
    resolve affected model element
    update impact/fix relations and probability
Import and frozen situations

During model import, invalid or incomplete rule definitions may be deferred only while interception control is disabled; the project deploys its own rules after the models. A frozen problem impacting an asset in the sensor’s recursive Fixed_Onto chain is activated in place. A frozen anticipation without that match stays frozen: detection creates a separate ACTIVE problem linked by Near. CEP results carry Occurred at from the sensor event date; simulated dates are not replaced with the current wall clock.

Deletion lifecycle

The delete hooks are empty in this interceptor. No explicit undeploy is performed here; runtime cleanup must therefore be guaranteed by the interpretation layer or another lifecycle mechanism.

03 · Thresholds

One CEP rule per threshold, with an optional release

A quantitative sensor carries a thresholds table. Each row (type MAX or MIN, value, referenced problems, potentiality probabilities) becomes one CEP rule: it activates its problems when the value crosses the threshold (THRESHOLD_TRANSITION, above for MAX, below for MIN) and, by default, releases them when the value crosses back.

Orléans Flood CrisisLoire water level - Orleans
MAX 2.50 m -> George-V bridge flood risk 0.2
MAX 3.50 m -> George-V bridge flood risk 0.5
MAX 4.00 m -> George-V bridge flood risk 0.8
MAX 4.50 m -> George-V bridge flood risk 1
MAX 4.50 m -> flood, released below 4.00 m after 6 h
# rule R5: activation THRESHOLD_TRANSITION crossesAboveValue 4.5
#          deactivation SUSTAINED_THRESHOLD staysBelowValue 4.0, durationMillis 21600000

The flood thus stays active while the Loire recedes from 4.50 m to 4.00 m and ends six hours after it went below 4.00 m; a reading back above 4.00 m in between starts the count again. The probabilities of the risk are covered in the 2L language reference, which sets the low tier of the same risk.

04 · Connected sensors

A sensor can receive the data of a public provider

A quantitative sensor or a messaging sensor carries a provider property in its Configuration section. With a provider other than None, the connect switch (Yes / No, default No) and a polling period (minutes) appear, plus a section of connection parameters for that provider. Connected, the sensor reads its provider at each period and every new value goes through the same path as any event of the field (listen, CEP / ML, time series). Not connected, it receives what the field channels send it, for example the scenario played by r-iosemit.

Hub'Eau

Quantitative sensor. Section Hub'Eau Configuration: station code (e.g. K435001010, the Loire at Orléans). Reads the latest water-level observations of the station (default period 5 min); at the first read only the current value is taken, then each new observation is sent to the sensor.

Mastodon

Messaging sensor. Section Mastodon Configuration: mastodon instance (default mastodon.social), hashtags (comma-separated; a public post carrying one of them is received), language (empty: every language). The instance is read at most every 30 s; at the first read only the latest post is taken, then each newer post is sent to the sensor as a message with its author and pictures.

Vigicrues

Forecast node (provider Vigicrues). Section Vigicrues Configuration: station code, polling period (minutes) (default 15), connect. Each new forecast published by the provider becomes a forecast snapshot sent to the projection service; while the provider fails, the projection goes on from the measures alone.

Compare with the other node behaviorsAll node interceptors →
Intercepteur de nœud / Interprétation

Sensor

Transforme un Sensor actif en règle CEP ou configuration d’apprentissage déployée, puis résout son impact dans le modèle collaboratif.

SN

SensorModelsPopulateInterceptor

Relie les capteurs collaboratifs à l’interprétation bas niveau.

beforeAdd · afterAdd · afterUpdate
DéclencheurType core-model Sensor exact avec statut ACTIVE. Le sous-type choisit le constructeur de configuration.
AVANT AJOUTCompléter l’asset 3D

Quand 3D model url est vide, elle est dérivée de l’icône de modélisation du capteur (.png → .glb). Un capteur sans icône de modélisation (ancien cas d’usage, import) garde une URL vide avec un avertissement au lieu d’interrompre la publication.

APRÈS AJOUTCompiler et déployer

Crée la configuration CEP ou ML adaptée via LowLevelInterpretationManager.

APRÈS UPDATERedéployer

Reconstruit l’interprétation afin que le runtime suive la définition courante. Une mise à jour partielle sans sous-type de capteur laisse les règles déployées inchangées.

01 · Aiguillage

Le sous-type sélectionne le chemin d’interprétation

Quantitative / Dedicated

Construit les règles CEP numériques ou propres au domaine.

Media

Construit une configuration CEP adaptée aux événements d’observation média.

Others / Knowledge

Utilise le chemin d’interprétation générique piloté par les connaissances.

Social : Messaging

Suit le message processing du capteur : LLM (par défaut) délègue à une configuration de machine learning dans laquelle le fournisseur de LLM configuré cherche les dangers et les risques de chaque message ; Keywords construit une règle CEP par ligne de la table thresholds, levée par un message contenant l’un de ses mots-clés (sans tenir compte de la casse) ; None ne déploie rien et les messages sont seulement stockés. Quand le traitement change, les règles générées pour l’autre traitement sont retirées ; les règles écrites à la main dans le projet sont gardées.

Sensor ACTIVEpropriétés typées
ChoisirCEP ou ML
Compilerconfiguration runtime
Déployergestionnaire d’interprétation
Résoudregraphe + probabilités
02 · Effets runtime

La détection met à jour le graphe collaboratif

La configuration générée ne se limite pas à reconnaître un événement. La résolution peut créer ou mettre à jour des problèmes, les relier par Impacts ou Fixed_Onto, maintenir la filiation Near et propager les probabilités des potentialités.

ajout / mise à jourflux conceptuel
si type != Sensor ou statut != ACTIVE : sortir
configuration = selon le sous-type :
    quantitative | dedicated | media | knowledge -> CEP
    messaging, message processing = LLM         -> ML
    messaging, message processing = Keywords    -> CEP (une règle par ligne de mots-clés)
    messaging, message processing = None        -> rien (messages stockés)
déployer(configuration)
à la détection :
    résoudre l’élément du modèle affecté
    actualiser impacts, corrections et probabilités
Import et situations gelées

Pendant l’import des modèles, les règles invalides ou incomplètes ne peuvent être différées que si le contrôle des interceptions est désactivé ; le projet déploie ses propres règles après les modèles. Un problème gelé impactant une ressource de la chaîne récursive Fixed_Onto du capteur est activé sur place. Une anticipation gelée sans cette correspondance reste gelée : la détection crée un problème ACTIVE distinct relié par Near. Les résultats CEP portent Occurred at depuis la date de l’événement capteur ; les dates simulées ne sont pas remplacées par l’heure courante.

Cycle de suppression

Les hooks de suppression sont vides. Aucun undeploy explicite n’est effectué ici ; le nettoyage du runtime doit être garanti par la couche d’interprétation ou un autre mécanisme.

03 · Seuils

Une règle CEP par seuil, avec un relâchement facultatif

Un capteur quantitatif porte une table thresholds. Chaque ligne (type MAX ou MIN, valeur, problèmes référencés, potentiality probabilities) devient une règle CEP : elle active ses problèmes quand la valeur franchit le seuil (THRESHOLD_TRANSITION, vers le haut pour MAX, vers le bas pour MIN) et, par défaut, les relâche quand la valeur le refranchit dans l’autre sens.

Orléans Flood CrisisLoire water level - Orleans
MAX 2,50 m -> George-V bridge flood risk 0,2
MAX 3,50 m -> George-V bridge flood risk 0,5
MAX 4,00 m -> George-V bridge flood risk 0,8
MAX 4,50 m -> George-V bridge flood risk 1
MAX 4,50 m -> crue, relâchée sous 4,00 m après 6 h
# règle R5 : activation THRESHOLD_TRANSITION crossesAboveValue 4.5
#            désactivation SUSTAINED_THRESHOLD staysBelowValue 4.0, durationMillis 21600000

La crue reste donc active pendant que la Loire redescend de 4,50 m à 4,00 m et se termine six heures après son passage sous 4,00 m ; un relevé repassé au-dessus de 4,00 m entre-temps relance le décompte. Les probabilités du risque sont détaillées dans la référence du langage 2L, qui fixe le palier bas du même risque.

04 · Capteurs connectés

Un capteur peut recevoir les données d’un fournisseur public

Un capteur quantitatif ou un capteur de messagerie porte une propriété provider dans sa rubrique Configuration. Avec un fournisseur autre que None apparaissent l’interrupteur connect (Yes / No, No par défaut) et une polling period (minutes), ainsi qu’une rubrique de paramètres de connexion propre au fournisseur. Connecté, le capteur lit son fournisseur à chaque période et chaque nouvelle valeur suit le même chemin que tout événement du terrain (listen, CEP / ML, série temporelle). Non connecté, il reçoit ce que lui envoient les canaux du terrain, par exemple le scénario joué par r-iosemit.

Hub'Eau

Capteur quantitatif. Rubrique Hub'Eau Configuration : station code (ex. K435001010, la Loire à Orléans). Lit les dernières observations de hauteur d’eau de la station (période de 5 min par défaut) ; à la première lecture seule la valeur courante est prise, puis chaque nouvelle observation est envoyée au capteur.

Mastodon

Capteur de messagerie. Rubrique Mastodon Configuration : mastodon instance (mastodon.social par défaut), hashtags (séparés par des virgules ; un message public portant l’un d’eux est reçu), language (vide : toutes les langues). L’instance est lue au plus toutes les 30 s ; à la première lecture seul le dernier message est pris, puis chaque message plus récent est envoyé au capteur avec son auteur et ses images.

Vigicrues

Nœud Forecast (fournisseur Vigicrues). Rubrique Vigicrues Configuration : station code, polling period (minutes) (15 par défaut), connect. Chaque nouvelle prévision publiée par le fournisseur devient un instantané de prévision envoyé au service de projection ; tant que le fournisseur est en échec, la projection continue à partir des seules mesures.

Comparer les autres comportements de nœudsTous les intercepteurs de nœuds →