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.
Probability ladder — when several thresholds give a probability to the same risk, they share one runtime node and its probability follows the measured value step by step; going back under an intermediate threshold lowers it to the previous step, only the first threshold removes the risk. The shared node carries the runtime key _potentiality_ladder and its probability is a cascade of ifThenElse on the measured value.
Nature of the risk — a potentiality raised by a threshold keeps the nature of its reference (Emerging, Intrinsic…): without it, the objectives offered to the deduction would ignore it.
Release with hysteresis — three optional columns delay the release: released below (MAX threshold) or released above (MIN threshold), and released after (h). What the threshold activates is then released only once the value has stayed past the release value for that many hours, with a SUSTAINED_THRESHOLD deactivation instead of the crossing back. A risk the same threshold gives a probability to is not removed with what it activates: at the release it is published again with the probability of the measure, since an actuality and the risk that generated it are never active together.
SUSTAINED_THRESHOLD trigger — fires on a reading taken at least durationMillis after a first reading past the value (staysBelowValue or staysAboveValue, exactly one), with no reading of the same sensor on the other side in between. The duration is measured on the dates of the events, so a replayed scenario follows its own clock (CEPRuleDefinitionCompiler.compileSustainedThreshold).
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.
Use-case clock — a connector sends nothing while the clock of the use case is not at the server time: values dated now would not belong to the time of the use case. The connection is then SUSPENDED and resumes when the clock is back at the server time.
Connection state — every change is published as a dataSourceConnectionEvent (CONNECTED, FAILING, SUSPENDED or DISCONNECTED, with the date of the last value received). r-iose shows a Connect to … switch and the state under the selected sensor and its forecasts; r-iota raises an alert when a provider becomes unreachable and another one when it answers again. A wrong configuration (no station code, no hashtag) leaves the sensor disconnected with a FAILING state; it never prevents the sensor from starting.
Message cap — a messaging sensor has a Message Processing section: message processing (LLM / Keywords / None), limit messages (default Yes) and messages per minute (default 5). With the limit on, beyond that number of messages in a sliding minute the messages received by the sensor are ignored, whatever channel they come from; a change of the value applies at once.
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.
Échelle de probabilité — quand plusieurs seuils donnent une probabilité au même risque, ils partagent un seul nœud d’exécution et sa probabilité suit la valeur mesurée palier par palier ; repasser sous un seuil intermédiaire la ramène au palier précédent, seul le premier seuil retire le risque. Le nœud partagé porte la clé d’exécution _potentiality_ladder et sa probabilité est une cascade d’ifThenElse sur la valeur mesurée.
Nature du risque — une potentialité levée par un seuil garde la nature de sa référence (Emerging, Intrinsic…) : sans elle, les objectifs proposés à la déduction l’ignoreraient.
Relâchement avec hystérésis — trois colonnes facultatives retardent le relâchement : released below (seuil MAX) ou released above (seuil MIN), et released after (h). Ce que le seuil active n’est alors relâché qu’une fois la valeur restée au-delà de la valeur de relâchement pendant ce nombre d’heures, par une désactivation SUSTAINED_THRESHOLD au lieu du franchissement inverse. Un risque auquel le même seuil donne une probabilité n’est pas retiré avec ce qu’il active : au relâchement, il est republié avec la probabilité de la mesure, car une actualité et le risque qui l’a générée ne sont jamais actifs ensemble.
Déclencheur SUSTAINED_THRESHOLD — se déclenche sur un relevé pris au moins durationMillis après un premier relevé au-delà de la valeur (staysBelowValue ou staysAboveValue, exactement un), sans relevé du même capteur de l’autre côté entre les deux. La durée se mesure sur les dates des événements : un scénario rejoué suit sa propre horloge (CEPRuleDefinitionCompiler.compileSustainedThreshold).
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.
Horloge du cas d’usage — un connecteur n’envoie rien tant que l’horloge du cas d’usage n’est pas à l’heure du serveur : des valeurs datées de maintenant n’appartiendraient pas au temps du cas d’usage. La connexion est alors SUSPENDED et reprend quand l’horloge revient à l’heure du serveur.
État de la connexion — chaque changement est publié en dataSourceConnectionEvent (CONNECTED, FAILING, SUSPENDED ou DISCONNECTED, avec la date de la dernière valeur reçue). r-iose affiche un interrupteur Connect to … et l’état sous le capteur sélectionné et ses prévisions ; r-iota lève une alerte quand un fournisseur devient injoignable et une autre quand il répond de nouveau. Une configuration erronée (pas de code de station, pas de hashtag) laisse le capteur déconnecté avec l’état FAILING ; elle n’empêche jamais le capteur de démarrer.
Plafond de messages — un capteur de messagerie a une rubrique Message Processing : message processing (LLM / Keywords / None), limit messages (Yes par défaut) et messages per minute (5 par défaut). Limite active, au-delà de ce nombre de messages sur une minute glissante, les messages reçus par le capteur sont ignorés, quel que soit leur canal ; un changement de la valeur s’applique aussitôt.