r-io suitededuction docsA link between two functions can carry a 2L Condition Evaluation: the dependent task is only executed when the condition holds at runtime. The deduction never decides the condition, since it usually reads the output of a task that has not run yet. Instead, it copies the condition onto the process flows, adds the flows that skip the task, and plans sibling tasks according to whether their conditions are exclusive or inclusive.
In the IMT Albi Crisis use case, Confirm gas leak implies Cut off the local gas valve when @Confirmed gas leak[Confirm gas leak] == "Yes and repairable" and Cut off the school gas supply when it equals "Yes and non-repairable". The answer is only known once the firefighter has confirmed the leak, so the deduced process keeps both branches and the engine follows the right one.
Implies, Supports and Needs edges between functions, with their Condition Evaluation property (2L code editor, hidden on the diagram, shown as a CE badge).@variable[Function name] reads an output variable of the task of that function.Sequence_Flows entering each guarded task.A condition always guards the dependent task, whatever the direction of the edge.
| Link | Guarded task | Planning |
|---|---|---|
A Implies B | B | B after A |
A Supports B | B | B in parallel with A (support task) |
B Needs A | B | B after A |
Copied onto every entering flow — the planning may insert other tasks before B, so the guard of B is copied onto every Sequence_Flow entering B. The quick access names the function explicitly, so the condition does not depend on the flow carrying it. Several conditions guarding the same task are combined with a logical AND, their local variables being renamed so that they do not collide.
One otherwise flow per source and condition — the process must not stay blocked before B when the guard is false: a flow X → End_Event named otherwise carries the negated guard (id <conditioned flow id>__otherwise). Conditioned flows leaving the same node with the same condition, written differently or not, share one otherwise flow.
Objectives released — following an otherwise flow skips B and the tasks only reachable through B. Their objectives will never be reached by a task completion, so the flow lists them in its releasesObjectives property and the engine releases their EXPECTED_FREEZE twin.
for flow X -> T in process.sequenceFlows:
guard = AND(conditions of the links guarding T)
if guard is empty: continue
flow.condition = guard
key = (X, canonical(guard)) # one otherwise per key
otherwise[key] = X -> End_Event
condition = NOT guard
releasesObjectives += objectives of T
and of the tasks only reachable through TSibling tasks depend on the same task through conditioned links (A Implies B and A Implies C, or B Needs A and C Needs A). Their guards are compared term by term, the terms being those of their logical AND.
| Relation | Detected when two terms are | At runtime | Planning |
|---|---|---|---|
| Exclusive | the same expression compared with == to two different literals · compared with == and != to the same literal · an expression and its negation ! | at most one of the tasks runs | never ordered against each other, may share actors and resources |
| Inclusive | any other case, same or different conditions | both, one or none of the tasks run | optional support tasks: in parallel when possible, in sequence otherwise |
The literal may be on either side of the comparison, and a condition written boolean ok = <expression>; ok; is analysed through the initial value of its local variables. A term that still depends on the statements of the condition cannot be compared and is considered compatible.
Two conditions are the same when their canonical writing is identical: the 2L code is parsed and printed again, so spaces, line breaks and a missing trailing ; do not matter.
@x[F] == "a" vs @x[F] == "b" # exclusive @x[F] == "a" vs @x[F] != "a" # exclusive @ok[F] vs !@ok[F] # exclusive @x[F] == "a" && @n[F] > 3 vs @x[F] == "b" # exclusive @x[F] == "a" vs @y[F] == "b" # inclusive @n[F] > 3 vs @n[F] < 2 # inclusive (not detected) @x[F] == "a" || @y[F] vs @x[F] == "b" # inclusive
The scheduler used to place a task after its sibling as soon as they shared an actor or a resource. With exclusive guards this made the second branch unreachable: to reach it, the process had to go through the first one, whose condition is its opposite.
Scheduler — each scheduled task knows the ids of the tasks exclusive with it (ScheduleTask.exclusiveTaskIds). The time slots they reserved never make it unavailable, so every exclusive branch starts right after the common task, each with its own condition. Nor is a task ever chained after an exclusive one: it would only be reached in the other branch.
Actors of support tasks — support tasks of the same task normally need distinct actors. Exclusive support tasks never run together, so they may share one (ResourceTask.exclusiveFunctionIds).
Inherited by descendants — a function is guarded by its own links and by the guards of the functions it depends on (Implies, Supports, Needs): with “B Implies D”, D is exclusive with C as B is. A function depending on several functions keeps only the conditions they all share, since any of them may lead to it.
Moves — a move inserted by the move improver (“Move to <task>”, whose only flow goes to that task) stands for its task: same guard, same prerequisites, skipped with it. The condition is carried by the flow entering the move, not by the flow from the move to its task.
Start -> Confirm gas leak
Confirm gas leak -> Cut off the local gas valve
[@Confirmed gas leak[Confirm gas leak] == "Yes and repairable"]
Confirm gas leak -> Cut off the school gas supply
[@Confirmed gas leak[Confirm gas leak] == "Yes and non-repairable"]
Confirm gas leak -> End # otherwise, one per branchWith two inclusive conditions C1 (task B) and C2 (task C), four outcomes must stay possible: C1 and C2, C1 only, C2 only, none.
Optional support tasks — inclusive siblings prefer different actors: the actors already assigned to a sibling are offered last (ResourceAssigner.prioritizeActorsFreeOfInclusiveTasks). When another actor is available the tasks run in parallel. Otherwise the same actor is kept and the scheduler places them in sequence; the solution is not lost.
Bypass flows — when the planning placed C after B, although B is not a prerequisite of C, and B may be skipped while C is not (a condition of B does not guard C), C would become unreachable when B is skipped. For each flow P → B, a flow P → C named bypass (id <P id>__bypass__<C id>) carries guard(C) AND NOT guard(B). Its own otherwise flow (id ending with __skipped__otherwise) carries NOT guard(B) AND NOT guard(C) and releases the objectives of C. Longer chains are bypassed recursively. No bypass is added when the two guards are the same: C then runs exactly when B runs.
| Outcome | Followed flows |
|---|---|
| C1 and C2 | A → B, then B → C |
| C1 only | A → B, then B → End (otherwise of C, releases C) |
| C2 only | A → End (otherwise of B, releases B) and A → C (bypass) |
| none | A → End (otherwise of B) and A → End (skipped otherwise, releases C) |
A link condition is always a branch, read once when the source task ends. To hold a task until a situation changes (a flood to recede before a bridge is inspected), the model places a Mediation function with the operation Wait Until between the two functions, linked by plain Implies links.
The wait function — it carries a 2L Wait Condition ($source = the wait task, $target = the task it leads to), a Wait Polling (s) (5 by default) and a Function:duration given as a range, for instance 6 to 24 h. It needs no actor; the deduced task is a Mediation task that copies the condition and the polling (WaitTasks).
Planning — a range duration is planned with its minimum, which gives the earliest dates. Every task after the wait gets an expected latest end date on its Plans edge, its planned end plus the width of the range: it is planned in a window. The deadline of an objective does not apply to the tasks after a wait.
At run time — the engine evaluates the condition every Wait Polling (s) (WaitUntilSkill) and ends the wait as soon as it is true; a condition that cannot be evaluated yet keeps waiting. Only that branch waits. The wait stops without completing when the process ends, and it is not observed in simulation. In r-iota a task after a wait is late only after its latest end.
Close a bridge to traffic
-> Wait until a bridge can be inspected
[Wait Condition: the flood is over
and the risk is below 0.8] # every 5 s
# duration 6 to 24 h
-> Inspect a bridge after a flood
# planned from the earliest end of the wait,
# latest end 18 h laterThe conditions of the wait functions are written in the 2L language reference.
PRIOTransitionController, SequenceFlowConditionEvaluator). A condition that fails to evaluate counts as false.__otherwise suffix, so exactly one of both is followed. A skipped otherwise has no conditioned flow of that id and is evaluated on its own condition.ObjectiveTaskGraph); a task still reachable by another flow, such as a bypass, is not skipped. The r-io suite web application then releases the EXPECTED_FREEZE twin of the objectives whose graph is finished, including when the process ends. Recovery tasks entered only by an Exception_Flow or Event_Flow are not part of the graph. Without that listener, the engine falls back to the objectives listed in releasesObjectives of the otherwise flow (OtherwiseFlowObjectiveRelease).Exclusivity is detected on the syntax of the conditions: @n[F] > 3 and @n[F] < 2 are exclusive but treated as inclusive. The result stays correct, since bypass flows keep every outcome reachable, but the plan may be longer than necessary. A real expression solver is planned.
@x[F] == Yes and non-repairable is a syntax error: the condition cannot be evaluated, the flow is never followed and its otherwise flow always is. Write "Yes and non-repairable", exactly as the value of the output variable.
The otherwise, bypass and skipped otherwise flows are plain model edges added when the process model is built. Their ids are deterministic: the same process always gives the same flows.
A different actor is only preferred, never required: with a single actor of the role, inclusive tasks are planned in sequence with bypass flows.
gind-governance-workflow-deduction-strategy-abstract/…/process/edges/FunctionLinkConditions.javaGuards, combination and negation, exclusive and inclusive functions, otherwise and bypass flows.gind-governance-workflow-planner-default/…/scheduler/Scheduler.java · ScheduleProcess.javaExclusive tasks never block each other.gind-governance-workflow-planner-default/…/resources/ResourceTaskGraph.java · ResourceAssigner.javaExclusive and inclusive functions of the task graph, actor preference of inclusive tasks.gind-workflow-engine-prio/…/boundary/SequenceFlowConditionEvaluator.java · OtherwiseFlowObjectiveRelease.javaRuntime evaluation and release of the skipped objectives.…/process/nodes/WaitTasks.java · gind-workflow-engine-prio/…/skill/mediation/WaitUntilSkill.javaWait functions (Mediation, Wait Until): no actor, copied condition and polling, waiting at run time.gind-models-collaborative-model/…/Collaborative_MetaModel.xmlCondition Evaluation of Implies, Supports, Needs and Sequence_Flow; Wait Condition and Wait Polling (s) of the functions and tasks.Un lien entre deux fonctions peut porter une Condition Evaluation 2L : la tâche dépendante ne s’exécute que si la condition est vraie à l’exécution. La déduction ne tranche jamais la condition, qui lit en général la sortie d’une tâche pas encore exécutée. Elle recopie la condition sur les flux du processus, ajoute les flux qui sautent la tâche et planifie les tâches sœurs selon que leurs conditions sont exclusives ou inclusives.
Dans le cas d’usage IMT Albi Crisis, Confirm gas leak implique Cut off the local gas valve quand @Confirmed gas leak[Confirm gas leak] == "Yes and repairable" et Cut off the school gas supply quand la valeur vaut "Yes and non-repairable". La réponse n’est connue qu’une fois la fuite confirmée par le pompier : le processus déduit garde les deux branches et le moteur suit la bonne.
Implies, Supports et Needs entre fonctions, avec leur propriété Condition Evaluation (éditeur de code 2L, masquée sur le diagramme, signalée par un badge CE).@variable[Nom de la fonction] lit une variable de sortie de la tâche de cette fonction.Sequence_Flow conditionnés entrant dans chaque tâche gardée.Une condition garde toujours la tâche dépendante, quel que soit le sens de l’arête.
| Lien | Tâche gardée | Planification |
|---|---|---|
A Implies B | B | B après A |
A Supports B | B | B en parallèle de A (tâche support) |
B Needs A | B | B après A |
Recopiée sur chaque flux entrant — la planification peut insérer d’autres tâches avant B : la garde de B est donc recopiée sur chaque Sequence_Flow entrant dans B. L’accès rapide nomme explicitement la fonction, la condition ne dépend donc pas du flux qui la porte. Plusieurs conditions gardant la même tâche sont combinées par un ET logique, leurs variables locales étant renommées pour ne pas entrer en collision.
Un flux otherwise par source et par condition — le processus ne doit pas rester bloqué avant B quand la garde est fausse : un flux X → End_Event nommé otherwise porte la garde niée (id <id du flux conditionné>__otherwise). Les flux conditionnés qui quittent le même nœud avec la même condition, écrite de la même façon ou non, partagent un seul flux otherwise.
Objectifs libérés — suivre un flux otherwise saute B et les tâches atteignables seulement par B. Leurs objectifs ne seront jamais atteints par la fin d’une tâche : le flux les liste dans sa propriété releasesObjectives et le moteur libère leur jumeau EXPECTED_FREEZE.
pour chaque flux X -> T du processus :
garde = ET(conditions des liens gardant T)
si garde vide : continuer
flux.condition = garde
cle = (X, canonique(garde)) # un otherwise par clé
otherwise[cle] = X -> End_Event
condition = NON garde
releasesObjectives += objectifs de T
et des tâches atteignables seulement par TDes tâches sœurs dépendent de la même tâche par des liens conditionnés (A Implies B et A Implies C, ou B Needs A et C Needs A). Leurs gardes sont comparées terme à terme, les termes étant ceux de leur ET logique.
| Relation | Détectée quand deux termes sont | À l’exécution | Planification |
|---|---|---|---|
| Exclusive | la même expression comparée par == à deux littéraux différents · comparée par == et != au même littéral · une expression et sa négation ! | au plus une des tâches s’exécute | jamais ordonnées l’une par rapport à l’autre, peuvent partager acteurs et ressources |
| Inclusive | tous les autres cas, conditions identiques ou différentes | les deux, une seule ou aucune des tâches s’exécutent | tâches supports optionnelles : en parallèle si possible, sinon en séquence |
Le littéral peut être de part ou d’autre de la comparaison, et une condition écrite boolean ok = <expression>; ok; est analysée à travers la valeur initiale de ses variables locales. Un terme qui dépend encore des instructions de la condition ne peut pas être comparé : il est considéré comme compatible.
Deux conditions sont identiques quand leur écriture canonique est la même : le code 2L est analysé puis réimprimé, les espaces, retours à la ligne et un ; final manquant ne comptent donc pas.
@x[F] == "a" vs @x[F] == "b" # exclusives @x[F] == "a" vs @x[F] != "a" # exclusives @ok[F] vs !@ok[F] # exclusives @x[F] == "a" && @n[F] > 3 vs @x[F] == "b" # exclusives @x[F] == "a" vs @y[F] == "b" # inclusives @n[F] > 3 vs @n[F] < 2 # inclusives (non détecté) @x[F] == "a" || @y[F] vs @x[F] == "b" # inclusives
Le planificateur plaçait une tâche après sa sœur dès qu’elles partageaient un acteur ou une ressource. Avec des gardes exclusives, la seconde branche devenait inatteignable : pour l’atteindre, il fallait passer par la première, dont la condition est son contraire.
Ordonnanceur — chaque tâche ordonnancée connaît les ids des tâches exclusives avec elle (ScheduleTask.exclusiveTaskIds). Les créneaux qu’elles ont réservés ne la rendent jamais indisponible : chaque branche exclusive démarre juste après la tâche commune, avec sa propre condition. Une tâche n’est jamais non plus enchaînée après une tâche exclusive : elle ne serait atteinte que dans l’autre branche.
Acteurs des tâches supports — les tâches supports d’une même tâche exigent normalement des acteurs distincts. Des tâches supports exclusives ne s’exécutent jamais ensemble et peuvent donc en partager un (ResourceTask.exclusiveFunctionIds).
Héritée par les descendants — une fonction est gardée par ses propres liens et par les gardes des fonctions dont elle dépend (Implies, Supports, Needs) : avec « B Implies D », D est exclusive avec C comme B. Une fonction qui dépend de plusieurs fonctions ne garde que les conditions qu’elles ont toutes en commun, puisque chacune peut y mener.
Déplacements — un déplacement inséré par l’améliorateur de déplacements (« Move to <tâche> », dont le seul flux mène à cette tâche) représente sa tâche : même garde, mêmes prérequis, sauté avec elle. La condition est portée par le flux qui entre dans le déplacement, pas par celui qui va du déplacement à sa tâche.
Start -> Confirm gas leak
Confirm gas leak -> Cut off the local gas valve
[@Confirmed gas leak[Confirm gas leak] == "Yes and repairable"]
Confirm gas leak -> Cut off the school gas supply
[@Confirmed gas leak[Confirm gas leak] == "Yes and non-repairable"]
Confirm gas leak -> End # otherwise, un par brancheAvec deux conditions inclusives C1 (tâche B) et C2 (tâche C), quatre sorties doivent rester possibles : C1 et C2, C1 seule, C2 seule, aucune.
Tâches supports optionnelles — les tâches sœurs inclusives préfèrent des acteurs différents : les acteurs déjà affectés à une sœur sont proposés en dernier (ResourceAssigner.prioritizeActorsFreeOfInclusiveTasks). Si un autre acteur est disponible, les tâches s’exécutent en parallèle. Sinon le même acteur est gardé et l’ordonnanceur les place en séquence : la solution n’est pas perdue.
Flux bypass — quand la planification a placé C après B alors que B n’est pas un prérequis de C, et que B peut être sautée sans que C le soit (une condition de B ne garde pas C), C deviendrait inatteignable quand B est sautée. Pour chaque flux P → B, un flux P → C nommé bypass (id <id de P>__bypass__<id de C>) porte garde(C) ET NON garde(B). Son propre flux otherwise (id terminé par __skipped__otherwise) porte NON garde(B) ET NON garde(C) et libère les objectifs de C. Les chaînes plus longues sont contournées récursivement. Aucun bypass n’est ajouté quand les deux gardes sont identiques : C s’exécute alors exactement quand B s’exécute.
| Sortie | Flux suivis |
|---|---|
| C1 et C2 | A → B, puis B → C |
| C1 seule | A → B, puis B → End (otherwise de C, libère C) |
| C2 seule | A → End (otherwise de B, libère B) et A → C (bypass) |
| aucune | A → End (otherwise de B) et A → End (otherwise « skipped », libère C) |
Une condition de lien est toujours un aiguillage, lu une fois à la fin de la tâche source. Pour retenir une tâche jusqu’à ce qu’une situation change (une crue qui doit refluer avant d’inspecter un pont), le modèle place une fonction Mediation d’opération Wait Until entre les deux fonctions, reliées par de simples liens Implies.
La fonction d’attente — elle porte une Wait Condition 2L ($source = la tâche d’attente, $target = la tâche à laquelle elle mène), un Wait Polling (s) (5 par défaut) et une Function:duration donnée par un intervalle, par exemple 6 à 24 h. Elle n’a besoin d’aucun acteur ; la tâche déduite est une tâche Mediation qui recopie la condition et la scrutation (WaitTasks).
Planification — une durée en intervalle est planifiée avec son minimum, ce qui donne les dates au plus tôt. Chaque tâche qui suit l’attente reçoit une expected latest end date sur son arête Plans, sa fin planifiée plus la largeur de l’intervalle : elle est planifiée dans une fenêtre. L’échéance d’un objectif ne s’applique pas aux tâches qui suivent une attente.
À l’exécution — le moteur évalue la condition toutes les Wait Polling (s) (WaitUntilSkill) et termine l’attente dès qu’elle est vraie ; une condition pas encore évaluable continue d’attendre. Seule cette branche attend. L’attente s’arrête sans se terminer quand le processus finit, et elle n’est pas observée en simulation. Dans r-iota, une tâche qui suit une attente n’est en retard qu’après sa fin au plus tard.
Close a bridge to traffic
-> Wait until a bridge can be inspected
[Wait Condition : la crue est terminée
et le risque est sous 0,8] # toutes les 5 s
# durée 6 à 24 h
-> Inspect a bridge after a flood
# planifiée depuis la fin au plus tôt de l’attente,
# fin au plus tard 18 h plus tardLes conditions des fonctions d’attente sont écrites dans la référence du langage 2L.
PRIOTransitionController, SequenceFlowConditionEvaluator). Une condition dont l’évaluation échoue compte comme fausse.__otherwise, donc exactement un des deux est suivi. Un otherwise « skipped » n’a pas de flux conditionné de cet id et est évalué sur sa propre condition.ObjectiveTaskGraph) ; une tâche encore atteignable par un autre flux, comme un bypass, n’est pas sautée. L’application web de r-io suite libère alors le jumeau EXPECTED_FREEZE des objectifs dont le graphe est terminé, y compris à la fin du processus. Les tâches de reprise entrées seulement par un Exception_Flow ou un Event_Flow ne font pas partie du graphe. Sans cet écouteur, le moteur se rabat sur les objectifs listés dans releasesObjectives du flux otherwise (OtherwiseFlowObjectiveRelease).L’exclusivité est détectée sur la syntaxe des conditions : @n[F] > 3 et @n[F] < 2 sont exclusives mais traitées comme inclusives. Le résultat reste correct, puisque les flux bypass gardent toutes les sorties atteignables, mais le plan peut être plus long que nécessaire. Un vrai solveur d’expressions est prévu.
@x[F] == Yes and non-repairable est une erreur de syntaxe : la condition ne peut pas être évaluée, le flux n’est jamais suivi et son flux otherwise l’est toujours. Écrire "Yes and non-repairable", exactement comme la valeur de la variable de sortie.
Les flux otherwise, bypass et otherwise « skipped » sont de simples arêtes ajoutées à la construction du modèle de processus. Leurs ids sont déterministes : le même processus donne toujours les mêmes flux.
Un acteur différent est seulement préféré, jamais exigé : avec un seul acteur du rôle, les tâches inclusives sont planifiées en séquence avec des flux bypass.
gind-governance-workflow-deduction-strategy-abstract/…/process/edges/FunctionLinkConditions.javaGardes, combinaison et négation, fonctions exclusives et inclusives, flux otherwise et bypass.gind-governance-workflow-planner-default/…/scheduler/Scheduler.java · ScheduleProcess.javaLes tâches exclusives ne se bloquent jamais.gind-governance-workflow-planner-default/…/resources/ResourceTaskGraph.java · ResourceAssigner.javaFonctions exclusives et inclusives du graphe de tâches, préférence d’acteurs des tâches inclusives.gind-workflow-engine-prio/…/boundary/SequenceFlowConditionEvaluator.java · OtherwiseFlowObjectiveRelease.javaÉvaluation à l’exécution et libération des objectifs sautés.…/process/nodes/WaitTasks.java · gind-workflow-engine-prio/…/skill/mediation/WaitUntilSkill.javaFonctions d’attente (Mediation, Wait Until) : sans acteur, condition et scrutation recopiées, attente à l’exécution.gind-models-collaborative-model/…/Collaborative_MetaModel.xmlCondition Evaluation d’Implies, Supports, Needs et Sequence_Flow ; Wait Condition et Wait Polling (s) des fonctions et des tâches.