GR(1)*: GR(1) Specifications Extended with Existential Guarantees

Amram, Gal; Maoz, Shahar; Pistiner, Or

doi:10.1007/978-3-030-30942-8_7

Cited by 9 publications

(27 citation statements)

References 37 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…First, consider a finergrain analysis, down to the level of sub-formulas, i.e., detecting vacuities within specification elements. Second, Amram et al have recently defined GR(1)* [3], an extension of GR(1) specifications with existential guarantees. GR(1)* expressive power is strictly beyond that of LTL, so our present work cannot be applied to it as is.…”

Section: Discussionmentioning

confidence: 99%

“…2 describes states from which one can reach states in F with a finite path using the transition relation ρ. Equ. 3 describes states from which there is a path according to ρ that reaches all sets {J i } n i=1 infinitely often 3 . Both µ-formulas in Equ.…”

Section: Basic Symbolic Algorithmsmentioning

confidence: 99%

“…We use formulas with non-binary variables without explicitly translating them, e.g., we may write GF x ≥ 2 where D(x ) = {1, 2, 3} without using two binary variables for x . Our implementation fully supports multi-valued variables 3. If the set of justices is empty, we define one justice that contains all states.…”

mentioning

confidence: 99%

See 2 more Smart Citations

Inherent vacuity for GR(1) specifications

Maoz

Shalom

2020

Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Softw

Self Cite

View full text Add to dashboard Cite

Section: Discussionmentioning

confidence: 99%

Section: Basic Symbolic Algorithmsmentioning

confidence: 99%

See 1 more Smart Citation

Inherent vacuity for GR(1) specifications

Maoz

Shalom

2020

Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Softw

Self Cite

View full text Add to dashboard Cite

“…This design also ensures that extensions of the Spectra kernel beyond GR(1) will directly support the new Spectra language elements. 3…”

Section: Spectra Language Elementsmentioning

confidence: 99%

“…There, synthesis becomes the problem of generating an implementation that not only meets the pure GR(1) specification but also guarantees that the resource is never over consumed, if such an implementation exists. Finally, on this front of enriching Spectra, we have recently presented GR(1)* [3], a fragment of CTL* that extends GR(1) with existential guarantees that are not expressible in LTL. Importantly, yet, in comparison to GR(1), GR(1)* remains efficient, and induces only a minor additional cost in terms of time complexity, proportional to the extended length of the formula.…”

Section: Choice Of Gr(1) As Kernelmentioning

confidence: 99%

Spectra: a specification language for reactive systems

Maoz

Ringert

2021

Softw Syst Model

Self Cite

View full text Add to dashboard Cite

We introduce Spectra, a new specification language for reactive systems, specifically tailored for the context of reactive synthesis. The meaning of Spectra is defined by a translation to a kernel language. Spectra comes with the Spectra Tools, a set of analyses, including a synthesizer to obtain a correct-by-construction implementation, several means for executing the resulting controller, and additional analyses aimed at helping engineers write higher-quality specifications. We present the language in detail and give an overview of its tool set. Together with the language and its tool set, we present four collections of many, non-trivial, large specifications, written by undergraduate computer science students for the development of autonomous Lego robots and additional example reactive systems. The collected specifications can serve as benchmarks for future studies on reactive synthesis. We present the specifications, with observations and lessons learned about the potential use of reactive synthesis by software engineers.

show abstract

Adapting Behaviors via Reactive Synthesis

Amram

Bansal

Fried

et al. 2021

Lecture Notes in Computer Science

Self Cite

View full text Add to dashboard Cite

In the Adapter Design Pattern, a programmer implements a Target interface by constructing an Adapter that accesses an existing Adaptee code. In this work, we present a reactive synthesis interpretation to the adapter design pattern, wherein an algorithm takes an Adaptee and a Target transducers, and the aim is to synthesize an Adapter transducer that, when composed with the Adaptee, generates a behavior that is equivalent to the behavior of the Target. One use of such an algorithm is to synthesize controllers that achieve similar goals on different hardware platforms. While this problem can be solved with existing synthesis algorithms, current state-of-the-art tools fail to scale. To cope with the computational complexity of the problem, we introduce a special form of specification format, called Separated GR(k), which can be solved with a scalable synthesis algorithm but still allows for a large set of realistic specifications. We solve the realizability and the synthesis problems for Separated GR(k), and show how to exploit the separated nature of our specification to construct better algorithms, in terms of time complexity, than known algorithms for GR(k) synthesis. We then describe a tool, called SGR(k), that we have implemented based on the above approach and show, by experimental evaluation, how our tool outperforms current state-of-the-art tools on various benchmarks and test-cases.

show abstract

GR(1)*: GR(1) Specifications Extended with Existential Guarantees

Cited by 9 publications

References 37 publications

Inherent vacuity for GR(1) specifications

Inherent vacuity for GR(1) specifications

Spectra: a specification language for reactive systems

Adapting Behaviors via Reactive Synthesis

Contact Info

Product

Resources

About