r-io suitesupervision docsOnce r-iota deploys and supervises a solution, the plan stops following the field: the field keeps changing while the expected world only moves on with the process. The supervision measures, every few seconds, how far the two worlds drift apart and tells whether the running process is still valid and still adapted to the current problems. It never changes the process by itself: it raises an alert and proposes adaptations to the operator.
Each strategy turns what it sees into the value of one or more failure categories, divided by the threshold of the category: below 1 the process is still fine, at 1 an action is needed. The operator decides: find solutions again, cancel the solution, or carry on. Since 2026-10 this replaces the former F-Score and D3 detection methods and the “Divergence detection method” of the r-ioga project editor.
EXPECTED_FREEZE twins of the supervised solution, cloned from the field when the supervision started, then moved on by the process.supervisionStatusEvent on the SOLUTION WebSocket topic at every computation.Supervising a solution clones the field into twins labelled EXPECTED_FREEZE and the solution id: the plan of what the world should become.
The ids are the same — a twin is named expected_freeze##<solution>##<field id>; the engine strips the prefix and the collaboration suffix, so the field node and its twin share one id. A node present in one world only was added or deleted there.
The baseline tells who changed — when the two worlds differ, the baseline (the expected world right after the clone, when both were equal) tells which side moved: the field (something happened) or the plan (the process did something). The clone is progressive, so the baseline is only taken once the size of the expected world is stable between two computations; it is stored in the SupervisionBaseline collection and survives a restart.
Matched changes cancel out — when the process does what the field also shows (a task resolved the gas leak and the sensor confirms it), both worlds changed the same way: nothing is weighted. Only a change found in one world counts.
Involved instances — an instance is involved when a task of the solution which is not over yet uses it (actor through Assigned_To, consumed, produced or required resource), or when an objective of the solution treats or prevents it (Solves → Plans → Treats | Prevents). Changes on involved instances weigh more than the others.
From the most to the least severe. The first four are alerts: at 1, the process must change. Improvable never raises an alert.
| Category | What happened | Proposed adaptation |
|---|---|---|
| Uncovered | New problems (actuality, potentiality, risk) appeared on the field that the supervised solution does not treat. | Find solution(s) for the new problem. |
| Failing | A resource of a remaining task disappeared or became unusable (presence lost, calendar unavailable, high strain), or the actors deviate from the process: it cannot be completed. | Reassign the remaining tasks (find solution(s) again). |
| Obsolete | A problem the solution treats vanished on the field while the plan still expects it: some tasks are now useless. | Remove the useless tasks (find solution(s) again). |
| Wrong | The indicators of the solution (duration, cost, distance, strain…) replayed with the field values drift from the deduced ones, or the process is late. | Switch to another solution or reschedule. |
| Improvable | Better resources became available: the process still works, a new deduction might do better. | Find solution(s) to compare with the current one. |
Each strategy is a plugin: a Maven module of gind-detection-engine and a TypeScript extension that edits its configuration in the supervision box. Checked by default: the first two.
A matrix of weights per concept, world and kind of change; changes found in one world only are summed.
Replays the indicators of the KPIL script with the field values and compares them with the deduced ones.
Work planned by now, work done, what it cost: schedule and cost performance indices.
Projects the end of the process along its critical path and warns before the deadline is missed.
Replays the To-Do Lists on the deduced process: skipped, disordered, rejected, failed or unexpected tasks.
Tries the newcomers in place of the resources of the tasks nobody started yet.
CUSUM or Page-Hinkley on the curves of the others: an early warning before a curve reaches 1.
Backend plugin — a module gind-detection-engine-<name> extends AbstractSupervisionStrategy (name, categories it feeds, extension name, checked by default or not, default configuration of a project, compute(SupervisionContext, configuration)) and declares itself in META-INF/services/fr.emac.gind.monitoring.supervision.AbstractSupervisionStrategy. The r-iota webapp depends on the plugins at runtime; ServiceLoader finds them at startup.
Frontend extension — a project gind-npm-strategy-supervision-<name> is an Angular bundle loaded by r-iota from supervision-strategy-extensions.json. It registers itself in window.gindSupervisionStrategyExtensions and mounts its configuration in the box: mount(host, {strategy, configuration, onChange, readonly}) returns update, setReadonly and destroy.
SupervisionContext what a strategy sees at one time
baseline / field / expected instances by id (the twins under the id of their field node)
resourcesOfRemainingTasks instances used by a task which is not over
treatedProblems actualities, potentialities, risks the objectives treat or prevent
solutionTasks / solutionFlows / solutionNodes the deduced process (tasks, flows, gateways, events)
runtimeTasks the tasks as their actors left them in the To-Do Lists
unexpectedRuntimeTasks To-Do List tasks the process of the solution does not have
objectiveDeadlines dates the objectives must be reached by (plan of the objective)
roles the roles (Has) of the persons of the field
history / currentScores for the strategies computed after the othersSessions — the SupervisionEngine is started with the r-iota webapp. A knowledge space is watched once r-iota asks for its state, or a few seconds after a solution is supervised. A one-second tick computes each session whose period is over; computations never overlap.
Period — 10 s by default, changed in the box even while a solution is supervised (it does not change what is measured). It cannot be shorter than 5 s, has no maximum, and is never shorter than five times the last computation, so a large use case slows itself down (about 0.5 s per computation on IMT Albi Crisis).
History — a point (date, value of each category, value per strategy, up to 200 contributions) is kept in memory and in the SupervisionHistory collection each time the values change, so the curves survive a reload. Every computation is also pushed to the r-iota pages as a supervisionStatusEvent.
Configuration — the checked strategies and their configurations are stored in the hidden project property supervision configuration (JSON). While a solution is supervised the configuration is frozen; the server refuses to save it until the solution is cancelled.
every second, for each watched knowledge space whose period is over
solution = the selected Solution with EXPECTED_FREEZE twins # none: nothing to supervise
if the expected world still grows: wait (the clone is progressive)
baseline = stored baseline, or the expected world now # once
context = field, expected, baseline, process, To-Do Lists, involved instances, deadlines, roles
for each checked strategy (the watching ones last):
values = strategy.compute(context, configuration) # share of the threshold
category = max(category, value)
record a point if a value changed, push supervisionStatusEvent
next run = now + max(period, 5 s, 5 × duration of this computation)The radar button of the r-iota toolbar opens it at any time. Before a solution is supervised it shows the detectors to check and configure; afterwards the curves come first.
Alert box — when an alert category newly reaches 1 (and the supervision box is not open), a single box opens on the most severe crossed category, with the contributions that explain it and the adaptations: find solutions again, or cancel the current solution. The radar button turns red.
Improvable — never opens the box: the radar button gets a blue badge and a light banner tells that a better solution may exist; the operator can hide it.
Cancel the current solution — two choices. Memorize the tasks already done writes the done tasks, their actors, dates and outputs on the solution (memorized done tasks) before cancelling, so that the next deduction can keep those actors; memorize nothing starts again from scratch, the deduction being free to choose better actors. After cancelling, the tasks of the To-Do Lists show as cancelled, r-iota is no longer supervised, the alerts are visible again and a new Find solution(s) covers every current problem.
The deduction does not read memorized done tasks yet.
Under /{app}/r-iota/supervision, for the collaboration and knowledge space of the user. See also the API reference.
| Call | Answer |
|---|---|
GET strategies | Every strategy found: name, description, categories, extension name, checked by default, default configuration for the project. |
GET configuration · POST configuration | The checked strategies, their configurations and the period; saving is refused while a solution is supervised. |
GET state | Supervised or not, solution, period asked and applied, duration of the last computation, history of the points. |
GET point?date= | The point closest to a date, with its contributions. |
POST period {periodSeconds} | Changes the period, also while a solution is supervised (5 s minimum). |
POST compute | Computes now. |
POST memorizeBeforeCancel {memorizeDoneTasks} | Writes or clears the memorized done tasks of the solution before it is cancelled. |
gind-webapp-r-iota/…/resources/supervision/SupervisionEngine.java · SupervisionResource.javaSessions, worlds, baseline, period, history, WebSocket event, REST resource.gind-detection-engine-abstract/…/monitoring/supervision/Contract: AbstractSupervisionStrategy, SupervisionContext, SupervisionResult, SupervisionContribution, SupervisionCategory, ProcessGraph, SupervisionHelper.gind-detection-engine-<strategy>/One module per strategy, declared through ServiceLoader.gind-npm-r-iota/…/detection-page/supervision/Supervision box, alert box, cancel dialog, extension loader and categories.gind-npm-strategy-supervision-<strategy>/The configuration editor of each strategy.Dès que r-iota déploie et supervise une solution, le plan cesse de suivre le terrain : le terrain continue de changer tandis que le monde attendu n’avance qu’avec le processus. La supervision mesure, toutes les quelques secondes, l’écart entre les deux mondes et dit si le processus en cours est encore valide et encore adapté aux problèmes du moment. Elle ne modifie jamais le processus d’elle-même : elle lève une alerte et propose des adaptations à l’opérateur.
Chaque stratégie transforme ce qu’elle voit en valeur d’une ou plusieurs catégories d’échec, divisée par le seuil de la catégorie : sous 1 le processus tient, à 1 une action est nécessaire. L’opérateur décide : chercher de nouvelles solutions, annuler la solution ou continuer. Depuis octobre 2026, cela remplace les anciennes méthodes de détection F-Score et D3 et la « Divergence detection method » de l’éditeur de projet de r-ioga.
EXPECTED_FREEZE de la solution supervisée, clonés depuis le terrain au début de la supervision puis avancés par le processus.supervisionStatusEvent sur le topic WebSocket SOLUTION à chaque calcul.Superviser une solution clone le terrain en jumeaux étiquetés EXPECTED_FREEZE et par l’id de la solution : le plan de ce que le monde devrait devenir.
Les ids sont les mêmes — un jumeau s’appelle expected_freeze##<solution>##<id terrain> ; le moteur retire le préfixe et le suffixe de collaboration, si bien que le nœud du terrain et son jumeau partagent un id. Un nœud présent dans un seul monde y a été ajouté ou supprimé.
La référence dit qui a changé — quand les deux mondes diffèrent, la référence (le monde attendu juste après le clone, quand les deux étaient égaux) dit quel côté a bougé : le terrain (il s’est passé quelque chose) ou le plan (le processus a agi). Le clone est progressif : la référence n’est prise qu’une fois la taille du monde attendu stable entre deux calculs ; elle est stockée dans la collection SupervisionBaseline et survit à un redémarrage.
Les changements concordants s’annulent — quand le processus fait ce que le terrain montre aussi (une tâche a réglé la fuite de gaz et le capteur le confirme), les deux mondes ont changé de la même façon : rien n’est pondéré. Seul un changement vu dans un seul monde compte.
Instances impliquées — une instance est impliquée quand une tâche non terminée de la solution l’utilise (acteur par Assigned_To, ressource consommée, produite ou requise), ou quand un objectif de la solution la traite ou la prévient (Solves → Plans → Treats | Prevents). Les changements sur les instances impliquées pèsent plus lourd que les autres.
De la plus grave à la moins grave. Les quatre premières sont des alertes : à 1, le processus doit changer. Improvable ne lève jamais d’alerte.
| Catégorie | Ce qui s’est passé | Adaptation proposée |
|---|---|---|
| Uncovered | De nouveaux problèmes (actualité, potentialité, risque) sont apparus sur le terrain sans être traités par la solution supervisée. | Chercher des solutions pour le nouveau problème. |
| Failing | Une ressource d’une tâche restante a disparu ou n’est plus utilisable (présence perdue, calendrier indisponible, fatigue élevée), ou les acteurs s’écartent du processus : il ne peut plus aboutir. | Réaffecter les tâches restantes (nouvelle recherche de solutions). |
| Obsolete | Un problème traité par la solution a disparu du terrain alors que le plan l’attend encore : des tâches sont devenues inutiles. | Retirer les tâches inutiles (nouvelle recherche de solutions). |
| Wrong | Les indicateurs de la solution (durée, coût, distance, fatigue…) recalculés avec les valeurs du terrain s’écartent des valeurs déduites, ou le processus est en retard. | Passer à une autre solution ou replanifier. |
| Improvable | De meilleures ressources sont disponibles : le processus fonctionne, une nouvelle déduction ferait peut-être mieux. | Chercher des solutions pour comparer avec la solution en cours. |
Chaque stratégie est un plugin : un module Maven de gind-detection-engine et une extension TypeScript qui édite sa configuration dans la boîte de supervision. Cochées par défaut : les deux premières.
Une matrice de poids par concept, monde et type de changement ; les changements vus dans un seul monde sont additionnés.
Recalcule les indicateurs du script KPIL avec les valeurs du terrain et les compare aux valeurs déduites.
Travail prévu à date, travail fait, ce qu’il a coûté : indices de performance de délai et de coût.
Projette la fin du processus le long de son chemin critique et prévient avant que l’échéance soit manquée.
Rejoue les To-Do Lists sur le processus déduit : tâches sautées, désordonnées, rejetées, en erreur ou imprévues.
Essaie les nouveaux arrivants à la place des ressources des tâches que personne n’a commencées.
CUSUM ou Page-Hinkley sur les courbes des autres : une alerte précoce avant qu’une courbe atteigne 1.
Plugin côté serveur — un module gind-detection-engine-<nom> étend AbstractSupervisionStrategy (nom, catégories alimentées, nom de l’extension, cochée par défaut ou non, configuration par défaut d’un projet, compute(SupervisionContext, configuration)) et se déclare dans META-INF/services/fr.emac.gind.monitoring.supervision.AbstractSupervisionStrategy. La webapp r-iota dépend des plugins à l’exécution ; ServiceLoader les trouve au démarrage.
Extension côté client — un projet gind-npm-strategy-supervision-<nom> est un bundle Angular chargé par r-iota depuis supervision-strategy-extensions.json. Il s’enregistre dans window.gindSupervisionStrategyExtensions et monte sa configuration dans la boîte : mount(host, {strategy, configuration, onChange, readonly}) renvoie update, setReadonly et destroy.
SupervisionContext ce qu’une stratégie voit à un instant
baseline / field / expected instances par id (les jumeaux sous l’id de leur nœud terrain)
resourcesOfRemainingTasks instances utilisées par une tâche non terminée
treatedProblems actualités, potentialités, risques traités ou prévenus par les objectifs
solutionTasks / solutionFlows / solutionNodes le processus déduit (tâches, flux, passerelles, événements)
runtimeTasks les tâches telles que leurs acteurs les ont laissées dans les To-Do Lists
unexpectedRuntimeTasks tâches des To-Do Lists absentes du processus de la solution
objectiveDeadlines dates auxquelles les objectifs doivent être atteints (plan de l’objectif)
roles les rôles (Has) des personnes du terrain
history / currentScores pour les stratégies calculées après les autresSessions — le SupervisionEngine démarre avec la webapp r-iota. Un knowledge space est surveillé dès que r-iota demande son état, ou quelques secondes après la mise en supervision d’une solution. Un battement d’une seconde calcule chaque session dont la période est écoulée ; les calculs ne se chevauchent jamais.
Période — 10 s par défaut, modifiable dans la boîte même pendant la supervision (elle ne change pas ce qui est mesuré). Elle ne peut pas descendre sous 5 s, n’a pas de maximum et n’est jamais plus courte que cinq fois le dernier calcul : un gros cas d’usage ralentit de lui-même (environ 0,5 s par calcul sur IMT Albi Crisis).
Historique — un point (date, valeur de chaque catégorie, valeur par stratégie, jusqu’à 200 contributions) est gardé en mémoire et dans la collection SupervisionHistory à chaque changement de valeur : les courbes survivent à un rechargement. Chaque calcul est aussi poussé vers les pages r-iota par un supervisionStatusEvent.
Configuration — les stratégies cochées et leurs configurations sont stockées dans la propriété cachée du projet supervision configuration (JSON). Pendant la supervision d’une solution, la configuration est figée ; le serveur refuse de l’enregistrer jusqu’à l’annulation de la solution.
chaque seconde, pour chaque knowledge space surveillé dont la période est écoulée
solution = la Solution sélectionnée qui a des jumeaux EXPECTED_FREEZE # aucune : rien à superviser
si le monde attendu grossit encore : attendre (le clone est progressif)
référence = référence stockée, ou le monde attendu maintenant # une seule fois
contexte = terrain, attendu, référence, processus, To-Do Lists, impliqués, échéances, rôles
pour chaque stratégie cochée (celles qui observent les autres en dernier) :
valeurs = stratégie.compute(contexte, configuration) # part du seuil
catégorie = max(catégorie, valeur)
enregistrer un point si une valeur a changé, pousser supervisionStatusEvent
prochain calcul = maintenant + max(période, 5 s, 5 × durée de ce calcul)Le bouton radar de la barre d’outils de r-iota l’ouvre à tout moment. Avant la supervision d’une solution, elle montre les détecteurs à cocher et à configurer ; ensuite, les courbes passent en premier.
Boîte d’alerte — quand une catégorie d’alerte atteint 1 pour la première fois (et que la boîte de supervision n’est pas ouverte), une seule boîte s’ouvre sur la catégorie franchie la plus grave, avec les contributions qui l’expliquent et les adaptations : chercher de nouvelles solutions ou annuler la solution en cours. Le bouton radar passe au rouge.
Improvable — n’ouvre jamais la boîte : le bouton radar prend une pastille bleue et un bandeau discret signale qu’une meilleure solution existe peut-être ; l’opérateur peut le masquer.
Annuler la solution en cours — deux choix. Mémoriser les tâches déjà faites écrit sur la solution les tâches terminées, leurs acteurs, dates et sorties (memorized done tasks) avant l’annulation, pour que la déduction suivante puisse garder ces acteurs ; ne rien mémoriser repart de zéro, la déduction étant libre de choisir de meilleurs acteurs. Après l’annulation, les tâches des To-Do Lists apparaissent annulées, r-iota n’est plus supervisé, les alertes sont de nouveau visibles et une nouvelle recherche de solutions couvre tous les problèmes du moment.
La déduction ne lit pas encore memorized done tasks.
Sous /{app}/r-iota/supervision, pour la collaboration et le knowledge space de l’utilisateur. Voir aussi la référence de l’API.
| Appel | Réponse |
|---|---|
GET strategies | Toutes les stratégies trouvées : nom, description, catégories, nom de l’extension, cochée par défaut, configuration par défaut du projet. |
GET configuration · POST configuration | Les stratégies cochées, leurs configurations et la période ; l’enregistrement est refusé pendant la supervision d’une solution. |
GET state | Supervisé ou non, solution, période demandée et appliquée, durée du dernier calcul, historique des points. |
GET point?date= | Le point le plus proche d’une date, avec ses contributions. |
POST period {periodSeconds} | Change la période, y compris pendant la supervision (5 s minimum). |
POST compute | Calcule tout de suite. |
POST memorizeBeforeCancel {memorizeDoneTasks} | Écrit ou efface les tâches faites mémorisées de la solution avant son annulation. |
gind-webapp-r-iota/…/resources/supervision/SupervisionEngine.java · SupervisionResource.javaSessions, mondes, référence, période, historique, événement WebSocket, ressource REST.gind-detection-engine-abstract/…/monitoring/supervision/Contrat : AbstractSupervisionStrategy, SupervisionContext, SupervisionResult, SupervisionContribution, SupervisionCategory, ProcessGraph, SupervisionHelper.gind-detection-engine-<stratégie>/Un module par stratégie, déclaré par ServiceLoader.gind-npm-r-iota/…/detection-page/supervision/Boîte de supervision, boîte d’alerte, boîte d’annulation, chargeur d’extensions et catégories.gind-npm-strategy-supervision-<stratégie>/L’éditeur de configuration de chaque stratégie.