Not interpreted although the parser accepts them: %, ++ / --, the ternary ?:, casts and instanceof (use isInstanceOf("Concept")). Compound assignments (+=…) behave like a plain =. A local variable cannot be assigned again after its declaration: declare a new one. There are no parentheses in expressions: (a || b) && c does not parse; write intermediate boolean variables instead (boolean cleared = …; boolean reopen = cleared && riskLow;).

A traversal gives null when nothing matches, the node when one does, a list otherwise. Reference copies embedded in solutions are left out, as in findNodeInstance. An unknown relation or concept is an error.

Node sensor = $target <-[Fixed_Onto]- ("Loire water level - Orleans");   // Orléans: the sensor fixed onto the bridge
if($target <-[Fixed_Onto]- ("Barbecue thermal sensor").currentValue >= 50) { … }   // Barbecue
Node objectiveRiskBurns = riskBurns <-[Prevents]- ("Prevent Henri risks getting burned");
List<Node> risks = potential <-[Generated_By]- ();   // Healthcare: the risks generated by the potential
risk <-[Prevents]- ().active();
Node risk = objective -[Prevents]-> (Risk);            // crisis roles: the risk the objective prevents
Node flood = risk <-[Generated_By]- (Actuality);

Only properties whose name is a valid identifier can be read with the dot (currentValue, probability, name). Writing a property (risk.probability = remaining / span;) updates a metric’s precise value or stores the text of the value; a property the node does not have is not created.

A Wait Condition is written on a Mediation function with the operation Wait Until, placed between two functions linked by plain Implies links; the task deduced from it copies the condition and its Wait Polling (s). It is evaluated the same way, every polling interval: $source is the wait, $target the task it leads to, so $target.createdFor() gives the objective that task was deduced for. A condition that cannot be evaluated yet keeps waiting; the wait stops without completing when the process ends, and is not observed in simulation (see waiting).

At deduction, the conditions of conditioned links are also replayed on every value their variables may take, to give each indicator of a branching solution an interval (see conditioned links).

“Rules only”: in a condition the call is allowed but nothing is saved. During the registration dry run these calls do nothing.

Orléans Flood Crisis — a danger zone that follows the Loire

The potential Loire flooding is Generated_By the George-V bridge. Its rule reads the water level sensor fixed onto the bridge: from 1.50 m the zone is active, centred on the sensor, with a radius of 50 m per metre of water; below, it is frozen and shrunk.

Node sensor = $target <-[Fixed_Onto]- ("Loire water level - Orleans");
if(sensor.currentValue >= 1.5) {
  Float radius = sensor.currentValue * 50;
  $source.active();
  $source.getGeoloc().setRadius(radius);
  $source.getGeoloc().setPosition(sensor.getGeoloc().getPosition());
} else {
  $source.freeze();
  $source.getGeoloc().setRadius(0);
  $source.getGeoloc().setPosition(null);
}

The risk George-V bridge flood risk is Generated_By that zone. From 2.50 m, the CEP rules of the sensor write its probability by tiers: 0.2 at 2.50 m, 0.5 at 3.50 m, 0.8 at 4.00 m and 1 at 4.50 m. Below 2.50 m no CEP threshold is ever crossed, so 2L sets the low tier: the risk is active at 0.05 as soon as the zone is. This rule replaces the default one, which would copy the probability of the zone onto the risk and overwrite the CEP tiers.

Node risk = $source;
Node zone = $target;
Node sensor = findNodeInstance("Sensor", "Loire water level - Orleans");
if(zone.isActive() && sensor.currentValue < 2.5 && risk.isFreeze()) {
  risk.probability = 0.05;
  risk.active();
  risk.getGeoloc().setPosition(sensor.getGeoloc().getPosition());
}
if(zone.isFreeze() && sensor.currentValue < 2.5 && risk.isActive()) {
  risk.probability = 0;
  risk.freeze();
  risk.getGeoloc().setPosition(null);
}

At 4.50 m the probability reaches 1: the Generated_By rule of the actuality Loire flood at George-V bridge activates it at the place of the risk and freezes the risk (if($target.probability >= 1), as in the default rule). The flood does not end as soon as the water goes down: the sensor threshold that raised it is released only once the level has stayed below 4.00 m for 6 hours (see Sensor interceptor).

Orléans Flood Crisis — waiting for the flood to recede before reopening

In the shared crisis roles, the Mediation function Wait until a bridge can be inspected sits between Close a bridge to traffic and Inspect a bridge after a flood, linked by plain Implies links. Its duration is a range of 6 to 24 h and it polls every 5 s. The deduced process closes the bridge, then the wait holds the inspection, and what follows it, until the condition is true; the tasks after it are planned in a window, from the shortest to the longest wait. The condition is generic: it finds the flood through the objective the inspection was deduced for, so the same function serves any bridge and any flood.

Node objective = $target.createdFor();
Node risk = objective -[Prevents]-> (Risk);
Node flood = risk <-[Generated_By]- (Actuality);
boolean cleared = flood == null || !flood.isActive();
boolean riskLow = risk == null || risk.probability < 0.8;
boolean reopen = cleared && riskLow;
reopen;

In the corrective procedure, Wait until the flood has receded sits the same way between Cut the utility networks crossing a bridge and Restore the utility networks crossing a bridge (6 to 24 h, every 5 s): the networks are restored once the flood the objective treats is no longer active.

Node objective = $target.createdFor();
Node flood = objective -[Treats]-> (Actuality);
boolean cleared = flood == null || !flood.isActive();
cleared;

Barbecue — a burn risk that grows as Henri gets closer

The potential High Temperature is a 6 m zone around the barbecue, active while its thermal sensor reads 50 or more. The risk Henri risks getting burned is Generated_By that zone: its probability goes from 0 at the edge of the zone to 1 at 1.5 m from the barbecue, where the alert Henri burns takes over.

Node riskBurns = $source;
Node highTemperature = $target;
Node objectiveRiskBurns = riskBurns <-[Prevents]- ("Prevent Henri risks getting burned");
Node actualityBurns = findNodeInstance("Alert", "Henri burns");
Node barbecue = findNodeInstance("Good", "Barbecue");
Node henri = findNodeInstance("Kid", "Henri Martinez");
if(henri != null && highTemperature.isActive() && actualityBurns.isFreeze() && henri.getGeoloc().getPosition().distanceTo(barbecue.getGeoloc().getPosition()) <= highTemperature.getGeoloc().radius) {
  Float distance = henri.getGeoloc().getPosition().distanceTo(barbecue.getGeoloc().getPosition());
  Float zoneRadius = highTemperature.getGeoloc().radius;
  if(distance > 1.5) {
    Float remaining = zoneRadius - distance;
    Float span = zoneRadius - 1.5;
    riskBurns.probability = remaining / span;
    riskBurns.getGeoloc().setPosition(henri.getGeoloc().getPosition());
    riskBurns.active();
    objectiveRiskBurns.active();
  }
} else {
  if(actualityBurns.isFreeze()) {
    riskBurns.probability = 0;
    riskBurns.freeze();
    objectiveRiskBurns.freeze();
  }
}

The drowning alert combines a distance and an area: Henri must be within 10 m of the pool and inside its polygon.

if(henri != null && henri.getGeoloc().getPosition().distanceTo(swimmingPool.getGeoloc().getPosition()) <= 10 && henri.isInside(swimmingPool)) {
  riskSubmersion.probability = 1;
  riskSubmersion.freeze();
  objectiveRiskSubmersion.freeze();
  actualitySubmersion.getGeoloc().setPosition(henri.getGeoloc().getPosition());
  actualitySubmersion.active();
  objectiveActualitySubmersion.active();
}

IMT Albi Healthcare — a susceptibility rule that walks the graph

A healthcare software is Is_Susceptible_To the potential Danger of Electrical Failure. The rule iterates over the risks that potential generates and activates each one, with its preventing objective, while the software lies inside the active zone and the risk is not yet certain.

Node software = $source;
if(software.isInstanceOf("Good")) {
  Node potential = $target;
  List<Node> risks = potential <-[Generated_By]- ();
  for(Node risk: risks) {
    if(potential.isActive() && software.isInside(potential) && risk.probability < 1) {
      risk.active();
      if(risk <-[Prevents]- () != null) {
        risk <-[Prevents]- ().active();
      }
      risk.getGeoloc().setPosition(software.getGeoloc().getPosition());
    } else {
      risk.freeze();
      if(risk <-[Prevents]- () != null) {
        risk <-[Prevents]- ().freeze();
      }
      risk.getGeoloc().setPosition(null);
    }
  }
}

IMT Albi Crisis — conditioned links and a qualified corrective

The function Confirm gas leak implies two functions, each guarded by the answer the firefighter gives in the output variable Confirmed gas leak. The two conditions are exclusive: the deduced process keeps both branches and the engine follows one (see conditioned links).

@Confirmed gas leak[Confirm gas leak] == "Yes and repairable"
@Confirmed gas leak[Confirm gas leak] == "Yes and non-repairable"

When the deduction selects a corrective for a risk found by the ML detection, the planner writes the condition of the Event_Flow attached to the nominal sub-task. The actuality name alone is not enough, since the same Power outage can be generated by several risks: the condition also requires the actuality to be linked to the validated risk, in either direction, since the ML detection writes the Generated_By edge from the risk to the actuality and a modelled use case usually the other way (corrective procedures walkthrough).

Node triggerActuality = findNodeInstance("Actuality", "Power outage");
boolean generated = triggerActuality <-[Generated_By]- ("Power outages") != null || triggerActuality -[Generated_By]-> ("Power outages") != null;
boolean triggered = triggerActuality.isActive() && generated;
triggered;

An implementation risk attached to a task gets an Exception_Flow instead, whose generated condition only watches the actuality (recovery procedures walkthrough):

findNodeInstance("Actuality", "Healthcare software unavailability for Blood Test Request Function").isActive()

• gind-dsl-2l-parser: grammar src/main/resources/grammar/2L.jjt, LLInterpretor (statements, operators, conditions), LLSpecificMethod and LLSpecificMathMethod (methods), LLManager (registration, waves, toConditionBlock), LLManagerNotifier (triggers); rule RelationTraversal of the grammar and traverse of the interpreter for the arrows.
• Collaborative_MetaModel.xml: the RIO_2L properties of Generated_By, Is_Susceptible_To, Impacts, Generates, Implies, Supports, Needs, Sequence_Flow, Event_Flow and Exception_Flow.
• GeneratedByModelsPopulateInterceptor: default activation conditions of Generated_By.
• gind-workflow-engine-prio, package boundary: SequenceFlowConditionEvaluator, PrioEventFlowHandler, PrioBoundaryExceptionHandler, ExecutionTaskVariableResolver.
• WaitTasks (deduction) and WaitUntilSkill (PRIO engine) for the “Wait Until” Mediation functions.
• RioDefaultPlanner and ResourceTaskGraph (generated Event_Flow and Exception_Flow conditions); rio2-lauto-complete.service.ts of gind-npm-utils (completion in the code editor).