Synthesizing Robust Systems with RATSY This work was supported in part by the European Commission through project DIAMOND (FP7-2009-IST-4-248613), and by the Austrian Science Fund (FWF) through the national research network RiSE (S11406-N23).

Synthesizing Robust Systems with Ratsy thanks: This work was supported in part by the European Commission through project DIAMOND (FP7-2009-IST-4-248613), and by the Austrian Science Fund (FWF) through the national research network RiSE (S11406-N23).

Roderick Bloem    Hans-Jürgen Gamauf    Georg Hofferek    Bettina Könighofer    Robert Könighofer \IfArrayPackageLoaded
Institute for Applied Information Processing and Communications (IAIK),
Institute for Applied Information Processing and Communications (IAIK), \IfArrayPackageLoaded
Graz University of Technology, Austria
Graz University of Technology, Austria
Abstract

Specifications for reactive systems often consist of environment assumptions and system guarantees. An implementation should not only be correct, but also robust in the sense that it behaves reasonably even when the assumptions are (temporarily) violated. We present an extension of the requirements analysis and synthesis tool RATSY that is able to synthesize robust systems from GR(1) specifications, i.e., system in which a finite number of safety assumption violations is guaranteed to induce only a finite number of safety guarantee violations. We show how the specification can be turned into a two-pair Streett game, and how a winning strategy corresponding to a correct and robust implementation can be computed. Finally, we provide some experimental results.

Doron Peled and Sven Schewe (Eds.): First Workshop on Synthesis (SYNT2012) EPTCS 84, 2012, pp. Synthesizing Robust Systems with RATSY thanks: This work was supported in part by the European Commission through project DIAMOND (FP7-2009-IST-4-248613), and by the Austrian Science Fund (FWF) through the national research network RiSE (S11406-N23).LABEL:LastPage, doi:10.4204/EPTCS.84.4 © R. Bloem et al. This work is licensed under the Creative Commons Attribution License.

Synthesizing Robust Systems with RATSY thanks: This work was supported in part by the European Commission through project DIAMOND (FP7-2009-IST-4-248613), and by the Austrian Science Fund (FWF) through the national research network RiSE (S11406-N23).

Roderick Bloem and Hans-Jürgen Gamauf and Georg Hofferek and Bettina Könighofer and Robert Könighofer \IfArrayPackageLoaded
Institute for Applied Information Processing and Communications (IAIK),
Institute for Applied Information Processing and Communications (IAIK),
\IfArrayPackageLoaded
Graz University of Technology, Austria
Graz University of Technology, Austria

1 Introduction

Property synthesis automatically creates systems from formal specifications [7, 12, 3]. Synthesized systems are correct-by-construction. Recently there has been a lot of progress in making property synthesis practical [11, 5, 4]. One remaining problem is that synthesized systems often do not behave reasonably in unexpected situations, e.g., when environment assumptions are violated.

Many specifications consist of environment assumptions and system guarantees. For both we distinguish between safety and fairness properties. Safety guarantees must be fulfilled only if all safety assumptions are satisfied. If a safety assumption is violated, the system is allowed to behave arbitrarily. Safety assumptions may be violated due to a buggy environment, operator mistakes, radiation-related bit-flips, etc. The latter issue in particular is becoming more serious, due to continuously decreasing feature sizes [13]. Clearly, if safety assumptions are violated, the system may not be able to fulfill all safety guarantees. However, it should try to recover if the environment does. Unfortunately, synthesized systems sometimes stop performing any useful interaction once a safety assumption has been violated.

We present an extension of the requirements analysis and synthesis tool RATSY [3], which synthesizes robust systems from GR(1) specifications [11]. In [6], we introduced a notion of a failure in a safety specification, along with a notion of recovery. A system is robust if finitely many environment failures induce only finitely many system failures, where a system failure is a violation of a safety guarantee, and an environment failure is a violation of a safety assumption. Note that this condition can be encoded as a Streett pair.

In [2], we described how a GR(1) specification can be turned into a one-pair Streett game such that a winning strategy corresponds to a correct implementation. Consequently, the combination of the Streett pair for the GR(1) game and the Streett pair for robustness leads to a two pair Streett game, which we solve using the algorithm of [10]. In this paper, we show this approach using an example and show experimental results for robust synthesis.

Different notions of robustness have been studied in different settings. In [6], robustness for safety specifications is considered. Synthesis is done using one-pair Streett games. We use the same notion of robustness but consider GR(1) specifications. Robustness for liveness is addressed in [2]: for any number of violated assumptions, the number of violated guarantees must be as low as possible. We use their idea of transforming GR(1) into Streett games via a counting construction. In [9], robustness is not defined in terms of assumption and guarantee violations, but using metrics on the state of a system. Synthesis is performed via special automata incorporating these metrics. Robustness of sequential circuits is also addressed in [8]. Inputs are divided into control and disturbance variables. A system is robust if a finite number of changes in disturbance inputs result in a bounded number of changes in the output. Synthesis is not addressed.

The rest of this paper is organized as follows. Section 2 presents an example to illustrate the problem. Section 3 explains our method to synthesize robust systems. Section 4 explains the computation of a winning strategy for two-pair Streett games in more detail. In section 5, our method is applied to an example. Section 6 presents experimental results and concludes.

2 Illustration of the Problem

Consider the specification of a simple arbiter for a resource shared between two clients. The input signals and are used by the clients to request access to the resource. The arbiter grants access via the output signals and . The system must fulfill the following safety requirements. First, the system is never allowed to raise both grant signals at the same time. In LTL syntax, this can be written as . Second, a request has to be followed immediately by a grant, which can be formalized by the guarantees and . Finally, it is assumed that the environment never raises both request signals at the same time: . Combining the three guarantees and the assumption results in the specification . It requires the arbiter to satisfy all three guarantees, if the assumption is fulfilled.

Figure 1: Synthesized Finite State Machines.

One possible implementation of (in form of a finite state machine) is shown in Figure 1(a). If the environment assumption is violated, i.e., and are raised at the same time, the machine enters state , and will remain there forever. Irrespective of future inputs, both grant signals stay low, therefore and will not be fulfilled anymore. This is not robust: a finite number of environment errors leads to an infinite number of system errors, i.e., the system does not recover. Our new synthesis algorithm guarantees that this cannot happen. Instead, our approach may lead to an implementation as shown in Figure 1(b), which does not exhibit the aforementioned weakness. If two requests occur simultaneously now, one will be discarded while the other one will be granted. Once the environment resumes correct behavior, the system will also fulfill all its guarantees again.

3 Robust Synthesis from GR(1) Specifications

A GR(1) specification consists of environment assumptions and system guarantees. There are two kinds of assumptions and guarantees. Safety properties encode conditions which have to hold in all time steps. Fairness properties are conditions which have to hold infinitely often. The safety specifications are given as safety automata that are deterministic but not complete. Intuitively, a word fulfills safety specification if it has a run in the safety automaton.

GR(1) synthesis is performed as follows [2]. First, the specification is transformed into a one-pair Streett game via a counting construction. The safety properties are encoded directly into the transition relation of the Streett game. The fairness properties are expressed via the Streett pair. For fairness assumptions (with ) and fairness guarantees (with ), the state-space is extended with two counters and , which can be encoded with additional bits. The counter is incremented modulo whenever assumption (corresponding to the current counter value) is satisfied; similarly for , , modulo . If a counter has the special value , it is always incremented. The counter value indicates that all have been satisfied in a row; indicates the same for all . Hence, the condition , expressed by the Streett pair , ensures that the liveness part of the specification is encoded properly in the game. A winning strategy for this game corresponds to a correct implementation.

In order to obtain a system which is also robust, we extend the safety specifications. We add Boolean variables and . We then label all existing edges in the environment safety automaton with and add edges from any state to any other state with set to false, and similar for the system automaton. Thus, the automata become complete, but variable is set to whenever the environment violates some safety assumption, is set to iff the system violates a safety guarantee. Our notion of robustness can now be formulated using the condition , which is expressed by the Streett pair . An infinite number of system errors is only allowed if there is an infinite number of environment errors.

A winning strategy for the two-pair Streett game corresponds to a correct and robust implementation. We use a recursive fixpoint algorithm to compute the winning region [10]. Intermediate results of this computation can be used to obtain the winning strategy.

4 Computing a Winning Strategy for Streett(2)

Figure 2 shows the algorithm to compute the winning region of a Streett game  [10]. The input Set is a set of Streett pairs . The function pr(X) returns the set of states from which the system can force the play into in one step. LFix and GFix represent least and greatest fixpoint computations over sets of states. The operators &, | and ! perform intersection, union, and complementation of sets.

1Func main_Streett(Set)
2 If (|Set|=0)
3  Return mStr(true,false);
4 Return Str(Set,true,false);
5End  Func main_Streett(Set)
1Func mStr(sng,rt)
2 GFix(X)
3  X = rt | sng & pr(X);
4 End  GFix(X)
5 Return X;
6End  mStr
1Func Str(Set,sng,rt)
2 GFix(Z)
3  Foreach (<a,b> in Set)
4   nSet = Set - <a,b>;
5   p1 = rt | sng & b & pr(Z);
6   LFix(Y)
7    p2 = p1 | sng & pr(Y);
8    If (|nSet|=0)
9     Y = mStr(sng & !a,p2);
10    Else
11     Y = Str(nSet,sng&!a,p2);
12   End  LFix(Y)
13   Z = Y;
14  End  Foreach (<a,b>)
15 End  GFix(Z)
16 Return Z;
17End  Str
Figure 2: Algorithm to compute the winning strategy.
Figure 3: Illustration of the iterates of the fixpoint computation.

The following discussion assumes Set=. Let be the fixpoint in for the first Streett pair in the top-level call to Str. is the result for the second pair. We denote the iterates of these fixpoint computations by and . For both Streett pairs, the function Str is called recursively. The iterates of in the recursive call during the computation of are denoted for and .

Figure 3 illustrates the intuitive meaning of the iterates. As long as and hold, it is possible to proceed to the next lower iterate of . is reachable from and is reachable from . The resulting cycle allows to visit and infinitely often. If is not satisfied, the next lower iterate of may not be reachable. Not reaching ever again is fine if is also never satisfied again. However, the other Streett pair still has to be handled. This is ensured through the iterates from the recursive step. Figure 3 shows them for only. If holds, it is possible to proceed to the next lower iterate of and from back to . This cycle ensures that is visited infinitely often if holds infinitely often but does not. Analogously for all other iterates .

To define a strategy, we introduce one bit of memory. means should be fulfilled next, means should be fulfilled next. The strategy is composed of several parts, which we enumerate in the following table. They are prioritized from top to bottom. If a particular sub-strategy cannot be applied (because of violated assumptions), the next one is tried.

Nr. present state in: next state in: informal description
1 step towards
2 step towards
3 reached; switch towards
4 reached; switch towards
5 ; sub-game towards
6 ; sub-game towards
7 reached in sub-game
8 reached in sub-game
9 ; stay
10 ; stay

5 Example of Robust Synthesis

To demonstrate our approach, this section gives an example. Consider the specification of a full-handshake protocol with a request input signal and a grant output signal . For the environment, the safety assumption and the fairness assumption are defined. The system has to satisfy the safety guarantee and the fairness guarantee . Combining the assumptions and the guarantees results in the specification .

First, the specification is transformed into a one-pair Streett game. In this example there is no need for a counting construction, since there is only a single fairness assumption and guarantee. Figure  4(a) illustrates the encoding of the safety properties in the transition relation of the Streett game. The first bit of each state corresponds to the request signal and the second bit to the grant signal . For example, the transitions require that, if there is a request, has to stay until the request is granted.

Figure 4: arbiter example (a) Encoding of the safety properties in the transition relation. (b) Extension of the state space.

The following step is to extend the state space with the variables and , as shown in Figure  4(b). The third bit of each state corresponds to the signal , which encodes an error caused by the environment. If this bit is , no error occurred. Black solid lines indicate that there is no system error () and red dashed-lines indicate that there is one (). Colored states represent states where an environment error has occurred. E.g., assume we start in state . In this state, a request occurred which has not been granted yet, and no environment error occurred. The safety assumption prohibits the environment from lowering the request. If it does anyway, depending on the choice of the system, either the state ”010” or ”000” is entered, which are both colored states.

Next, the winning region and the strategy are computed. Figure 5 illustrates the iterates of the fixpoint computation. We have . To illustrate strategy computation, we consider the following scenario. Assume that and the arbiter is in a state out of \. The value of dictates to visit a state out of next, if possible. contains all states with an environment error. If we assume that the environment always behaves correctly, the set becomes unreachable. In order to win the game anyway, the system is not allowed to make a mistake either, so the arbiter stays in . This way the second Streett pair is fulfilled, because both sets are only visited finitely often. To win the game, the first Streett pair also has to be fulfilled. Therefore the subgame is entered, trying to reach states in while staying in . Through the loop in , it is possible to visit these states infinitely often, fulfilling the first Streett pair as well.

Figure 5: Illustration of the iterates of the fixpoint computation.

6 Results and Conclusions

We tested our implementation in RATSY with an arbiter, with request and acknowledge lines (cf. Section 2). Table 1 compares the synthesis time (seconds) and the implementation size (lines of Verilog), with and without robustness. As expected, the robust approach takes more time and creates larger circuits than RATSY’s original synthesis algorithm. This is due to the higher complexity of the new method. Simulating the synthesized systems shows that the number of system errors needed to recover after one environment error is really small. In most practical cases only one or even no system errors are needed.

N size w/o robustness size with robustness time w/o robustness time with robustness
2 85 501 0.04 0.15
3 145 1,234 0.08 1.07
4 230 2,829 0.14 3.37
5 324 5,614 0.18 11.13
10 1,072 90,215 0.81 3,485
15 2,215 3.30 26,172
Table 1: Performance results

The original synthesis algorithm of RATSY gave no formal guarantees for robustness. The extension presented in this paper guarantees that synthesized systems are correct-and-robust-by-construction. This comes at the cost of larger circuits and longer synthesis times, due to the increased computational complexity. Experimental results show that synthesized robust systems are able to recover with just very few system errors. In many practical cases, the ratio between system errors and environment errors is less than one. Since in practice, one has to be prepared for environment errors, guaranteed robustness is an important property enhancing the quality of a system.

References

Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
""
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
   
Add comment
Cancel
Loading ...
60279
This is a comment super asjknd jkasnjk adsnkj
Upvote
Downvote
""
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters
Submit
Cancel

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test
Test description