On the software engineering challenges of applying reactive synthesis to robotics

Reactive synthesis is an automated procedure to obtain a correct-by-construction reactive system from its temporal logic specification. This short paper discusses the software engineering challenges in applying reactive synthesis to robotics, beyond the synthesis algorithms themselves, including the challenge of writing declarative specifications, the challenge of abstraction of data and time, and the challenge of availability of an adequate development process supported by related tools. The identification and description of the challenges are based on our experience in building a development environment for reactive synthesis and applying it to the construction of about 10 different autonomous Lego robots. We describe the challenges using concrete examples from one of the robots built in our lab.


INTRODUCTION
Reactive synthesis is an automated procedure to obtain a correctby-construction reactive system from its temporal logic specification [26].Rather than manually constructing an implementation and using model checking to verify it against a specification, synthesis offers an approach where a correct implementation of the system is automatically obtained for a given specification, if such an implementation exists.In the case of reactive synthesis, an implementation is typically given as a controller, i.e., an automaton that accepts input from the environment (e.g., from sensors) and produces the system's output (e.g., commands for actuators) to always satisfy the specification.
Reactive synthesis has been studied extensively in the formal methods and software engineering research literature, see, e.g., [1-3, 6, 13, 15, 19, 21, 23].While synthesis from Linear Temporal Logic (LTL) specifications [26] is generally considered impractical due its high computational complexity (double exponential in the length of the formula), synthesis from fragments of LTL, e.g., General Reactivity of Rank 1 (GR(1)) [3], has shown to allow for efficient sybolic implementations of synthesis algorithms.
One potential application domain for reactive synthesis is robotics.Indeed, in the last few years, a number of research groups have investigated this direction, providing initial results.Kress-Gazit et al. [14,16,30] applied reactive synthesis for robotics mission planning, where a synthesized controller guarantees a robot achieves a given task.Maniatopoulos et al. [17] present an approach to automatically generate code implementation of high-level robotic behavior using synthesis.They demonstrated their approach on the Atlas humanoid robot in the context of the 2015 DARPA Robotics Challenge.Wongpiromsarn et al. [31] use GR (1) synthesis in TuLiP, a software toolbox for synthesis of embedded control software with application to robotics mission planning.Gritzner and Greenyer [10] have investigated the use of reactive synthesis to generate PLC code for industrial robots.We have applied reactive synthesis in a case study for synthesizing a forklift controller [20] (used here as our running example, see Sect. 2).Furthermore, various synthesis tools have been developed independent of the robotics domain, e.g., Bloem et al. [2] developed RATSY, a requirement analysis tool with GR(1) synthesis and Ehlers and Raman [6] developed the GR(1) synthesis framework Slugs, which has been extended with a number of plugins for advanced analyses.
While these show some potential for future success, a wide chasm remains to be crossed before reactive synthesis becomes a tool in the hands of robotics software engineers.
In this short paper we discuss the key software engineering challenges in applying reactive synthesis to robotics, beyond the synthesis algorithms themselves.First, the challenge of writing declarative specifications.Second, the challenge of abstraction of data and time.Finally, the challenge of availability of an adequate development process supported by related tools.
We demonstrate these challenges via an example robot, one of many built in our lab at Tel Aviv University, where we have taught two project classes (in 2015 and in 2017), in which small teams of 3rd year Computer Science undergraduate students have used our synthesis environment in a semester long project, to develop about 10 different autonomous Lego robots, which the students actually built and run 1 .From these classes, we have collected over 200 versions of specifications, all written by these students.Our RoSE'18, May 28-June 28 2018, Gothenburg, Sweden Shahar Maoz and Jan Oliver Ringert choice of Lego as the underlying robotics technology for the class and for this research was motivated by its relatively low cost and its modularity, allowing us to gain experience from several different robots, e.g., a robot sorting Lego pieces by color, an elevator servicing different floors, a self parking Lego car, performing very different tasks.Furthermore, although different in detail and scale, the use of the Lego robots provided us with concrete examples of some of the challenges one expects to encounter with real-world robotic technologies, such as the inaccuracy of sensor readings, and the limitations in terms of battery, memory, and computation power.

RUNNING EXAMPLE
We start off with a running example of a specification for an autonomous forklift.The forklift is an actual Lego robot 2 shown on the left side of Fig. 1.We have constructed and experimented with this robot in our lab (see [20]).

Forklift Overview and Architecture
The forklift has a sensor to determine whether it is at a station, two distance sensors to detect obstacles and cargo, and an emergency button to stop it.It has two motors to turn the left and right wheels and one motor to lift the fork.Consider an initial set of informal requirements for the behavior of the forklift: (1) Do not run into obstacles.
(2) Only pick up or drop cargo at stations.
(3) Always keep on delivering cargo.(4) Never drop cargo at the station where it was picked up.
(5) Stop moving if emergency off is pressed.
The logical software architecture of the forklift is depicted as a component and connector model (see e.g., [28] and [11], for concepts of component and connector models) in Fig. 1 (b).The components on the left side are hardware wrappers that read sensor values and publish them as messages on their output ports.The output ports of the sensor components are connected to input ports of component Controller (names and types labeled on ports in Fig. 1).The output ports of component Controller (names and types labeled on ports in Fig. 1) are connected to three components on the right that receive commands and encapsulate access to the actuators (here different motors) of the forklift.
The execution of the robot is performed in a control cycle: read sensor data, execute controller, perform actions.The only delays during execution of cycles are introduced by computation times of components (in ranges of milliseconds).
We focus on the development of component Controller.This component is the most complicated in terms of reactive behavior as it contains the systems logic of how actuators are controlled to realize desired system behavior.

Example Specification
We show excerpts of a specification for the forklift robot in Lst. 1.The specification is written in the Spectra language [22].From the complete specification we can directly synthesize an implementation of component Controller (from Fig. 1).The specification starts by declaring environment controlled variables (inputs of Controller) and system controlled variables (outputs of Controller).
We introduce some short names for expressions in a define section in ll.15-23.As an example, we define stopping as an abbreviation for both motors receiving the command STOP and we define deliverUnlessBlocked as an abbreviation for dropping cargo or being blocked by the emergency off button or a low obstacle.
The main part of the specification are assumptions on the behavior of the environment and guarantees that a system implementation has to satisfy if all the assumptions hold.Assumptions and guarantees that start with the temporal operator G have to hold on all transitions between states, e.g., the assumption stationsDontMove in ll.[26][27] expresses that in all states where the forklift is stopping the value read by the station sensor does not change in the next state.Assumptions and guarantees with the temporal operator GF must be satisfied repeatedly after any finite number of transitions, e.g., the guarantee keepDelivering in ll.48-49 states that the forklift has to repeatedly deliver cargo unless it is repeatedly blocked.
We have added the five informal requirements from above as comments to guarantees of the specification that most closely resemble each requirement.The complete specification consists of 9 assumptions and 12 guarantees and it takes one second to synthesize an implementation from it.

CHALLENGES
We now list the three challenges that we have identified.For each, we first explain the challenge in general terms, then we illustrate it on examples relating to the forklift robot, and finally we mention existing works and how they relate to the presented challenge.

Writing declarative specifications
A major software engineering challenge for applying reactive synthesis is writing of declarative specifications.In a robotics software engineering process based on synthesis specifications replace code.Software components that are traditionally implemented manually are now synthesized automatically.However, shifting the focus on declarative specifications brings various challenges.First, there is currently little experience and almost no training for writing declarative specifications.Second, specification languages from the formal methods community, e.g., Linear Temporal Logic (LTL) [25] (which can be seen as the assembly language for synthesis), are not friendly to be used by engineers and specifying reasonable constraints on the robot's behavior may lead to very complex formulas.Finally, declarative specifications for non-trivial robot behavior require engineers to make assumptions on the behavior of the environment the robot operates in explicit.Inadequate assumptions and guarantees can lead to no or even undesired implementations of robot behavior.
Example 1.When executing synthesized controllers from earlier versions of the specification shown in Lst. 1 the forklift destroyed the physical lifting mechanism because a synthesized controller issued the lifting command when the robot had already lifted cargo.Example 2. Specifications describe temporal relations between system states.These relations easily become complex to describe in a declarative way.As an example, recall requirement (4) to never drop cargo at the same station that it was picked up.We formulate as a the temporal constraint that the between lifting cargo and dropping cargo the forklift has to leave the station.More technically, to express that a predicate p = !atStationalways has to be satisfied at least once between the satisfaction of predicates q = lifting and r = dropping we could write the following LTL formula: Intuitively, φ W ψ expresses that either φ holds forever or φ holds in every state until ψ holds in at least one state.Note that the temporal operator W is nested in the scope of the operator G and the predicate r is repeated multiple times.These LTL formulas can easily become unreadable, see e.g., the LTL specification patterns of Dwyer et al. [5] collected from existing specifications.In our example specification in Lst. 1 we use pattern names and instantiations [19], e.g., in guarantee leaveStationForDelivery (Lst. 1, ll. 52-54), instead of their LTL equivalent.
Example 3.An important part of a specification are assumptions on environment behavior.Note that our initial list of five informal requirements formulated only guarantees.Any non-trivial reactive behavior specification will require assumptions that promise that the environment will react to the behavior of the system, e.g., in order to ensure that packages will be delivered only on stations, the forklift will assume that if it stops on a station the station will not magically disappear (assumption stationsDontMove, Lst. 1, ll. 26-27).In addition, we might want to assume that the forklift always eventually finds a station, i.e., GF station.However, the combination of these two assumptions might lead to a system implementation that forces the environment to violate an assumption: the robot can stop forever, once it is not on a station and the environment will then fail to satisfy the assumption GF station.
Works Related to this Challenge.Most recent works in the area of applying reactive synthesis are indirectly related to the challenge of writing declarative specifications.In works by Kress-Gazit et al. [14,16,30] the specifications are written with primitives specific to path planning on a grid; or can be extracted using natural language processing [16].In [17] specifications for synthesis are generated from high-level models created by engineers.Fillippidis et al. [8] present a multi-paradigm specification language that mixes declarative and imperative elements.We have recently [19] shown how to support most of the well-known LTL specification patterns of Dwyer et al. [5] as specification elements for GR(1) synthesis.

Abstraction of data and time
A second major software engineering challenge for applying reactive synthesis to robotics system development is the necessity for abstraction of complex data and time.While this abstraction is a general challenge for robotics software development, properties of the underlying formalisms of reactive synthesis add additional complexity.First, the running time of a synthesis algorithm typically depends on the statespace -including inputs and outputs -of the specified system.As an example, the popular GR(1) synthesis algorithm [3], used in many synthesis tools, has complexity quadratic in the statespace where the statespace is exponential in the numbers of input and output variables.Thus, abstraction of data in the specification is often needed to make synthesis tractable.Second, the temporal relations expressed in specifications refer to    1.A complete version of the specification is available from http://smlab.cs.tau.ac.il/syntech/forklift/.See [22] for a language reference of the Spectra language used in this listing.a sequence of states and not to points in the physical time a robot operates in.Thus, an engineer has to find suitable mechanisms and abstractions to relate physical time to a virtual sequence of states.Example 5. Consider the scenario where the forklift delivers cargo.Intuitively we would want to express that the forklift needs to back up before it can turn to drive away from cargo (otherwise the fork might not be clear from cargo).In the forklift specification temporal relations are over states and execution steps but it is unrealistic to assume that backing up for one execution step will clear the fork from cargo.Specifications have to consider physical processes that take time not measured in execution steps.To address this challenge, we added the guarantee noTurningCloseToCargo (Lst. 1, ll. 40-41) and the assumption driveAwayFromCargoAndObstacles (Lst. 1, ll. 31-34).The assumption expresses that after some finite time of backing up or turning, cargo and obstacles will no longer block the sensors.The synthesizer will determine that backing up to clear cargo is the only viable option to continue.
Works Related to this Challenge.Recent works have started to address challenges of abstraction in different application domains of reactive synthesis.Murray et al. [7,31] have presented Tulip for synthesizing hybrid reactive systems where piecewise affine dynamics are automatically abstracted.Walker and Ryzhyk [29] presented predicate abstraction and refinement for reactive synthesis of device drivers where large memory registers are automatically abstracted.Raman et al. [27] formalized a pattern for supporting the execution of robot actions with arbitrary timing for reactive synthesis (our solution in Example 5 is similar to their approach).

Development process and tools
A third major challenge for applying reactive synthesis to robotics concerns the development process and the related tool support.Although the synthesized implementation is correct with regard to the specification, the specification itself may not correctly represent the intentions of the engineer who wrote it.Moreover, specifications, like code, evolve over time, as bugs are corrected and new features are added.Thus, only having a synthesis tool that provides correct-by-construction implementation of the specification does not suffice.Effective use of reactive synthesis implies major changes to traditional development processes and revised developer tasks, which in turn call for new tool support.Example 6.A specification may be over constrained, in which case it is unrealizable, i.e., there exists an environment that meets the specified assumptions and can force the system to violate some of the specified guarantees.For example, consider the following guarantee, expressing the requirement to go forward when no obstacle is detected: This guarantee, together with guarantee emergencyOff (Lst. 1, ll. 57-58), overconstrain possible behaviors when there is no obstacle and the emergency off is pressed.The specification would be unrealizable, and so no implementation will be synthesized.
Example 7. The problem described in Example 3 above is a case of non-well-separation [12], where a synthesized controller may satisfy the specification by forcing any environment to violate the assumptions (rather than by satisfying the guarantees).From a development process perspective, this problem may be worse than the above mentioned problem of unrealizability: since the synthesizer is able to output a controller, there is no hint of the problem, which will only appear later, during testing, or worse, in production.
Example 8.An earlier version of the forklift did not include an emergency off feature.To reflect the new requirement in the specification, we added the guarantee emergencyOff (Lst. 1, ll. 57-58).Note that this single guarantee affects the behavior of a synthesized controller in almost all of its states.Throughout development of a specification, many similar changes are expected.
Works Related to this Challenge.Some recent works have started to address a few aspects of this challenge.For example, to deal with unrealizable specifications, authors have shown how to compute an unrealizable core [4,13], i.e., a minimal subset of the guarantees for which the specification is already unrealizable.The core is intended to help the engineer by localizing the problem.Other works suggested also the computation and presentation of a counterstrategy [13,23,24], which shows how a synthesized environment can force any system implementation to violate the specification.We have recently presented the JVTS, a symbolic counter-strategy representation, which is typically much smaller, simpler, and can be computed faster than concrete counter-strategies [15].
To deal with non-well-separation, we have recently presented a tool to automatically identify different cases of non-well-separation and provide the engineer a non-well-separation core, i.e., a minimal subset of the assumptions that is already non-wellseparated [21].
To the best of our knowledge, no work has yet addressed other aspects of the development process, such as dealing with the evolution of specifications and testing of synthesized controllers.

Example 4 .
The forklift robot shown in Fig.1is equipped with distance sensors that measure distances up to 255cm with a resolution of 1cm.Including many input variables with large ranges in a specification could render traditional synthesis algorithms impractical.When developing the specification shown in Lst.1 we have introduced an abstraction of values smaller than 20cm to CLOSE and values greater or equal to 20cm to FAR.The abstraction is performed by component DistanceSensor and the environment variables in the specification in Lst. 1 only use the type Distance = FAR, CLOSE, e.g., for variable sense in guarantee dontHitObstacles (Lst. 1, ll. 37-38).