Skip to content
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
80 changes: 80 additions & 0 deletions content/language-reference/query-syntax/controller_synthesis.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@ ControlQuery ::=
| PartialControlSpecifier Goal Subjection
| TimeEfficientGameSpecifier Goal
| ApproximateControlSpecifier // In section below
| TatlExpression // In section below

ControlSpecifier ::=
'control:'
Expand Down Expand Up @@ -115,3 +116,82 @@ strategy shield = acontrol: A[] water_level < 10 && water_level > 0 { WaterTank.
```

Declares a strategy called `shield` to enforce the desired invaraint `water_level < 10 && water_level > 0`. The system has two, state variables. First, the `WaterTank` template has 5 locations, so `WaterTank.location` has 5 possible values. The second variable, `water_level[-1, 11]:24` is a double which gets split up into 24 intervals, with the corresponding size of 0.5. So the partition will contain `5·24 = 120` cells.


### Timed Alternating-Time Temporal Logic (TATL)

{{% notice info %}}
TATL queries are available in the UPPAAL TATL version only.
{{% /notice %}}

{{% notice info %}}
Due to some yet-to-be resolved parsing conflicts, TATL sub-expressions are wrapped in parenthesis if they themselves are also valid TATL expressions.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like you are fighting with bison, let me know if you need help

{{% /notice %}}

```EBNF
TatlExpression ::=
Identifier '@' TatlExpressionOrExpression // (A)
| TatlCoalition TatlPathProp
;

TatlCoalition ::=
'<<' PlayerColorList '>>' // (B1)
| '[[' PlayerColorList ']]' // (B2)
;

TatlPathProp ::=
'[' TatlExpressionOrExpression 'U' TatlExpressionOrExpression ']' // (C1)
| '<>' TatlExpressionOrExpression // (C2)
| '[]' TatlExpressionOrExpression // (C3)
| 'X' TatlExpressionOrExpression // (C4)
;

TatlExpressionOrExpression ::=
'(' TatlExpression ')'
| '(' TatlExpression ')' BoolOrKWAnd TatlExpressionOrExpression
| '(' TatlExpression ')' BoolOrKWOr TatlExpressionOrExpression
| '!' '(' TatlExpression ')'
| Expression
;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The conflicts are probably in this rule:
Expression already handle boolean operations, so bison is confused which rule to apply.
Perhaps TatlExpression could be part of Expression and then typechecker could enforce the rules when it can be invoked?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think TatlExpression should be an Expression. If I recall correctly, I tried that originally, but it had another conflict. I can try it again and let you know if I run into issues.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other conflict was likely related to << and >> being left and right shift operators, and [ and ] being subscript operators.


PlayerColorList ::=
/* empty */
| PlayerColor
| PlayerColorList ',' PlayerColor
;

PlayerColor ::=
'black' | 'lightgray' | 'darkgray' | 'red' | 'green' | 'blue' | 'yellow' | 'cyan' | 'magenta' | 'orange' | 'pink' ;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using literal colors is quite limiting:

  1. it seems that TATL supports only upo to 11 colors (is that true?)
  2. color-blind users will have issues

It would be better to simply allocate an integer-indexed color type, like typed enum (and then use user-customizable pallete during visualization), e.g. color(7) or simply 7, then the names can be added as specific constant values of integer type (ultimately color type). I could also help with that.

A similar technique is applied in Gantt chart, except the color palette is a bit weird (after 16 colors repeat in different shades), the named constants are not defined, and nobody bothered to implement user customizable palette (that users could choose for their best contrast).

It would be interesting to see what solution colored petri nets use.

Copy link
Author

@NicEastvillage NicEastvillage Nov 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has limitations, indeed, but it was by far the easiest way to get this prototype up and running - I didn't have to add any new GUI features, just parse 11 new keywords. As I mention in https://github.com/UPPAALModelChecker/uppaal/pull/1300, I think the ideal solution introduces a new type that can also be used in template parameters and quantification on edges. For example, I want to be able to

  • make a template with a parameter PlayerColor p1 and then "color" an edge the p1 color (such that I can instantiate MyProcess(red), MyProcess(blue), MyProcess(green), etc).
  • make a "multicolored" edge using a similar expression like the selector expression, e.g. thisEdgesColor : PlayerColor for any color.

I think we could have a long discussion on the design of this new type, if that is the direction we want to go, but I believe my solution is sufficient for the prototype I aim to release.

In Tapaal's colored petri net, colors are defined using number intervals as types and numbers as instances. Raw numbers might lead to ambiguity in Uppaal.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without the latter bullet point, you have to do this for a synchronization with anyone:
multicolored edge

```

Alternating-Time Temporal (ATL) logic is an extension of computation-tree logic (CTL), where the traditional for-all- and exists path quantifiers have been replaced with outcome quantifiers, quantifying over the possible outcome paths resulting from a coalition of players working together. The timed extension comes from the addition of the freeze operator.

- **(A) The freeze operator.** The left-hand side must be a globally defined clock that is not used in any automata (undefined behavior otherwise). `z @ RHS` is satisfied if the right-hand side is satisfied after the clock `z` is reset in the current state.
- **(B) Outcome quantifiers.**
- `<< S >> rho` (B1) is satisfied if there *exist* strategies for the players `S` such that *all* outcome paths satisfies path property `rho`.
- `[[ S ]] rho` (B2) is satisfied if there *exists* an outcome path satisfying `rho` for *all* strategies the players `S`.
- Empty clauses: `<< >>` is equivalent to `A`, and `[[ ]]` is equivalent to `E`.
- **(C) Path Properties.** Your typical CTL temporal operators. Note that `X` is the next *location* operator.

#### Players

TATL queries are defined over timed *multi-player* games. A TATL query considers each edge color a different player (it does not matter if an edge is marked uncontrollable).
There are 11 different edge colors available in the UPPAAL GUI and they are referred to using their natural language name, i.e. `red`, `green`, `blue`, etc.

The semantics are similar to that of a standard 2-player game. The player `red` may activate enabled red edges at any time, and must do it in a timed-locked state, if any is enabled.
If two players activate an edge in the same instant, it is non-deterministic which activation happens.
If a synchronization involves more than one player, it is consider "uncontrollable", unless they are all working together.

#### Examples

`<< green >> [] safe`
: satisfied if there exists a strategy for `green` such that only `safe` states are visited (despite the actions of other players).

`[[ red ]] [ safe U goal ]`
: satisfied if the system *can* stay in `safe` states until eventually reaching a `goal` state despite the actions of player `red`.

`<<>> [] (<<red, blue>> <> goal)`
: satisfied if in all reachable states `red` and `blue` can cooperate such that `goal` is eventually reached.

`z @ (<< green, blue >> [ (safe && z <= 5) U goal ])`
: satisfied if `green` and `blue` can cooperate to reach a `goal` state within 5 time units and only visiting `safe` states along the way (`z` is a global clock).