The Challenges in Specifying and Explaining Synthesized Implementations of Reactive Systems

Abstract

In formal synthesis of reactive systems an implementation of a system is automatically constructed from its formal specification. The great advantage of synthesis is that the resulting implementation is correct by construction; therefore there is no need for manual programming and tedious debugging tasks. Developers remain, nevertheless, hesitant to using automatic synthesis tools and still favor manually writing code. A common argument against synthesis is that the resulting implementation does not always give a clear picture on what decisions were made during the synthesis process. The outcome of synthesis tools is mostly unreadable and hinders the developer from understanding the functionality of the resulting implementation. Many attempts have been made in the last years to make the synthesis process more transparent to users. Either by structuring the outcome of synthesis tools or by providing additional automated support to help users with the specification process.In this paper we discuss the challenges in writing specifications for reactive systems and give a survey on what tools have been developed to guide users in specifying reactive systems and understanding the outcome of synthesis tools.

Automated Repair of Unrealisable LTL Specifications Guided by Model Counting

“…Let us present a running example to illustrate the main ideas behind AuRUS. Consider the problem of synchronising the access to a shared resource, via an arbiter [31]. Two processes request access to the resource via signals 𝑟 1 and 𝑟 2 , respectively.…”

“…Signals 𝑟 1, 𝑟 2 and 𝑎 thus constitute the inputs, while signals 𝑔1 and 𝑔2 are the outputs. The following guarantees are elicited in [31] for this problem:…”

“…Therefore, if any of the processes requests access to the resource in such a situation, no implementation would satisfy the guarantees 𝐺 1 and 𝐺 2 . In [31], authors propose different alternatives for "fixing" these issues. One option is to add an environment assumption to ensure that the resource is allowed to be accessed infinitely often; indeed, by adding the assumption 𝐴 1 = 23𝑎, the resulting specification becomes realisable.…”

“…One option is to add an environment assumption to ensure that the resource is allowed to be accessed infinitely often; indeed, by adding the assumption 𝐴 1 = 23𝑎, the resulting specification becomes realisable. Another option explored in [31] is to indicate that the arbiter will enforce mutual exclusion in accessing the resource. This is done by replacing 𝐺 3 by an alternative guarantee…”

Establishing Reliable Robot Behavior using Capability Analysis Tables

“…Finally, system guarantees and logical models representing a system are captured using formal methods [4,10,27,33]. More recently, Kress-Gazit presented a survey on how formal methods are used with robots [20] and a survey on the challenges of automatic code synthesis for reactive systems [21].…”