ltlsynt
Table of Contents
Basic usage
This tool synthesizes 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
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 controller exists, then one with finite memory exists. Such controllers are easily represented as automata (or more specifically as I/O automata or transducers). In the automaton representing the controller, the acceptance condition is irrelevant and trivially true.
ltlsynt
has three mandatory options:
--ins
: a comma-separated list of input atomic propositions;--outs
: a comma-separated list of output atomic propositions;--formula
or--file
: a specification in LTL or PSL.
One of --ins
or --outs
may be omitted, as any atomic proposition not listed
as input can be assumed to be an output and vice-versa.
The following example illustrates the synthesis of a controller acting as an
AND
gate. We have two inputs a
and b
and one output c
, and we want c
to always be the AND
of the two inputs:
ltlsynt --ins=a,b -f 'G (a & b <=> c)'
REALIZABLE HOA: v1 States: 1 Start: 0 AP: 3 "c" "a" "b" acc-name: all Acceptance: 0 t properties: trans-labels explicit-labels state-acc deterministic controllable-AP: 0 --BODY-- State: 0 [!0&!1 | !0&!2 | 0&1&2] 0 --END--
The output is composed of two parts:
- the first one is a single line
REALIZABLE
orUNREALIZABLE;
- the second one, only present in the
REALIZABLE
case is an automaton describing the controller. In this example, the controller has a single state, with two loops labeled bya & b & c
and(!a | !b) & !c
.
The label a & b & c
should be understood as: "if the input is a&b
,
the output should be c
".
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
By default, the controller is output in HOA format, but it can be
output as an AIGER circuit thanks to the --aiger
flag. This is the
output format required for the SYNTCOMP competition.
The generation of a controller can be disabled with the flag --realizability
.
In this case, ltlsynt
output is limited to REALIZABLE
or UNREALIZABLE
.
TLSF
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
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"
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 controler (no) nothing, (bisim) bisimulation-based reduction, (bwoa) bissimulation-based reduction with output assignment, (sat) SAT-based minimization, (bisim-sat) SAT after bisim, (bwoa-sat) SAT after bwoa. Defaults to 'bwoa'.
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
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 flag deactivate the resolution of the
parity game.
For benchmarking purpose, the --csv
option can be used to record
intermediate statistics about the resolution.
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.