Counterexample-Driven Synthesis for Probabilistic Program Sketches

TL;DR

This paper introduces a counterexample-guided synthesis method for probabilistic programs, enabling automatic generation of finite-state models by efficiently exploring large design spaces with minimal verification queries.

Contribution

It presents a novel approach combining CEGIS with model checking and SMT solving for probabilistic program synthesis, improving scalability and automation.

Findings

Can explore millions of candidate designs with few thousand queries

Effective in practical case studies involving complex probabilistic programs

Demonstrates scalability and efficiency of the proposed synthesis method

Abstract

Probabilistic programs are key to deal with uncertainty in e.g. controller synthesis. They are typically small but intricate. Their development is complex and error prone requiring quantitative reasoning over a myriad of alternative designs. To mitigate this complexity, we adopt counterexample-guided inductive synthesis (CEGIS) to automatically synthesise finite-state probabilistic programs. Our approach leverages efficient model checking, modern SMT solving, and counterexample generation at program level. Experiments on practically relevant case studies show that design spaces with millions of candidate designs can be fully explored using a few thousand verification queries.

Equations

$$\mathfrak{P}(0)=0.5:k_1+0.5:k_2$$

$$\mathfrak{P}(3)=1:k_4$$

$$r^{\ast }:=\arg \underset{r\in {\mathcal{R}}_{\mathfrak{D}}}{\max }\{\text{Prob}(D_r,◊G)\mid D_r\models \Phi \text{mbox}andc(r)\le B\}.$$

$$D$$

$$\text{mbox}guard\to p_1:\text{mbox}{update}_1+\dots \dots +p_n:\text{mbox}{update}_n$$

$$\text{mbox}holeh\text{mbox}either\{x_1\text{mbox}is\text{mbox}{expr}_1\text{mbox}cost{c}_1,\dots ,x_k\text{mbox}is\text{mbox}{expr}_k\text{mbox}cost{c}_k\}$$

$$\text{mbox}constraint(x_1\vee x_2)⟹x_3$$

$${\psi }_{\text{opti}}:=\underset{h\in H}{\bigwedge }1\le {\kappa }_h\le |{\mathsf{Option}}_h|,{\psi }_{\Gamma }:=\underset{\gamma \in \Gamma }{\bigwedge }\gamma [N_h^i/{\kappa }_h=i],$$

$${\psi }_{\text{cost}}:=\sum _{h\in H}{\omega }_h\le B\wedge \left(\underset{h\in H}{\bigwedge }\underset{i=1}{\overset{n}{\bigwedge }}{\kappa }_h=i\to {\omega }_h=\mathsf{cost}(o_h^i)\right),$$

$$\psi :=1\le {\kappa }_X\le 2\wedge 1\le {\kappa }_Y\le 2\wedge 1\le {\kappa }_Z\le 2\wedge \neg ({\kappa }_X=1\wedge {\kappa }_Y=1)\wedge$$

$${\omega }_X+{\omega }_Y+{\omega }_Z\le B\wedge {\kappa }_X=1\to {\omega }_X=3\wedge {\kappa }_X=2\to {\omega }_X=0\wedge {\omega }_Y=0\wedge {\omega }_Z=0.$$

$$\neg\Big{(}\bigwedge_{h\in H,\bar{R}(h)\neq\perp}\kappa_{h}=\alpha_{\bar{R}}(\kappa_{h})\Big{)}.$$

Full text

1 Introduction

With the ever tighter integration of computing systems with their environment, quantifying (and minimising) the probability of encountering an anomaly or unexpected behaviour becomes crucial. This insight has led to a growing interest in probabilistic programs and models in the software engineering community. Henzinger [43] for instance argues that “the Boolean partition of software into correct and incorrect programs falls short of the practical need to assess the behaviour of software in a more nuanced fashion $[\ldots]$.” In [61], Rosenblum advocates taking a more probabilistic approach in software engineering. Concrete examples include quantitative analysis of software product lines [40, 68, 60, 32, 67], synthesis of probabilities for adaptive software [23, 19], and probabilistic model checking at runtime to support verifying dynamic reconfigurations [20, 37].

Synthesis of probabilistic programs. The development of systems under uncertainty is intricate. Probabilistic programs are a prominent formalism to deal with uncertainty. Unfortunately, such programs are rather intricate. Their development is complex and error prone requiring quantitative reasoning over many alternative designs. One remedy is the exploitation of probabilistic model checking [6] using a Markov chain as the operational model of a program. One may then apply model checking on each design, or some suitable representation thereof [32, 27]. Techniques such as parameter synthesis [42, 26, 58] and model repair [9, 31] have been successful, but they only allow to amend or infer transition probabilities, whereas the control structure—the topology of the probabilistic model—is fixed.

Counter-Example-Guided Inductive Synthesis. This paper aims to overcome the existing limitation, by adopting the paradigm of CounterExample-Guided Inductive Synthesis (CEGIS, cf. Fig. 1) [65, 3, 64, 1] to finite-state probabilistic models and programs. Program synthesis amounts to automatically provide an instantiated probabilistic program satisfying all properties, or returns that such realisation is non-existing. This syntax-based approach starts with a sketch, a program with holes, and iteratively searches for good—or even optimal—realisations, i.e., instantiated programs. Rather than checking all realisations, the design space is pruned by potentially ruling out many realisations (dashed area) at once. From every realisation that was verified and rejected, a counterexample (CE) is derived, e.g., a program run violating the specification.

An SMT (satisfiability modulo theory)-based synthesiser uses the CE to prune programs that also violate the specification. These programs are safely removed from the design space. The synthesis and verification step are repeated until either a satisfying program is found or the entire design space is pruned implying the non-existence of such a program.

Problem statement and program-level approach. This paper tailors and generalises CEGIS to probabilistic models and programs. The input is a sketch—a probabilistic program with holes, where each hole can be replaced by finitely many options—, a set of quantitative properties that the program needs to fulfil, and a budget. All possible realisations have a certain cost and the synthesis provides a realisation that fits within the budget. Programs are represented in the PRISM modelling language [50] and properties are expressed in PCTL (Probabilistic Computational Tree Logic) extended with rewards, as standard in probabilistic model checking [50, 34]. Program sketches succinctly describe the design space of the system by providing the program-level structure but leaving some parts (e.g., command guards or variable assignments) unspecified.

Outcomes. To summarise, this paper presents a novel synthesis framework for probabilistic programs that adhere to a given set of quantitative requirements and a given budget. We use families of Markov chains to formalise our problem, and then formulate a CEGIS-style algorithm on these families. Here, CEs are subgraphs of the Markov chains. In the second part, we then generalise the approach to reason on probabilistic programs with holes. While similar in spirit, we rely on program-level CEs [33, 71], and allow for a more flexible sketching language. To the best of our knowledge, this is the first lifting of CEGIS to probabilistic programs. The CEGIS approach is sound and complete: either an admissible program does exist and it is computed, or no such program exists and the algorithm reports this. We provide a prototype implementation build on top of the model checker Storm [34] and the SMT-tool Z3 [56]. Experiments with different examples demonstrate scalability: design spaces with millions of realisations can be fully explored by a few thousand verification queries and result in a speedup of orders of magnitude.

Related work. We build on the significant body of research that employs formal methods to analyse quality attributes of alternative designs, e.g. [8, 16, 10, 38, 66, 72]. Enumerative approaches based on Petri nets [54], stochastic models [19, 62] and timed automata [44, 52], and the corresponding tools for simulation and verification (e.g. Palladio [10], PRISM [50], UPPAAL [44]) have long been used.

For non-probabilistic systems, CEGIS can find programs for a variety of challenging problems [64, 63]. Meta-sketches and the optimal and quantitative synthesis problem in a non-probabilistic setting have been proposed [25, 30, 17].

A prominent representation of sets of alternative designs are modal transition systems [53, 5, 49]. In particular, parametric modal transition systems [11] and synthesis therein [12] allow for similar dependencies that occur in program-level sketches. Probabilistic extensions are considered in, e.g. [35], but not in conjunction with synthesis. Recently [36] proposed to exploit relationships between model and specification, thereby reducing the number of model-checking instances.

In the domain of quantitative reasoning, sketches and likelihood computation are used to find probabilistic programs that best match available data [57]. The work closest to our approach synthesises probabilistic systems from specifications and parametric templates [39]. The principal difference to our approach is the use of counterexamples. The authors leverage evolutionary optimisation techniques without pruning. Therefore, the completeness is only achieved by exploring all designs, which is practically infeasible. An extension to handle parameters affecting transition probabilities (rates) has been integrated into the evolutionary-driven synthesis [21, 23] and is available in RODES [22]. Some papers have considered the analysis of sets of alternative designs within the quantitative verification of software product lines [40, 68, 60]. The typical approach is to analyse all individual designs (product configurations) or build and analyse a single (so-called all-in-one) Markov decision process describing all the designs simultaneously. Even with symbolic methods, this hardly scales to large sets of alternative designs. These techniques have recently been integrated into ProFeat [32] and QFLan [67]. An abstraction-refinement scheme has recently been explored in [27]. It iteratively analyses an abstraction of a (sub)set of designs—it is an orthogonal and slightly restricted approach to the inductive method presented here (detailed differences are discussed later). An incomplete method in [45] employs abstraction targeting a particular case study. SMT-based encodings for synthesis in Markov models have been used in, e.g. [46, 24]. These encodings are typically monolithic—they do not prune the search space via CEs. Probabilistic CEs have been recently used to ensure that controllers obtained via learning from positive examples meet given safety properties [74]. In contrast, we leverage program-level CEs that can be used to prune the design space.

2 Preliminaries and Problem Statement

We start with basics of probabilistic model checking, for details, see [7, 6], and then formalise families of Markov chains. Finally, we define some synthesis problems.

Probabilistic models and specifications. A probability distribution over a finite set $X$ is a function $\mu\colon X\rightarrow[0,1]$ with $\sum_{x\in X}\mu(X)=1$. Let $\mathit{Distr}(X)$ denote the set of all distributions on $X$.

Definition 1 (MC)

A discrete-time Markov chain (MC) $D$ is a tuple $(S,s_{0},P)$ with finite set $S$ of states, initial state $s_{0}\in S$, and transition probabilities $P\colon S\rightarrow\mathit{Distr}(S)$. We write $P(s,t)$ to denote $P(s)(t)$.

For $S^{\prime}\subseteq S$, the set ${\mathsf{Succ}(S^{\prime})\colonequals\{t\in S\mid\exists s\in S^{\prime}.~{}P(s,t)>0\}}$ denotes the successor states of $S^{\prime}$. A path of an MC $D$ is an (in)finite sequence $\pi=s_{0}s_{1}s_{2}$, where $s_{i}\in S$, and $s_{i+1}\in\mathsf{Succ}(s_{i})$ for all $i\in\mathbb{N}$.

Definition 2 (sub-MC)

Let MC $D=(S,s_{0},P)$ and critical states $C\subseteq S$ with $s_{0}\in C$. The sub-MC of $D,C$ is the MC ${D}\!\downarrow\!{C}=(C\cup\mathsf{Succ}(C),s_{0},P^{\prime})$ with $P^{\prime}(s,t)=P(s,t)$ for $s\in C$, $P^{\prime}(s,s)=1$ for $s\in\mathsf{Succ}(C){\setminus}C$, and $P^{\prime}(s,t)=0$

Specifications. For simplicity, we focus on reachability properties ${\varphi=\mathbb{P}_{\sim\lambda}(\lozenge G)}$ for a set $G\subseteq S$ of goal states, threshold $\lambda\in[0,1]\subseteq{\mathbb{R}}$, and comparison relation ${{}\sim{}}\in\{<,\leq,\geq,>\}$. The interpretation of $\varphi$ on MC $D$ is as follows. Let $\texttt{Prob}(D,\lozenge G)$ denote the probability to reach $G$ from $D$’s initial state. Then, $D\models\varphi$ if $\texttt{Prob}(D,\lozenge G)\sim\lambda$. A specification is a set $\Phi=\{\varphi_{i}\}_{i\in I}$ of properties, and $D\models\Phi$ if $\forall i\in I.~{}D\models\varphi_{i}$. Upper-bounded properties (with ${{}\sim{}}\in\{<,\leq\}$) are safety properties, lower-bounded properties are liveness properties. Extensions to expected rewards or $\omega$-regular properties are rather straightforward.

Families of Markov chains. We recap an explicit representation of a family of MCs using a parametric transition function, as in [27].

Definition 3 (Family of MCs)

A family of MCs is a tuple $\mathfrak{D}=(S,s_{0},K,\mathfrak{P})$ with $S$, $s_{0}$ as before, a finite set of parameters $K$ where the domain for each parameter $k\in K$ is $T_{k}\subseteq S$, and transition probability function $\mathfrak{P}\colon S\rightarrow\mathit{Distr}(K)$.

The transition probability function of MCs maps states to distributions over successor states. For families, this function maps states to distributions over parameters. Instantiating each parameter with a value from its domain yields a “concrete” MC, called a realisation.

Definition 4 (Realisation)

A realisation of a family $\mathfrak{D}=(S,s_{0},K,\mathfrak{P})$ is a function $r\colon K\rightarrow S$ where $\forall k\in K\colon r(k)\in T_{k}$. A realisation $r$ yields an MC $D_{r}\colonequals(S,s_{0},\mathfrak{P}(r))$, where $\mathfrak{P}(r)$ is the transition probability matrix in which each $k\in K$ in $\mathfrak{P}$ is replaced by $r(k)$. Let $\mathcal{R}^{\mathfrak{D}}$ denote the set of all realisations for $\mathfrak{D}$.

As a family $\mathfrak{D}$ has finite parameter domains, the number of family members (i.e. realisations from $\mathcal{R}^{\mathfrak{D}}$) of $\mathfrak{D}$ is finite, but exponential in $|K|$. While all MCs share their state space, their reachable states may differ.

Example 1

Consider the family of MCs $\mathfrak{D}=(S,s_{0},K,\mathfrak{P})$ where $S=\{0,\ldots,4\}$, $s_{0}=0$, and $K=\{k_{0},\ldots,k_{5}\}$ with $T_{k_{0}}=\{0\}$, $T_{k_{1}}=\{1\}$, $T_{k_{2}}=\{2,3\}$, $T_{k_{3}}=\{2,4\}$, $T_{k_{4}}=\{3\}$ and $T_{k_{5}}=\{4\}$, and $\mathfrak{P}$ given by:

[TABLE]

Fig. 2 shows the four MCs of $\mathfrak{D}$. Unreachable states are greyed out.

The function $c\colon\mathcal{R}^{\mathfrak{D}}\to\mathbb{N}$ assigns realisation costs. Attaching costs to realisations is a natural way to distinguish preferable realisations. We stress the difference with rewards in MCs; the latter impose a cost structure on paths in MCs.

Problem statement

Synthesis problems. Let $\mathfrak{D}$ be a family, and $\Phi$ be a set of properties, and $B\in\mathbb{N}$ a budget. Consider the synthesis problems:

Feasibility synthesis: Find a realisation $r\in\mathcal{R}^{\mathfrak{D}}$ with $D_{r}\models\Phi$ and $c(r)\leq B$. 2. 2.

Max synthesis: For given $G\subseteq S$, find $r^{*}\in\mathcal{R}^{\mathfrak{D}}$ with

[TABLE]

The problem in feasibility synthesis is to determine a realisation satisfying all $\varphi\in\Phi$, or return that no such realisation exists. This problem is NP-complete [27]. The problem in max synthesis is to find a realisation that maximises the reachability probability of reaching $G$. It can analogously be defined for minimising such probabilities. As families are finite, such optimal realisations $r^{*}$ always exist. It is beneficial to consider a variant of the max-synthesis problem in which the realisation $r^{*}$ is not required to achieve the maximal reachability probability, but it suffices to be close to it. This notion of $\varepsilon$-maximal synthesis for a given $0<\varepsilon\leq 1$ amounts to find a realisation $r^{*}$ with $\texttt{Prob}(D_{r^{*}},\lozenge G)\geq(1{-}\varepsilon)\cdot\max\limits_{r\in\mathcal{R}^{\mathfrak{D}}}\{\texttt{Prob}(D_{r},\phi)\}$.

Problem statement and structure. In this paper, we propose novel synthesis algorithms for the probabilistic systems that are based on two concepts, CEGIS [64] and syntax-guided synthesis [3]. To simplify the presentation, we start with CEGIS in Sect. 3 and adopt it for MCs and the feasibility problem. In Sect. 4, we lift and tune CEGIS, in particular towards probabilistic program sketches.

3 CEGIS for Markov Chain Families

We follow the typical separation of concerns as in oracle-guided inductive synthesis [4, 39, 41]: a synthesiser selects single realisations $r$ that have not been considered before, and a verifier checks whether the MC $D_{r}$ satisfies the specification $\Phi$ (cf. Fig. 1 on page 1). If a realisation violates the specification, the verifier returns a conflict representing the core part of the MC causing the violation.

3.1 Conflicts and synthesiser

To formalise conflicts, a partial realisation of a family $\mathfrak{D}$ is a function $\bar{r}\colon K\rightarrow S\cup\{\bot\}$ such that $\forall k\in K.~{}\bar{r}(k)\in T_{k}\cup{\{\perp\}}$. For any partial realisations $\bar{r}_{1}$, $\bar{r}_{2}$, let $\bar{r}_{1}\subseteq\bar{r}_{2}$ iff $\bar{r}_{1}(k)\in\{\bar{r}_{2}(k),\bot\}$ for all $k\in K$.

Definition 5 (Conflict)

Let $r\in\mathcal{R}^{\mathfrak{D}}$ be a realisation with $D_{r}\not\models\varphi$ for $\varphi\in\Phi$. A partial realisation $\bar{r}_{\varphi}\subseteq r$ is a conflict for the property $\varphi$ iff $D_{r^{\prime}}\not\models\varphi$ for each realisation $r^{\prime}\supseteq\bar{r}_{\varphi}$. A set of conflicts is called a conflict set.

To explore all realisations, the synthesiser starts with $Q\colonequals\mathcal{R}^{\mathfrak{D}}$ and picks some realisation $r\in Q$.111We focus on program-level synthesis, and refrain from discussing important implementation aspects—like how to represent $Q$—here. Either $D_{r}\models\Phi$ and we immediately return $r$, or a conflict is found: then $Q$ is pruned by removing all conflicts that the verifier found. If $Q$ is empty, we are done: each realisation violates a property $\varphi\in\Phi$.

3.2 Verifier

Definition 6

A verifier is sound and complete, if for family $\mathfrak{D}$, realisation $r$, and specification $\Phi$, the verifier terminates, the returned conflict set is empty iff $D_{r}\models\Phi$, and if it is not empty, it contains a conflict $\bar{r}_{\varphi}\subseteq r$ for some $\varphi\in\Phi$.

Algorithm 1 outlines a basic verifier. It uses an off-the-shelf probabilistic model-checking procedure Check($D_{r}$, $\varphi$) to determine which $\varphi\in\Phi$ (if any) are violated. The algorithm then iterates over the violated $\varphi$ and computes critical sets $C$ of $D_{r}$ that induce sub-MCs such that ${D_{r}}\!\downarrow\!{C}\not\models\varphi$ (line 6). The critical sets for safety properties can be obtained via standard methods [2], support for liveness properties is discussed at the end of the section.

Example 2

Reconsider $\mathfrak{D}$ from Ex. 1 with $\Phi\colonequals\{\varphi\colonequals\mathbb{P}_{\leq\nicefrac{{2}}{{5}}}(\lozenge\{2\})\}$. Assume the synthesiser picks realisation $r_{1}$. The verifier builds $D_{r_{1}}$ and determines $D_{r_{1}}\not\models\Phi$. Observe that the verifier does not need the full realisation $D_{r_{1}}$ to refute $\Phi$. In fact, the paths in the fragment of $D_{r_{1}}$ in Fig. 3a (ignoring the outgoing transitions of states $1$ and $2$) suffice to show that the probability to reach state $2$ exceeds $\nicefrac{{2}}{{5}}$. Formally, the fragment in Fig. 3b is a sub-MC ${D_{r_{1}}}\!\downarrow\!{C}$ with critical states $C=\{0\}$.

The essential property is [70]:

[TABLE]

Observe that ${D_{r_{1}}}\!\downarrow\!{C}$ is part of $D_{r_{2}}$ too. Formally, the sub-MC of ${D_{r_{2}}}\!\downarrow\!{C}$ is isomorphic to ${D_{r_{1}}}\!\downarrow\!{C}$ and therefore also violates $\Phi$. Thus, $D_{r_{2}}\not\models\Phi$.

Finally, the verifier translates the obtained critical set $C$ for realisation $r$ to a conflict $\textsl{Conflict}(C,r)\subseteq r$ and stores it in the conflict set $\mathsf{Conflict}$ (line 7). The procedure generateConflict$(\mathfrak{D},r,C)$ identifies the subset of parameters $K$ that occur in the sub-MCs ${D_{r}}\!\downarrow\!{C}$ and returns the corresponding partial realisation. The proposition below clarifies the relation between critical sets and conflicts.

Proposition 1

If $C$ is a critical set for $D_{r}$ and $\varphi$, then $C$ is also a critical set for each $D_{r^{\prime}}$, $r^{\prime}\supseteq\textsl{Conflict}(C,r)$, and $D_{r^{\prime}}\not\models\varphi$.

Example 3

Recall from Ex. 2 that $D_{r_{2}}\not\models\Phi$. This can be concluded without constructing $D_{r_{2}}$. Just considering $r_{2}$, $\mathfrak{D}$ and $C$ suffices: First, take all parameters occurring in $\mathfrak{P}(c)$ for any $c\in C$. This yields $\{k_{1},k_{2}\}$. The partial realisation $\bar{r}\colonequals\{k_{1}\mapsto 1,k_{2}\mapsto 2\}$ is a conflict. The values for the other parameters do not affect the shape of the sub-MC induced by $C$. Realisation $r_{2}\supset\bar{r}$ only varies from $r_{1}$ in the value of $k_{3}$, but $\bar{r}(k_{3})=\bot$, i.e., $k_{3}$ is not included in the conflict. This suffices to conclude $D_{r_{2}}\not\models\Phi$.

Conflicts for liveness properties. To support liveness properties such as $\varphi\colonequals\mathbb{P}_{>\lambda}(\lozenge G)$, we first consider a (standard) dual safety property $\varphi^{\prime}\colonequals\mathbb{P}_{<1-\lambda}(\lozenge B)$, where $B$ is the set of all states that do not have a path to $G$. Observe that $B$ can be efficiently computed using graph algorithms. We have to be careful, however.

Example 4

Consider $D_{r_{1}}$, and let $\varphi\colonequals\mathbb{P}_{>0.6}(\lozenge\{4\})$. $D_{r_{1}}\not\models\varphi$. Then, $\varphi^{\prime}=\mathbb{P}_{<0.4}(\lozenge\{2\})$, which is refuted with critical set $C=\{0\}$ as before. Although ${D_{r_{2}}}\!\downarrow\!{C}$ is again isomorphic to ${D_{r_{1}}}\!\downarrow\!{C}$, we have $D_{r_{2}}\models\varphi$. The problem here is that state $2$ is in $B$ for $D_{r_{1}}$ as $r_{1}(k_{3})=2$, but not in $B$ for $D_{r_{2}}$, as $r_{2}(k_{3})=4$.

To prevent the problem above, we ensure that the states in $B$ cannot reach $G$ in other realisations, by including $B$ in the critical set of $\varphi$: Let $C$ be the critical set for the dual safety property $\varphi^{\prime}$. We define $B\cup C$ as critical states for $\varphi$. Together, we reach states $B$ with a critical probability mass222A good implementation takes a subset of $B^{\prime}\subseteq B$ by considering the $\texttt{Prob}(D,\lozenge B^{\prime})$., and never leave $B$.

Example 5

In $D_{r_{1}}$, we compute critical states $\{0,2\}$, preventing the erroneous reasoning from the previous example. For $D_{r_{4}}$, we compute $C^{\prime}=\{0\}\cup\{3\}$ as critical states, and as ${D_{r_{4}}}\!\downarrow\!{C^{\prime}}$ is isomorphic to ${D_{r_{3}}}\!\downarrow\!{C^{\prime}}$, we obtain that $D_{r_{3}}\not\models\varphi$.

4 Syntax-Guided Synthesis for Probabilistic Programs

Probabilistic models are typically specified by means of a program-level modelling language, such as PRISM [50], PIOA [73], JANI [18], or MODEST [15]. We propose a sketching language based on the PRISM modelling language. A sketch, a syntactic template, defines a high-level structure of the model and represents a-priori knowledge about the system under development. It effectively restricts the size of the design space and also allows to concisely add constraints and costs to its members. The proposed language is easily supported by model checkers and in particular by methods for generating CEs [33, 71]. Below, we describe the language, and adapt CEGIS from state level to program level. In particular, we employ so-called program-level CEs, rather than CEs on the state level.

4.1 A program sketching language

Let us briefly recap how the model-based concepts translate to language concepts in the PRISM guarded-command language. A PRISM program consists of one or more reactive modules that may interact with each other. Consider a single module. This is not a restriction, every PRISM program can be flattened into this form. A module has a set of bounded variables spanning its state space. Transitions between states are described by guarded commands of the form:

[TABLE]

The guard is a Boolean expression over the module’s variables of the model. If the guard evaluates to true, the module can evolve into a successor state by updating its variables. An update is chosen according to the probability distribution given by expressions $p_{1},\ldots,p_{n}$. In every state enabling the guard, the evaluation of $p_{1},\ldots,p_{n}$ must sum up to one. Overlapping guards yield non-determinism and are disallowed here. Roughly, a program $\mathcal{P}$ thus is a tuple $(\mathrm{Var},E)$ of variables and commands. For a program $\mathcal{P}$, the underlying MC $[\![\,\mathcal{P}\,]\!]$ are $\mathcal{P}$’s semantics. We lift specifications: Program $\mathcal{P}$ satisfies a specification $\Phi$, iff $[\![\,\mathcal{P}\,]\!]\models\Phi$, etc.

A sketch is a program that contains holes. Holes are the program’s open parts and can be replaced by one of finitely many options. Each option can optionally be named and associated with a cost. They are declared as:

[TABLE]

where $h$ is the hole identifier, $x_{i}$ is the option name, $\mbox{{expr}}_{i}$ is an expression over the program variables describing the option, and $c_{i}$ are the cost, given as expressions over natural numbers. A hole $h$ can be used in commands in a similar way as a constant, and may occur multiple times within multiple commands, in both guards and updates. The option names can be used to describe constraints on realisations. These propositional formulae over option names restrict realisations, e.g.,

[TABLE]

requires that whenever the options $x_{1}$ or $x_{2}$ are taken for some (potentially different) holes, option $x_{3}$ is also to be taken.

Definition 7 (Program sketch)

A (PRISM program) sketch is a pair $\mathfrak{S}_{H}\colonequals(\mathcal{P}_{H},\mathsf{Option}_{H},\Gamma,\mathsf{cost})$ where $\mathcal{P}_{H}$ is a program with a set $H$ of holes with options $\mathsf{Option}_{H}$, $\Gamma$ are constraints over $\mathsf{Option}_{H}$, and $\mathsf{cost}\colon\mathsf{Option}_{H}\rightarrow\mathbb{N}$ option-costs.

Example 6

We consider a small running example to illustrate the main concepts. Fig. 4a depicts the program sketch $\mathfrak{S}_{H}$ with holes $H=\{\text{X},\text{Y},\text{Z}\}$. For X, the options are $\mathsf{Option}_{\text{X}}=\{1,2\}$. The constraint forbids XA and XB both being one; it ensures a non-trivial random choice in state s=0.

Remark 1

Below, we formalise notions previously used on families. Due to flexibility of sketching (in particular in combination with multiple modules), it is not straightforward to provide family semantics to sketches, but the concepts are analogous. In particular: holes and parameters are similar, parameter domains are options, and family realisations and sketch realisations both yield concrete instances from a family/sketch. The synthesis problems carry over naturally.

Definition 8 (Realisations of sketches)

Let $\mathfrak{S}_{H}\colonequals(\mathcal{P}_{H},\mathsf{Option}_{H},\Gamma,\mathsf{cost})$ be a sketch, a sketch realisation on holes $H$ is a function $R\colon H\rightarrow\mathsf{Option}_{H}$ with $\forall h\in H.~{}R(h)\in\mathsf{Option}_{h}$ and that satisfies all constraints in $\Gamma$. The sketch instance $\mathfrak{S}_{H}(R)$ for realisation $R$ is the program (without holes) $\mathcal{P}_{H}[H/R]$ in which each hole $h\in H$ in $\mathcal{P}_{H}$ is replaced by $R(h)$. The cost $c(R)$ is the sum of the cost of the selected options, $c(R)\colonequals\sum_{h\in H}\mathsf{cost}(R(h))$.

Example 7

We continue Ex. 6. The program in Fig. 4b reflects $\mathfrak{S}_{H}(R)$ for realisation $R=\{X{\mapsto}1,Z{\mapsto}2,Y{\mapsto}3\}$, with $c(R)=3$ as $\mathsf{cost}(R(X))=3$ and all other options have cost zero. For realisation $R^{\prime}=\{Y,Z\mapsto 1,X\mapsto 2\}$, $c(R^{\prime})=0$. The assignment $\{X,Y,Z\mapsto 1\}$ violates the constraint and is not a realisation. In total, $\mathfrak{S}_{H}$ represents $6=2^{3}{-}2$ programs and their underlying MCs.

4.2 A program-level synthesiser

Feasibility synthesis.

The synthesiser follows the steps in Alg. 2. During the synthesis process, the synthesiser stores and queries the set of realisations not yet pruned. These remaining realisations are represented by (the satisfying assignments of) the first-order formula $\psi$ over hole-assignments. Iteratively extending $\psi$ with conjunctions thus prunes the remaining design space.

We give a brief overview, before detailing the steps. Initialise$(\mathfrak{S}_{H},B)$ constructs $\psi$ such that it represents all sketch realisations that satisfy the constraints in the sketch $\mathfrak{S}_{H}$ within the budget $B$. GetRealisation($\psi$) exploits an SMT-solver for linear (bounded) integer arithmetic to obtain a realisation $R$ consistent with $\psi$, or Unsat if no such realisation exists. As long as new realisations are found, the verifier analyses them (line 5) and returns a conflict set $C$. If $C=\varnothing$, the $\mathfrak{S}_{H}(R)$ satisfies the specification $\Phi$ and the search is terminated. Otherwise, the synthesiser updates $\psi$ based on the conflicts (line 7). $R$ is always pruned.

Initialise$(\mathfrak{S}_{H},B)$: Let hole $h\in H$ have (ordered) options $\mathsf{Option}_{h}=\{o_{h}^{1},\ldots,o_{h}^{n}\}$. To encode realisation $R$, we introduce integer-valued meta-variables $K_{H}\colonequals\{\kappa_{h}\mid h\in H\}$ with the semantics that $\kappa_{h}=i$ whenever hole $h$ has value $o_{h}^{i}$, i.e., $R(h)=o_{h}^{i}$. We set $\psi\colonequals\psi_{\text{opti}}\land\psi_{\Gamma}\land\psi_{\text{cost}}$, where $\psi_{\text{opti}}$ ensures that each hole is assigned to some option, $\psi_{\Gamma}$ ensures that the sketch’s constraints $\Gamma$ are satisfied, and $\psi_{\text{cost}}$ ensures that the budget is respected. These sub-formulae are:

[TABLE]

where $\gamma[N_{h}^{i}/\kappa_{h}=i]$ denotes that in every constraint $\gamma\in\Gamma$ we replace each option name $N_{h}^{i}$ for an option $o_{h}^{i}$ with $\kappa_{h}=i$, and $\omega_{h}$ are fresh variables storing the cost for the selected option at hole $h$.

Example 8

For sketch $\mathfrak{S}_{H}$ in Fig. 4a, we obtain (with slight simplifications)

[TABLE]

GetRealisation$(\psi)$: To obtain a realisation $R$, we check satisfiability of $\psi$. The solver either returns Unsat indicating that the synthesiser is finished, or Sat, together with a satisfying assignment $\alpha_{R}\colon K_{H}\rightarrow\mathbb{N}$. The assignment $\alpha_{R}$ uniquely identifies a realisation $R$ by $R(h)\colonequals o_{h}^{\alpha_{R}(\kappa_{h})}$. The sum over $\omega_{*}$ gives $c(R)$.

Verify$(\mathfrak{S}_{H}(r),\Phi)$: invokes any sound and complete verifier, e.g., an adaption of the verifier from Sect. 3.2 as presented in Sect. 4.3.

LearnFromConflict$(\mathfrak{S}_{H},\bar{R})$: For a conflict333As in Sect. 3.1: A partial realisation for $\mathfrak{S}_{H}$ is a function ${\bar{R}\colon H\rightarrow\mathsf{Option}_{H}\cup\{\bot\}}$ s.t. $\forall h\in H.~{}\bar{R}(h)\in\mathsf{Option}_{h}\cup{\{\perp\}}$. For partial realisations $\bar{R}_{1},\bar{R}_{2}$, let $\bar{R}_{1}\subseteq\bar{R}_{2}$ iff $\forall h\in H.\;\bar{R}_{1}(h)\in\{\bar{R}_{2}(h),\perp\}$. Let $R$ be a realisation s.t. $\mathfrak{S}_{H}(R)\not\models\varphi$ for $\varphi\in\Phi$. Partial realisation $\bar{R}_{\varphi}\subseteq R$ is a conflict for $\varphi$ iff $\forall R^{\prime}\supseteq\bar{R}_{\varphi}~{}\mathfrak{S}_{H}(R^{\prime})\not\models\varphi$. $\bar{R}\in C$, we add the formula

[TABLE]

that excludes realisations $R^{\prime}\supseteq\bar{R}$. Intuitively, the formula states that the realisations remaining in the design space (encoded by the updated $\psi$) must have different valuations of holes $h$ w.r.t. $\bar{R}$ (for holes where $\bar{R}(h)\neq\bot$).

Example 9

Consider $\psi$ from Ex. 8. The satisfying assignment (for $B\geq 2$) is $\{\kappa_{X}\mapsto 1,\kappa_{Y},\kappa_{Z}\mapsto 2,\omega_{X}\mapsto 3,\omega_{Y},\omega_{Z}\mapsto 0\}$ represents $R$, $c(R)=3$ from Ex. 6. Consider $\Phi=\{\mathbb{P}_{\leq 0.4}[\lozenge~{}\texttt{s=3}]\}$. The verifier (for now, magically) constructs a conflict set $\{\bar{R}\}$ with $\bar{R}=\{\text{Y}\mapsto 3\}$. The synthesiser updates $\psi\leftarrow\psi\land\kappa_{Y}\neq 2$ (recall that $\kappa_{Y}=2$ encodes $Y\mapsto 3$). A satisfying assignment $\{\kappa_{X},\kappa_{Y},\kappa_{Z}\mapsto 1\}$ for $\psi$ encodes $R^{\prime}$ from Ex. 7. As $\mathfrak{S}_{H}(R^{\prime})\models\Phi$, the verifier reports no conflict.

Optimal synthesis. We adapt the synthesiser to support max synthesis, cf. Alg. 3.

Recall the problem aims at maximizing the probability of reaching states described by a predicate $G$, w.r.t. the tolerance $\varepsilon\in(0,1)$. Algorithm 3 stores in $\lambda^{*}$ the maximal probability $\mathsf{Prob}(\mathfrak{S}_{H}(R),\lozenge G)$ among all considered realisations $R$, and this $R$ in $R^{*}$. In each iteration, an optimising verifier is invoked (line 5) on realisation $R$. If $\mathfrak{S}_{H}(R)\models\Phi$ and $\mathsf{Prob}(\mathfrak{S}_{H}(R),\lozenge G)\;{>}\;\lambda^{*}$, it returns an empty conflict set and $\lambda_{\text{new}}\colonequals\mathsf{Prob}(\mathfrak{S}_{H}(R),\lozenge G)$. Otherwise, it reports a conflict set for $\Phi\cup\{\mathbb{P}_{\geq(1-\varepsilon)\cdot\lambda^{*}}(\lozenge G)\}$.

4.3 A program-level verifier

We now adapt the statel-level verifier from Sect. 3.2 in Alg. 1 to use program-level counterexamples [71] for generating conflicts. The appendix contains more details.

generateMC$(\mathfrak{S}_{H},R)$: This procedure first constructs the instance $\mathfrak{S}_{H}(R)$, i.e., a program without holes, from $\mathfrak{S}_{H}$ and $R$, as in Fig. 4b: Constraints in the sketch are removed, as they are handled by the synthesiser. This approach allows us to use any model checker supporting PRISM programs. The realisation is passed separately, the sketch is parsed once and then appropriately instantiated. The instance is then translated into the underlying MC $[\![\,\mathfrak{S}_{H}(R)\,]\!]$ via standard procedures, with transitions annotated with their generating commands.

ComputeCriticalSet$(D,\varphi)$ computes program-level CEs as analogue of critical sets. They are defined on commands rather than on states. Let $\mathcal{P}=(\mathrm{Var},E)$ be a program with commands $E$. Let ${\mathcal{P}}_{|{E^{\prime}}}\colonequals(\mathrm{Var},E^{\prime})$ denote the restriction of $\mathcal{P}$ to $E^{\prime}$ (with variables and initial sates as in $\mathcal{P}$). Building ${\mathcal{P}}_{|{E^{\prime}}}$ may introduce deadlocks in $[\![\,{\mathcal{P}}_{|{E^{\prime}}}\,]\!]$ (just like a critical set introduces deadlocks). To remedy this, we use the standard operation $\mathsf{fixdl}$, which takes a program and adds commands that introduce self-loops for states without enabled guard.

Definition 9

For program $\mathcal{P}=(\mathrm{Var},E)$ and specification $\Phi$ with $\mathcal{P}\not\models\Phi$, a program-level CE $E^{\prime}\subseteq E$ is a set of commands, such that for all (non-overlapping) programs $\mathcal{P^{\prime}}=(\mathrm{Var},E^{\prime\prime})$ with $E^{\prime\prime}\supseteq E^{\prime}$ (i.e, extending $\mathcal{P}$), $\mathsf{fixdl}(\mathcal{P^{\prime}})\not\models\Phi$.

Example 10

Reconsider $\Phi=\{\mathbb{P}_{\leq 0.4}[\lozenge~{}\texttt{s=3}]\}$. Figure 5a shows a CE for $\mathfrak{S}_{H}(R)$ in Fig. 4b. The probability to reach s=3 in the underlying MC is $0.5>0.4$.

For safety properties, program-level CEs coincide with high-level CEs proposed in [71], their extension to liveness properties follows the ideas on families. The program-level CEs are computed by an extension of the MaxSat [14] approach from [33]. The appendix contains details and further extensions.

GenerateConflict$(\mathfrak{S}_{H},R,E)$ generates conflicts from commands: we map commands in $\mathfrak{S}_{H}(R)_{|E}$ to the commands from $\mathfrak{S}_{H}$, i.e., we restore the information about the critical holes corresponding to the part of the design space that can be pruned by CE $E$. Formally, $\textsl{Conflict}(E,R)(h)=R(h)$ for all $h\in H$ that appear in restriction $\mathfrak{S}_{H}{}_{|E}$.

Proposition 2

If $E$ is a CE for $\mathfrak{S}_{H}(R)$, then $E$ is also a CE for each $\mathfrak{S}_{H}(R^{\prime})$, $R^{\prime}\supseteq\textsl{Conflict}(E,R)$.

Example 11

The CEs in Fig. 5a contain commands which depend on the realisations for holes X and Y. For these fixed values, the program violates the specification independent of the value for Z, so Z is not in the conflict $\{\text{X}\mapsto 1,\text{Y}\mapsto 3\}$.

5 Experimental Evaluation and Discussion

Implementation. We evaluate the synthesis framework with a prototype444https://github.com/moves-rwth/sketching using the SMT-solver Z3 [56], and (an extension of) the model checker Storm [34].

Case studies. We consider the following three case studies:

Dynamic power management (DPM). The goal of this adapted DPM problem [13] is to trade-off power consumption for performance. We sketch a controller that decides based on the current workload, inspired by [39]. The fixed environment contains no holes. The goal is to synthesise the guards and updates to satisfy a specification with properties such as $\varphi_{1}$: the expected number of lost requests is below $\lambda$, and $\varphi_{2}$: the expected energy consumption is below $\kappa$.

Intrusion describes a network (adapted from [51]), in which the controller tries to infect a target node via intermediate nodes. A failed attack makes a node temporarily harder to intrude. We sketched a partial strategy aiming to minimise the expected time to intrusion. Constraints encode domain specific knowledge.

Grid is based on a classical benchmark for solving partially observable MDPs (POMDPs) [48]. To solve POMDPs, the task is to find an observation-based strategy, which is undecidable for the properties we consider. Therefore, we resort to finding a deterministic $k$-state strategy [55] s.t. in expectation, the strategy requires less than $\lambda$ steps to the target. This task is still hard: finding a memoryless, observation-based strategy is already NP-hard [69, 29]. We create a family describing all $k$-state strategies (for some fixed $k$) for the POMDP. Like in [47] actions are reflected by parameters, while parameter dependencies ensure that the strategy is observation-based.

Evaluation. We compare w.r.t. an enumerative approach. That baseline linearly depends on the number of realisations, and the underlying MCs’ size. We focus on sketches where all realisations are explored, as relevant for optimal synthesis. For concise presentation we use Unsat variants of feasibility synthesis, where methods perform mostly independent of the order of exploring realisations. We evaluate results for DPM, and summarise further results. All results are obtained on a Macbook MF839LL/A, within 3 hours and using less than 8 GB RAM.

DPM has 9 holes with 260K realisations, and MCs have 5K (reachable) states on average, ranging from 2K to 8K states. *The performance of CEGIS significantly depends on the specification, namely, on the thresholds appearing in the properties. * Fig. 6a shows how the number of iterations (left axis, green circle) and the runtime in seconds (right axis, blue) changes for varying $\lambda$ for property $\varphi_{1}$ (stars and crosses are explained later). We obtain a speedup of $100{\times}$ over the baseline for $\lambda=0.7{\cdot}\lambda^{*}$, dropping to $23{\times}$ for $\lambda=0.95{\cdot}\lambda^{*}$, where $\lambda^{*}$ is the minimal probabilty over all realisations. The strong dependency between performance and “unsatisfiability” is not surprising. The more unsatisfiable, the smaller the conflicts (as in [33]). Small conflicts have a double beneficial effect. First, the prototype uses an optimistic verifier searching for minimal conflicts; small conflicts are found faster than large ones. Second, small conflicts prune more realisations. A slightly higher number of small conflicts yields a severe decrease in iterations. Thus the further the threshold from the optimum, the better the performance.

Reconsider Fig. 6a, crosses and stars correspond to a variant in which we have blown up the state space of the underlying MCs by a factor B-UP. Observe that performance degrades similarly for the baseline and our algorithm, which means that the speedup w.r.t. the baseline is not considerably affected by the size of the underlying MCs. This observation holds for various models and specifications.

Varying the sketch tremendously affects performance, cf. Fig. 6b for the performance of variants of the original sketch with some hole substituted. The framework performs significantly better on sketches with holes that lie in local regions of the MC. Holes relating to states all-over the MC are harder to prune. Finally, our prototype generally performs better with specifications that have multiple (conflicting) properties: Some realisations can be effectively pruned by conflicts w.r.t. property $\varphi_{1}$, whereas other realisations are easily pruned by conflicts w.r.t., e.g., property $\varphi_{2}$.

Intrusion has 26 holes and 6800K realisations, the underlying MCs have only 500 states on average. We observe an even more significant effect of the property thresholds on the performance, as the number of holes is larger (recall the optimistic verifier). We obtain a speedup of factor $2200$, $250$ and $5$ over the baseline, for thresholds $0.7{\cdot}\lambda^{*}$, $0.8{\cdot}\lambda^{*}$ and $0.9{\cdot}\lambda^{*}$, respectively. For $0.7{\cdot}\lambda^{*}$, many conflicts contain only 8 holes. Blowing up the model does not affect the obtained speedups. Differences among variants are again significant, albeit less extreme.

Grid is structurally different: only 6 holes in 3 commands and 1800 realisations, but MCs having 100K states on average. Observe that reaching the targets on expectation below some threshold implies that the goal must almost surely be reached. The MCs’ topology and the few commands make pruning hard: our algorithm needs more than $400$ iterations. Still, we obtain a $3{\times}$ speedup for $\lambda=0.98{\cdot}\lambda^{*}$. Pruning mostly follows from reasoning about realisations that do not reach the target almost surely. Therefore, the speedup is mostly independent of the relation between $\lambda$ and $\lambda^{*}$.

Discussion. Optimistic verifiers search for a minimal CE and thus solve an NP-hard problem [28, 71]. In particular, we observed a lot of overhead when the smallest conflict is large, and any small CE that can be cheaply computed might be better for the performance (much like the computation of unsatisfiable cores in SMT solvers). Likewise, reusing information about holes from previous runs might benefit the performance. Improvements in concise sketching, and exploiting the additional structure, will also improve performance.

Sketching. Families are simpler objects than sketches, but their explicit usage of states make them inadequate for modelling. Families can be lifted to a (restricted) sketching class, as in [27]. However, additional features like conflicts significantly ease the modelling process. Consider intrusion: Without constraints, the number of realisations grows to $6{\cdot}10^{11}$ realisations. Put differently, the constraint allows to discard over $99.99\%$ of the realisations up front. Moreover, constraints can exclude realisations that would yield unsupported programs, e.g, programs with infinite state spaces. While modelling concise sketches with small underlying MCs, it may be hard to avoid such invalid realisations without the use of constraints.

Comparison with CEGAR. We also compared with our CEGAR-prototype [27], which applies an abstraction-refinement loop towards, e.g., feasibility synthesis. In particular, the abstraction aggregates multiple realisations in a single model to effectively reason about a set of designs. This approach does not support multiple objective specification (as of now), and, more importantly, the algorithm is conceptually not capable of handling constraints. For DPM with a single objective, CEGAR-prototype is drastically faster, while on Grid, it is typically (often significantly) slower. Comparing two prototypes is intricate, but there is a CEGIS strength and weakness that explains the different characteristics.

Weakness: Upon invocation, the CEGIS verifier gets exactly one realisation, and is (as of now) unaware of other options for the holes. The verifier constructs a CE which is valid for all possible extensions (cf. Definition 9), even for extensions which do not correspond to any realisation. It would be better if we compute CEs that are (only) valid for all possible realisations. The following example (exaggerating DPM) illustrates that considering multiple realisations at once may be helpful: Consider a family with a parametric transition (hole) from the initial state and specification that requires reaching the failure state with probability smaller than 0.1. Assume that all 100 options lead to a failure states with probability 1. CEGIS never prunes this hole as it is relevant for every realisation. Knowing that all options lead to the failure state, however makes the hole trivially not relevant. Thus, all corresponding options can be safely pruned.

Strength: The weakness is related to its strength: the verifier works with one concrete MC. An extreme example (exaggerating Grid) is a sketch with holes $h_{0},\ldots,h_{m}$, where hole $h_{0}$ has options $1,\ldots,m$, and option $i$ makes holes $h_{j}$ $j\neq i$ irrelevant (by the model topology). CEGIS considers a realisation, say $\{h_{0}\mapsto i,\ldots,h_{i}\mapsto x,\ldots\}$, that violates the specification. As holes $h_{j}$ with $j\neq i$ are not relevant, CEGIS finds a conflict $\{h_{0}\mapsto i,h_{i}\mapsto x\}$. Indeed, for every realisation, it is able to prune all but two holes. However, if the verifier would consider many realisations for $h_{0}$, it may (without advanced reasoning) generate much larger conflicts. Thus, considering a single realisation naturally fixes the context of the selected options and makes it clearer which holes are not relevant.

Appendix 0.A Program-level Counterexamples for CEGIS

This section reports on the relevant steps to instantiate an efficient implementation of the syntax-guided synthesis framework. First, available implementations of CE generation are too restricted in the variety of properties they support. Moreover, the embedding into a CEGIS-loop changes the focus of the CE generation. We motivate and report on a selection of changes. Finally, when moving from the analysis of a single model to a family of models, the well-foundedness criteria need reviewing, which we exemplify for three particularly important criteria.

0.A.1 Better CEs for CEGIS

Before diving into any changes, we recap the technique of [33] for computing traditional program-level CEs:

Definition 10 (High-level CEs [33])

Given a program $\mathcal{P}=(\mathrm{Var},C)$ and property $\varphi=\mathbb{P}_{\leq\lambda}[\lozenge G]$ s.t. $\mathcal{P}\not\models\varphi$, $E\subseteq C$ is a high-level CE if $\mathsf{fixdl}({\mathcal{P}}_{|E})\not\models\varphi$.

We have the following connection between high-level and program-level CEs.

Proposition 3

For safety properties, high-level and program-level CEs coincide.

Each program-level CE is trivially a high-level CE. A high-level CE is a program-level CE, as any additional command can only be enabled in unreachable or deadlock states. Otherwise, the program would contain overlapping commands, violating Def. 9. Recall that assuming only non-overlapping programs is crucial. Consider adding the command s=0 -> s’=2 to the program in Fig. 5a. The probability to reach s=3 is now reduced to $0.25$ resulting in the extended program no longer violating $\Phi$. Unreachable states are irrelevant to any property and, intuitively speaking, adding transitions to deadlocks cannot decrease the probability to reach $\psi$.

The technique in [33] computes minimal high-level CEs (i.e. the smallest set of commands) violating a given reachability property with an upper bound $\lambda$. The set is not unique in general. It reduces the computation to repeatedly solving MaxSat instances over two sets of propositional formulae, $\Xi$ and $\Upsilon$. $\Xi$ encodes a selection of commands and (via a negation) the MaxSat solver minimises the size of the command set. $\Upsilon$ encodes required (but not sufficient) constraints on valid CEs, e.g, it states that a command enabled in the initial state must be selected. In this way, the MaxSat solver returns a candidate set $E$ of commands. Using standard procedures it is then checked whether $E$ is sufficient to exceed $\lambda$. If so, $E$ by construction is a minimal CE. Otherwise, $\Upsilon$ is strengthened to exclude $E$ and (possibly) other candidate sets.

0.A.1.1 More properties

We provide support for program-level CEs beyond upper bounds on reachability probabilities. We deem support for liveness properties essential. Consider a sketch for a controller that moves a robot. A sketch that includes the option to wait together with the single objective that something bad may only happen with a small probability might simply never make any progress. While not doing anything typically induces safety, the synthesised controller is not useful. Likewise, performance criteria such as expected time to completion or expected energy consumption are widespread, and typically expressed as expected rewards.

Liveness properites

Proposition 3 is crucial for the correctness of our approach, but it does not hold for lower bounds (e.g. $\varphi=\mathbb{P}s_{\geq\lambda}[\lozenge G]$). Suppose $E$ is a (traditional) CE for $\mathcal{P}$ and $\varphi$. Adding commands may add probability-mass that reaches the target and thus may yield a program $\mathcal{P^{\prime}}$ such that $\mathcal{P^{\prime}}\models\Phi$. However, the statement does hold for lower bounds if there are no deadlocks reachable in $[\![\,{\mathcal{P}}_{|E}\,]\!]$.

The idea thus is to trap more probability mass than $1-\lambda$ in states $B$ from which there is no path to the target states $\psi$. To this end, we first compute a traditional CE $E$ for reaching $B$ with probability at most $1-\lambda$. Then, we extend $E$ with commands that ensure that the states in $B$ actually may never reach $\psi$. This is always possible by construction of $B$. The resulting set of commands is a program-level CE as in Def. 9. These CEs are no longer necessarily the smallest (in terms of the number of commands) for given $\mathcal{P}$ and $\varphi$.

Example 12

Consider the property $\varphi=\mathbb{P}_{>0.6}[\lozenge~{}\texttt{s=2}]$. The property is violated by the program from Fig. 4b. Fig. 5b constitutes a CE since with probability $0.5$ the system moves to s=3 that in turn is equipped with a self-loop. Hence, the probability to ever reach s=2 is guaranteed to be below $0.5$. Dropping the command with guard s=3 is insufficient for this guarantee: an additional command could add transitions from s=3 and s=1 to s=2 and meet the (lower) bound of $\varphi$.

Expected rewards

We adapted the ideas of state-level CEs for rewards from [59] to the program level. Intuitively, in the underlying MC of the program, we replace the self-loops from the $\mathsf{fixdl}$ operation by transitions to a target state. For its soundness, the method has to assume that for each realisation, the probability to reach the target is one. Otherwise, the costs are by definition infinite, and the instance can be rejected. Support for lower bounds on rewards requires additional assumptions and has not been considered so far.

0.A.1.2 A changed minimisation objective.

The following adaptions allow us to derive conflicts that are in many situations smaller than the conflicts derived from the minimal CEs described above. Smaller conflicts lead to more effective pruning and thus improve the performance of the framework. The conflicts we obtain are always at least as good as before.

Relevant commands

The MaxSat approach in [33] minimises over all commands. Recall that the design space is given only by relevant commands, i.e. the commands containing holes. Therefore, we change $\Xi$ to minimise the number of relevant commands. All other commands can be added to a CE without negatively affecting the sizes of the generated conflicts. This significantly reduces the number of candidates considered during the CE generation. Formula $\Upsilon$ still reasons about all commands, which allows to restrict the candidate command sets further.

Example 13

In Fig. 4a only the commands with guards s=0 and s=1 are relevant. Instead of considering up to $2^{4}$ candidate command sets (all four commands), we only consider up to $2^{2}$ CEs (the two relevant commands).

Multiple CEs

CEs (even with minimal size) are not unique. For the same realisation, multiple CEs may lead to different conflicts. Each of them can be used to prune future realisations from being explored. Furthermore, our approach does not require to use only the smallest CE, we may want to explore other CEs beyond the first one. However, minimality is crucial: If a strict subset of a CE $E$ is already a CE, conflicts generated by $E$ do not prune the design space further. We thus extend the MaxSat loop to prevents all supersets of $E$ being checked: If we find a CE $E$, we extend $\Upsilon$ by blocking all CEs which include the set of relevant commands in $E$.

CEs to multiple properties

We search for CEs that violate any of the properties. Candidate CEs that subsume other CEs (potentially for other properties) are superfluous and should not be considered. We integrated support for CE generation for multiple properties with the same path formula. For other combinations, a naive combination induces a severe performance hit to the MaxSat solver, and proper support is left as future work.

0.A.2 Handling ill-formed realisations.

Model checkers typically make some assumptions on the well-foundedness of the input, and might or might not enforce them. Relevant examples for non well-founded models are the existence of deadlocks in the model, variables that go out of their bounds, and –in this context– guards that overlap. In the presence of a sketch, these well-foundedness criteria are easily violated and thus rigorous handling is essential. We argue that it is not good to simply throw an error if the well-foundedness is violated by any realisation: Such rigour makes sketching overly complicated, and might require manually adding various constraints. Conversely, checking the well-foundedness of every candidate realisation on side of the verifier can significantly degrade the performance as by default only single realisations can be removed from the design space. Below we review how we handle ill-formed realisations to achieve a good trade-off between the usability and performance of the synthesis framework.

Out-of-bounds

Variable bounds should be strictly respected. However, constraining the sketch to prevent generation of realisations with out-of-bounds violations might be very complex. Therefore, we extend the model checker to add a state which reflects a variable being out-of-bounds by checking the variable values during the MC construction. Then, the properties are extended with a statement that no probability mass should reach these states. This extension allows us to apply conflict analysis and typically prune a set of realisations violating the variable bounds using a single verification query.

Overlapping guards

As already pointed out, overlapping guards can prevent effective CE generalisation. Therefore, we reject realisations with overlapping guards. In order mitigate the performance degradation caused by returning trivial conflicts, we implement a similar extension as for out-of-bounds.

Deadlocks

The existence of deadlocks prevents verification of time unbounded properties, therefore most verification tools automatically apply a $\mathsf{fixdl}$ operation. While this operation is sensible for a single program, it is not for sketches with holes in guards, as deadlocks are problematic for CE generalisation in combination with lower-bounded properties. Thus, we treat them analogous to out-of-bounds and overlapping guards.