ltlsynt
Table of Contents
Basic usage
This tool synthesizes reactive controllers from LTL/PSL formulas.
Consider a set \(I\) of input atomic propositions, a set \(O\) of output atomic propositions, and a PSL formula φ over the propositions in \(I \cup O\). A reactive controller realizing φ is a function \(c: (2^{I})^\star \times 2^I \mapsto 2^O\) such that, for every ω-word \((u_i)_{i \in N} \in (2^I)^\omega\) over the input propositions, the word \((u_i \cup c(u_0 \dots u_{i-1}, u_i))_{i \in N}\) satisfies φ.
If a reactive controller exists, then one with finite memory exists. Such controllers are easily represented as automata (or more specifically as Mealy machines). In the automaton representing the controller, the acceptance condition is irrelevant and trivially true.
Here is a small example where \(I=\{i_1,i_2\}\) and \(O=\{o_1\}\). The specification asks that \(o_1\) hold at some point if and only if \(i_1\) and \(i_2\) hold one after the other at some point.
ltlsynt -f 'F(i1 & Xi2) <-> F(o1)'
REALIZABLE HOA: v1 States: 2 Start: 0 AP: 3 "i1" "o1" "i2" acc-name: all Acceptance: 0 t properties: trans-labels explicit-labels state-acc deterministic controllable-AP: 1 --BODY-- State: 0 [!0&!1] 0 [0&!1] 1 State: 1 [!0&!1&!2] 0 [0&!1&!2] 1 [1&2] 1 --END--
The output is composed of two parts:
- The first part is a single line stating
REALIZABLE
orUNREALIZABLE
; the presence of this line, required by the SyntComp competition, can be disabled with option--hide-status
. - The second part, only present in the
REALIZABLE
case, is an automaton describing the controller.
The controller contains the line controllable-AP: 2
, which means
that this automaton should be interpreted as a Mealy machine where
o0
is part of the output. Using the --dot
option, makes it easier
to visualize this machine.
ltlsynt -f 'F(i1 & Xi2) <-> F(o1)' --hide-status --dot
The following example illustrates the case of an unrealizable specification. As
a
is an input proposition, there is no way to guarantee that it will
eventually hold.
ltlsynt --ins=a -f 'F a'
UNREALIZABLE
Input options
ltlsynt
require two pieces of information two solve a reactive
LTL/PSL synthesis problem: an LTL (or PSL) formula, and a partition of
its atomic propositions as input and output.
The specification formula can be passed with -f/--formula
or
-F/--file
. If multiple specifications formulas are passed, they
will all be solved individually.
The input/output partition can be given in several ways. If it is
not specified, ltlsynt
assumes that input variables should start
with i
, and output variables should start with o
.
Options --ins
and --outs
should be followed by a comma-separated
list of input atomic propositions, or input regexes enclosed in
slashes. E.g., --ins=switch,/^in/,car
. If only one of these
options is given, atomic propositions not matched by that option
are assumed to belong to the other set.
Another way to specify the input/output partition is using a *.part
file passed to the --part-file
option. Such a file is used by
several other synthesis tools. The format is space-separated list of
words representing atomic-propositions. Two keywords .inputs
and
.outputs
indicate the set of the atomic-propositions that follow.
For instance:
.inputs request cancel .outputs grant ack
Using --part-file=THEABOVEFILE
is equivalent to
--ins=request,cancel --outs=grant,ack
.
As an extension to this simple *.part
format, words enclosed in
slashes are interpreted as regexes, like for the --ins
and --outs
options.
TLSF input
ltlsynt
was made with the SYNTCOMP competition in mind, and more
specifically the TLSF track of this competition. TLSF is a high-level
specification language created for the purpose of this competition.
Fortunately, the SYNTCOMP organizers also provide a tool called
syfco
which can translate a TLSF specification to an LTL formula.
The following line shows how a TLSF specification called FILE
can
be synthesized using syfco
and ltlsynt
:
ltlsynt --tlsf FILE
The above --tlsf
option will call syfco
(which must be on your
$PATH
) to perform the conversion and extract output signals, as if
you had used:
LTL=$(syfco -f ltlxba -m fully FILE) OUT=$(syfco --print-output-signals FILE) ltlsynt --formula="$LTL" --outs="$OUT"
Output options
By default, the controller is output in HOA format, but it can be
output as an And-Inverter-Graph in AIGER format using the --aiger
flag. This is the output format required for the SYNTCOMP competition.
ltlsynt -f 'F(i1 & Xi2) <-> F(o1)' --aiger
REALIZABLE aag 5 2 1 1 2 2 4 6 11 8 8 4 6 10 3 9 i0 i1 i1 i2 o0 o1
The above format is not very human friendly. Again, by passing both
--aiger
and --dot
, one can display the And-Inverter-Graph representing
the controller:
ltlsynt -f 'F(i1 & Xi2) <-> F(o1)' --hide-status --aiger --dot
In the above diagram, round nodes represent AND gates. Small black
circles represent inversions (or negations), colored triangles are
used to represent input signals (at the bottom) and output signals (at
the top), and finally rectangles represent latches. A latch is a one
bit register that delays the signal by one step. Initially, all
latches are assumed to contain false
, and they emit their value from
the *_out
rectangles at the bottom. Their input value, to be
emitted at the next step, is received via the *_in
boxes at the top.
In ltlsynt
's encoding, the set of latches is used to keep track of
the current state of the Mealy machine.
The generation of a controller can be disabled with the flag
--realizability
. In this case, ltlsynt
's output is limited to
REALIZABLE
or UNREALIZABLE
.
Internal details
The tool reduces the synthesis problem to a parity game, and solves the parity game using Zielonka's recursive algorithm. The process can be pictured as follows.
LTL decomposition consist in splitting the specification into multiple
smaller constraints on disjoint subsets of the output values (as
described by Finkbeiner, Geier, and Passing), solve those constraints
separately, and then combine them while encoding the AIGER circuit.
This is enabled by default, but can be disabled by passing option
--decompose=no
.
The ad hoc construction on the top is just a shortcut for some type of constraints that can be solved directly by converting the constraint into a DBA.
Otherwise, conversion to parity game (represented by the blue zone) is
done using one of several algorithms specified by the --algo
option.
The game is then solved, producing a strategy if the game is realizable.
If ltlsynt
is in --realizability
mode, the process stops here
In synthesis mode, the strategy is first simplified. How this is done
can be fine-tuned with option --simplify
:
--simplify=no|bisim|bwoa|sat|bisim-sat|bwoa-sat simplification to apply to the controller (no) nothing, (bisim) bisimulation-based reduction, (bwoa) bisimulation-based reduction with output assignment, (sat) SAT-based minimization, (bisim-sat) SAT after bisim, (bwoa-sat) SAT after bwoa. Defaults to 'bwoa'. --splittype=expl|semisym|fullysym|auto Selects the algorithm to use to transform the automaton into a game graph. Defaults to 'auto'.
Finally, the strategy is encoded into AIGER. The --aiger
option can
take an argument to specify a type of encoding to use: by default it
is ite
for if-then-else, because it follows the structure of BDD
used to encode the conditions in the strategy. An alternative
encoding is isop
where condition are first put into
irredundant-sum-of-product, or both
if both encodings should be
tried. Additionally, these optiosn can accept the suffix +ud
(use
dual) to attempt to encode each condition and its negation and keep
the smallest one, +dc
(don't care) to take advantage of don't care
values in the output, and one of +sub0
, +sub1
, or +sub2
to test
various grouping of variables in the encoding. Multiple encodings can
be tried by separating them using commas. For instance
--aiger=isop,isop+dc,isop+ud
will try three different encodings.
Other useful options
Printing games
You can also ask ltlsynt
to print to obtained parity game into
PGSolver format, with the flag --print-pg
, or in the HOA format,
using --print-game-hoa
. These flags deactivate the resolution of the
parity game. Note that if any of those flag is used with --dot
, the game
will be printed in the Dot format instead:
ltlsynt -f '(i1 & i2) <-> F(o1 & X(!o1))' --print-game-hoa --dot
Saving statistics
For benchmarking purpose, the --csv
option can be used to record
intermediate statistics about the resolution. The --csv
option will
also save the formula into the CSV file, which can therefore become
very large. The variant --csv-without-formula
is usually enough.
For instance the following command tests the realizability of the 23
demonstration specifications from Lily 1.0.2 while saving some
statistics in bench.csv
. (If you compare our results with theirs,
keep in mind that Lily uses Moore's semantics, while ltlsynt
uses
Mealy's semantics.)
genltl --lily-patterns | ltlsynt --algo=acd --realizability --csv-without-formula=bench.csv
After execution, bench.csv
contains a table like the following:
A source of the form -:N
designates the Nth line of the standard
input, as ltlsynt
was reading from that. The various *_time*
columns refers to different steps in the processing pipeline. Note
that various bits and minor operations are not timed, so tot_time
(the total time) should be larger than the sum of times used for
translation, splitting, conversion to DPA, and game solving. Some of
these intermediate processing time are listed as 0
above because
(e.g., for input 8, 10, 12) because the specifications can be found to
be realizable trivially without building any game.
Verifying the output
The --verify
option requests that the produced strategy or aiger
circuit are compatible with the specification. This is done by
ensuring that they do not intersect the negation of the specification.
References
The initial reduction from LTL to parity game is described in the following paper:
- Reactive Synthesis from LTL Specification with Spot, Thibaud Michaud, Maximilien Colange. Presented in SYNT@CAV'18. (pdf | bib)
Further improvements are described in the following paper:
- Improvements to
ltlsynt
, Florian Renkin, Philipp Schlehuber, Alexandre Duret-Lutz, and Adrien Pommellet. Presented at the SYNT'21 workshop. (pdf | bib)
Simplification of Mealy machines is discussed in the following papers:
- Effective reductions of Mealy machines, Florian Renkin, Philipp Schlehuber-Caissier, Alexandre Duret-Lutz, and Adrien Pommellet. Presented at FORTE'22. (pdf | bib)
- The Mealy-machine reduction functions of Spot, Florian Renkin, Philipp Schlehuber-Caissier, Alexandre Duret-Lutz, and Adrien Pommellet. Science of Computer Programming, 230(102995), August 2023. (bib | pdf)
A more recent paper covering many aspects of ltlsynt
is the following