G4ltlSt: Automatic Generation of PLC Programs
Abstract
G4LTLST automatically synthesizes control code for industrial Programmable Logic Controls (PLC) from timed behavioral specifications of inputoutput signals. These specifications are expressed in a linear temporal logic (LTL) extended with nonlinear arithmetic constraints and timing constraints on signals. G4LTLST generates code in IEC 611313compatible Structured Text, which is compiled into executable code for a large number of industrial fieldlevel devices. The synthesis algorithm of G4LTLST implements pseudoBoolean abstraction of data constraints and the compilation of timing constraints into LTL, together with a counterstrategyguided abstractionrefinement synthesis loop. Since temporal logic specifications are notoriously difficult to use in practice, G4LTLST supports engineers in specifying realizable control problems by suggesting suitable restrictions on the behavior of the control environment from failed synthesis attempts.
Keywords:
industrial automation, LTL synthesis, theory combination, assumption generation1 Overview
Programmable Logic Controllers (PLC) are ubiquitous in the manufacturing and processing industries for realizing realtime controls with stringent dependability and safety requirements. A PLC is designed to read digital and analog inputs from various sensors and other PLCs, execute a userdefined program, and write the resulting digital and analog output values to various output elements including hydraulic and pneumatic actuators or indication lamps. The time it takes to complete such a scan cycle typically ranges in the milliseconds.
The languages defined in the IEC 611313 norm are the industry standard for programming PLCs [1]. Programming in these rather lowlevel languages can be very inefficient, and yields inflexible controls which are difficult to maintain and arduous to port. Moreover, industry is increasingly moving towards more flexible and modular production systems, where the control software is required to adapt to frequent specification changes [2].
With this motivation in mind, we developed the synthesis engine G4LTLST for generating IEC 611313compatible Structured Text programs from behavioral specifications. Specifications of industrial control problems are expressed in a suitable extension of linear temporal logic (LTL) [16]. The wellknown LTL operators G, F, U, and X denote “always”, “eventually”, “(strong) until”, and “next”s relations over linear execution traces. In addition to vanilla LTL, specifications in G4LTLST may also include

nonlinear arithmetic constraints for specifying nonlinear constraints on realvalued inputs;

timing constraints based on timer constructs specified in IEC 611313.
A timing constraint of the form 10sec(light), for example, specifies that the light signal is on for 10 seconds. Moreover, the semantics of temporal specifications in G4LTLST is slightly different from the standard semantics as used in model checking, since the execution model of PLCs is based on the concept of Mealy machines. Initial values for output signals are therefore undefined, and the synthesis engine of G4LTLST assumes that the environment of the controller makes the first move by setting the inputs.
Consider, for example, the PLC specification in Figure 1 with a specified scan cycle time of 50ms (line 1). The input variables store bounded input and sensor values, and output values are available at the end of each scan cycle at grant1, grant2, and light (line 1). According to the specification in line 6, the output light must be on for at least 10 seconds whenever an error occurs, that is, input signal err is raised. Line 7 requires that if err no longer appears, then eventually the light signal is always off. The transitionstyle LTL specifications 3 and 4 in Figure 1 require setting grant1 (resp. grant2) to true in the next cycle whenever the condition (resp. ) holds. Finally, grant1 and grant2 are supposed to be mutually exclusive (line 5).
The synthesis engine of G4LTLST builds on top of traditional LTL synthesis techniques [15, 11, 17, 4] which view the synthesis problem as a game between the (sensor) environment and the controller^{1}^{1}1Appendex C provides the detailed formulation and implemented algorithm for LTL synthesis.. The moves of the environment in these games are determined by setting the input variables, and the controller reacts by setting output variables accordingly. The controller wins if the resulting inputoutput traces satisfy the given specification. Notably, arithmetic constraints and timers are viewed as theories and thus abstracted into a pseudoBoolean LTL formula. This enables G4LTLST to utilize CEGARlike [8, 14, 12] techniques for successively constraining the capabilities of the control environment.
Since specifications in linear temporal logic are often notoriously difficult to use in practice, G4LTLST diagnoses unrealizable specifications and suggests additional assumptions for making the controller synthesis problem realizable. The key hypothesis underlying this approach is that this kind of feedback is more useful for the engineer compared to, say, counter strategies. The assumption generation of G4LTLST uses builtin templates and heuristics for estimating the importance and for ordering the generated assumptions accordingly.
Synthesis of control software, in particular, has been recognized as a key Industrie 4.0 technology for realizing flexible and modular controls (see, for example, [3], RE2 on page 44). The synthesis engine G4LTLST is planned to be an integral part of a complete development tool chain towards meeting these challenges. G4LTLST is written in Java and is available(under the GPLv3 open source license) at
http://www.sourceforge.net/projects/g4ltl/files/beta
In the following we provide an overview of the main features of G4LTLST including PseudoBoolean abstractions of timing constraints, the abstractionrefinement synthesis loop underlying G4LTLST and its implementation, and, finally, the templatebased generation for suggesting new constraints of the behavior of the environment for making the control synthesis problem realizable. These features of G4LTLST are usually only illustrated by means of examples, but the initiated reader should be able to fill in missing technical details.
Realtime specification pattern  Encoding in LTL 

Whenever a, then b for seconds  
Whenever a continues for more  
than seconds, then b  
Whenever a, then b,  
until c for more than seconds 
2 Timing Abstractions
The timing constraint in Figure 1 with its 10 seconds timeout may be encoded in LTL by associating each discrete step with a 50ms time delay. Notice, however, that up to 200 consecutive X operators are needed for encoding this simple example.
Instead we propose a more efficient translation, based on standard IEC 611313 timing constructs, for realizing timing specifications. Consider, for example, the timed specification . In a first step, fresh variables t1.start and t1.expire are introduced, where t1 is a timer variable of type TON in IEC 611313. The additional output variable t1.start starts the timer t1, and the additional input variable t1.expire receives a timeout signal from t1 ten seconds after this timer has been started. Now, the timing specification is rewritten as an LTL specification for a function block in the context of a timer.
The antecedent formula ensures that the expire signal is eventually provided by the timing block of the environment. Since no provision is being made that there is a timeout exactly after 10 seconds, however, the precise expected behavior of the timeout environment is overapproximated.
It is straightforward to generate PLC code using timing function blocks from winning strategies of the controller. Whenever t1.start is set to true the instruction t1(IN:=0, PT:=TIME#10s) is generated for starting the timer t1. Instructions that set t1.start to false is ignored based on the underlying semantics of timers. Finally, timeout signals t1.expire are simply replaced with the variable t1.Q of the IEC 611313 timing construct.
In Table 1 we describe some frequently encountered specification patterns and their translations using IEC 611313like timing constructs. Each of these patterns requires the introduction of a fresh timer variable t1 together with the assumption on the environment providing timeouts. These specification patterns, however, are not part of the G4LTLST input language, since there is no special support in the synthesis engine for these language constructs, and G4LTLST is intended to be used in integrated development frameworks, which usually come with their own specification languages.
3 AbstractionRefinement Synthesis Loop
The input to the synthesis engine of G4LTLST are LTL formulas with nonlinear arithmetic constraints with bounded real (or rational) variables, and the workflow of this engine is depicted in Figure 2. Notice, however, that the abstractionrefinement loop in Figure 2 is more general in that it works for any decidable theory Th.
In a preliminary step Abstract simply replaces arithmetic constraints on the inputs with fresh Boolean input variables. The resulting specification therefore is (like the timer abstraction in Section 2) an overapproximation of the behavior of the environment. In our running example in Figure 1 (ignoring line 6, 7), Abstract creates two fresh Boolean variables, say req1 and req2, for the two input constraints and to obtain the pseudoBoolean specification
(1) 
Clearly, this pseudoBoolean specification with input variables req1 and req2 overapproximates the behavior of the environment, since it does not account for interrelationships of the arithmetic input constraints.
In the next step, LTL controller synthesis checks whether or not the pseudoBoolean LTL formula generated by Abstract is realizable. If the engine is able to realize a winning strategy for the control, say , then a controller is synthesized from this strategy. Otherwise, a candidate counterstrategy, say , for defeating the controller’s purpose is generated.
The pseudoBoolean specification (1), for example, is unrealizable. A candidate counterstrategy for the environment is given by only using the input , since, in violation of the mutual exclusion condition (1), the controller is forced to subsequently set both grant1 and grant2 .
The Extract module extracts candidate counterstrategies with fewer pseudoBoolean input valuations (via a greedybased method) whose validity are not proven at the theory level. Consequently, the Extract module generates a candidate counterstrategy that only uses and the input valuations are passed to the Theory Checker.
A candidate counterstrategy is a genuine counterstrategy only if all pseudoBoolean input patterns are satisfiable at the theory level; in these cases the environment wins and Theory Checker reports the unrealizability of the control problem. In our running example, however, the input is not satisfiable at the theory level, since the conjunction of the input constraints and is unsatisfiable for . G4LTLST uses the JBernstein [6] verification engine for discharging quantifierfree verification conditions involving nonlinear real arithmetic. In order to avoid repeated processing at the theory level, all satisfiable inputs are memorized.
Unsatisfiable input combinations are excluded by Refine. In our running example, the formula is added as a new assumption on the environment, since the input pair has been shown to be unsatisfiable.
(2) 
In this way, Refine successively refines the overapproximation of the behavior of the environment. Running the LTL synthesis engine on the refined specification 2 yields a controller: if one of req1 () and req2 () holds, the controller may grant the corresponding client in the next round, since req1 and req2 do not hold simultaneously.
Refinement of Timer Environments.
The refinement of overapproximations of environmental behavior also works for the abstracted timer environments. Recall from Section 2 that the initial abstraction is given by . Assuming, for example, that t1.expire appears two iterations after t1.start in a candidate counterstrategy, one might strengthen this initial assumption with
Synthesized Code.
The synthesized PLC for the complete control specification in Figure 1 is listed in the Appendix A. This synthesized function block can readily be passed to industrystandard PLC development tools for connecting function blocks with concrete field device signals inside the main program to demonstrate desired behavior. Notice that the synthesized code in Appendix A is separated into two independent state machines. This separation is based on a simple analysis of G4LTLST for partitioning the specification into blocks with mutually independent output variables. In particular, in Figure 1, the formulas in line 3 to 5 do not consider err and light, and the formulas in lines 6 and 7 do not consider x, y, grant1, grant2 . Therefore, code for these two blocks can be synthesized independently.
Constraints over input and output variables.
Even though the current implementation of G4LTLST is restricted to specifications with arithmetic constraints on inputs only, the abstractionrefinement synthesis loop in Figure 2 works more generally for arithmetic constraints over input and output variables. Consider, for example, the specification with input variables and output variable . Abstraction yields a pseudoBoolean specification with in, out fresh input variables for the constraints and , respectively. Now, pseudoBoolean LTL synthesis generates a candidate winning strategy for the controller, which simply sets the output out to be always true. The candidate controller is realizable if every pseudoBoolean output assignment of is indeed satisfiable on the theory level. This condition amounts to demonstrating validity of the quantified formula Using the witness, say, for the existentially quantified output variable , a winning strategy for the controller is to always set the output to , and the control synthesis problem therefore is realizable.
Otherwise, the candidate controller strategy is not realizable at the theory level, and, for pseudoBoolean outputs, refinement due to unrealizability of the control synthesis problem is achieved by adding new constraints as guarantees to the pseudoBoolean specification. For example the constraint is added to the pseudoBoolean specification, if pseudoBoolean outputs grant1 and grant2 are mutually exclusive at the theory level.
In this way, the abstractionrefinement synthesis loop in Figure 2 may handle arbitrary theory constraints on input and output variables as long as corresponding verification conditions in a firstorder theory with one quantifieralternation can be decided. The implementation of G4LTLST could easily be extended in this direction by using, for examples the verification procedure for the existsforall fragment of nonlinear arithmetic as described in [7]. So far we have not yet encountered the need for this extensions, since the PLC case studies currently available to us are restricted to Boolean outputs.
# Example (synthesis) 
Timer(T)/ Data(d) 
lines of spec 
Synthesis Time 
Lines of ST 

Ex1  T, D  9  1.598s (comp)  110 
Ex2  T  13  0.691s  148 
Ex3  T  9  0.303s  80 
Ex4  T  13  21s  1374 
Ex5  T  11  0.678s (comp)  210 
Ex6    7  0.446s  41 
Ex7  D  8  17s  43 
Ex8  T  8  0.397s (comp)  653 
Ex9  abstract D,T  3 + model ( loc)  1.55s  550 
Ex10  abstract D,T  3 + model ( loc)  3.344s  229 
Ex11  abstract D,T  3 + model ( loc)  0.075s  105 
# Example (Assup. gen) 
# Learned Assump. 
Time of Learning 

Ex1  1  0.127s 
Ex2  1  0.452s 
Ex3  1  3.486s 
Ex4  4  22s (DFS) 
Ex5  1  2.107s 
Ex6  1  1.046s 
Ex7  1  0.154 
Ex8  1  2.877 
Ex9  1  8.318 
4 Assumption Generation
An unrealizable control synthesis problem can often be made realizable by restricting the capabilities of the input environment in a suitable way. In our case studies from the manufacturing domain, for example, suitable restrictions on the arrival rate of workpieces were often helpful. G4LTLST supports the generation of these assumptions from a set of given templates. For example, instantiations of the template , where ?a and ?b are metavariables for inputs, disallows successive arrivals of an input signal ?a. For a prespecified set of templates, G4LTLST performs a heuristic match of the metavariables with input variables by analyzing possible ways of the environment to defeat the control specification.
The underlying LTL synthesis engine performs bounded unroll [17] of the negated property to safety games. Therefore, whenever the controller can not win the safety game, there exists an environment strategy which can be expanded as a finite tree, whose leaves are matched with the risk states of the game. Then, the following three steps are performed successively:

Extract a longest path from the source to the leaf. Intuitively, this path represents a scenario where the controller endeavors to resist losing the game (without intentionally losing the game). For example, assume for such a longest path, that the environment uses to win the safety game.

Generalize the longest path. Select from the set of templates one candidate which can fit the path in terms of generalization. For example, the path above may be generalized as . For every such template, the current implementation of G4LTLST defines a unique generalization function.

Resynthesize the controller based on the newly introduced template. For example, given as the original specification, the new specification will be , which is equivalent to . Therefore, the path is generalized as an assumption stating that a should appear infinitely often.
If this process fails to synthesize a controller, then new assumptions are added to further constrain the environment behavior. When the number of total assumptions reaches a predefined threshold but no controller is generated, the engine stops and reports its inability to decide the given controller synthesis problem.
5 Outlook
The synthesis engine of G4LTLST has been evaluated on a number of simple automation examples extracted both from public sources and from ABB internal projects. The evaluation results in Table 2 demonstrate that, despite the underlying complexity of the LTL synthesis, G4LTLST can still provide a practical alternative to the prevailing lowlevel encodings of PLC programs^{2}^{2}2Short descriptions of the case studies have been added to the appendix., whose block size are (commonly) within 1000 LOC. This is due to the fact that many modules are decomposed to only process a small amount of I/Os. For small sized I/Os, the abstraction of timers and data in G4LTLST together with counterstrategybased lazy refinement are particularly effective in fighting the state explosion problem, since unnecessary unrolling (for timing) and bitblasting (for data) are avoided. Data analysis is also effective when no precise (or imprecise) environment model is provided, as is commonly the case in industrial automation scenarios.
Mechanisms such as assumption generation are essential for the widespread deployment of G4LTLST in industry, since they provide feedback to the designer in the language of the problem domain. Extensive field tests, however, are needed for calibrating assumption generation in practice. Moreover, a targeted frontend language for highlevel temporal specification of typical control problems for (networks of) PLCs needs to be developed [13].
References
 [1] International Electrotechnical Commission IEC 611313 Ed. 3.0: Programmable Controllers – Part 3: Programming languages. International Electrotechnical Commission, Geneva, Switzerland, 2013.
 [2] Recommendations for implementing the strategic initiative  INDUSTRIE 4.0. German National Academy of Science and Engineering (AcaTech). April, 2013.
 [3] Die Deutsche NormungsRoadmap  INDUSTRIE 4.0. DKE German Commission for Electrical, Electronic & Information Technologies. December, 2013.
 [4] A. Bohy, V. Bruyère, E. Filiot, N. Jin, and J.F. Raskin. Acacia+, a tool for LTL synthesis. In CAV, volume 7358 of LNCS, pages 652–657. Springer, 2012.
 [5] C.H. Cheng, M. Geisinger, H. Ruess, C. Buckl, and A. Knoll. MGSyn  Automatic Synthesis for Industrial Automation In CAV, volume 7358 of LNCS, pages 658–664. Springer, 2012.
 [6] C.H. Cheng, H. Ruess, and N. Shankar. JBernstein  a validity checker for generalized polynomial constraints. In CAV, volume 8044 of LNCS, pages 656–661. Springer, 2013.
 [7] C.H. Cheng, N. Shankar, H. Ruess, and S. Bensalem. EFSMT: A Logical Framework for CyberPhysical Systems. arXiv:1306.3456. 2013.
 [8] E. Clarke, O. Grumberg, S. Jha, Y. Lu, H. Veith. Counterexampleguided abstraction refinement. In CAV, volume 1855 of LNCS, pages 154–169. Springer, 2000.
 [9] P. Gastin and D. Oddoux. Fast LTL to Büchi automata translation. In CAV, volume 2102 of LNCS, pages 53–65. SpringerVerlag, 2001.
 [10] D. Giannakopoulou and F. Lerda. From states to transitions: Improving translation of LTL formulae to Büchi automata. In FORTE, volume 2529 of LNCS, pages 308–326. SpringerVerlag, 2002.
 [11] B. Jobstmann and R. Bloem. Optimizations for LTL synthesis. In FMCAD, pages 117–124. IEEE, 2006.
 [12] T. A. Henzinger, R. Jhala, and R. Majumdar. CounterexampleGuided Control. ICALP 2003: 886902 In ICALP, volume 2719 of LNCS, pages 886–902. Springer, 2003.
 [13] O. Ljungkrantz, K. Akesson, M. Fabian, and C. Yuan. Formal Specification and Verification of Industrial Control Logic Components. IEEE Tran. on Automation Science and Engineering, 7(3):538 – 548, 2010.
 [14] R. Nieuwenhuis, A. Oliveras, and C. Tinelli. Abstract DPLL and abstract DPLL modulo theories. In LPAR, volume 3835 of LNCS, pages 36–50. Springer, 2005.
 [15] A. Pnueli and R. Rosner. On the synthesis of a reactive module. In POPL, pages 179–190. ACM, 1989.
 [16] A. Pnueli. The temporal logic of programs. In FOCS, pages 46–57. IEEE, 1977.
 [17] S. Schewe and B. Finkbeiner. Bounded synthesis. In ATVA, volume 4762 of LNCS, pages 474–488. SpringerVerlag, 2007.
 [18] M. Senesky, G. Eirea, and T. J. Koo. Hybrid modelling and control of power electronics. In HSCC, pages 450–465. Springer, 2003.
 [19] A. SolarLezama, R. Rabbah, R. Bodík, and K. Ebcioğlu. Programming by sketching for bitstreaming programs. In PLDI, pages 281–294. ACM, 2005.
 [20] A. Zutshi, S. Sankaranarayanan, and A. Tiwari. Timed relational abstractions for sampled data control systems. In CAV, pages 343–361. Springer, 2012.
Appendix A Synthesized Function Block
Structured Text generated by G4LTLST for the synthesis control problem in Figure 1.
FUNCTION_BLOCK FB_G4LTL VAR_INPUT x: REAL; y: REAL; error: BOOL; END_VAR VAR_OUTPUT grant1: BOOL; grant2: BOOL; light: BOOL; END_VAR VAR cstate1 : INT := 0; cstate2 : INT := 0; p0 : BOOL; p1 : BOOL; t1: TON; END_VAR VAR CONST T1_VALUEΨ: TIME := TIME#10s; END_VAR p0 := (x)+(y)>3; p1 := (x*x)+(y*y)<3.5; (* Update the predicate based on sensor values *) CASE cstate1 OF (* State machines *) 0: IF ((p0 = TRUE) AND (p1 = FALSE)) THEN cstate1 := 9; grant1 := TRUE; grant2 := FALSE; ELSIF ((p0 = FALSE) AND (p1 = FALSE)) THEN cstate1 := 0; grant1 := TRUE; grant2 := FALSE; ELSIF ((p0 = FALSE) AND (p1 = TRUE)) THEN cstate1 := 7; grant1 := TRUE; grant2 := FALSE; ELSIF ((p0 = TRUE) AND (p1 = TRUE)) THEN cstate1 := 11; grant1 := TRUE; grant2 := FALSE; END_IF; 7: IF ((p0 = TRUE) AND (p1 = FALSE)) THEN cstate1 := 9; grant1 := FALSE; grant2 := TRUE; ELSIF ((p0 = FALSE) AND (p1 = FALSE)) THEN cstate1 := 0; grant1 := FALSE; grant2 := TRUE; ELSIF ((p0 = FALSE) AND (p1 = TRUE)) THEN cstate1 := 7; grant1 := FALSE; grant2 := TRUE; ELSIF ((p0 = TRUE) AND (p1 = TRUE)) THEN cstate1 := 11; grant1 := TRUE; grant2 := FALSE; END_IF; 9: IF ((p0 = TRUE) AND (p1 = FALSE)) THEN cstate1 := 9; grant1 := TRUE; grant2 := FALSE; ELSIF ((p0 = FALSE) AND (p1 = FALSE)) THEN cstate1 := 0; grant1 := TRUE; grant2 := FALSE; ELSIF ((p0 = FALSE) AND (p1 = TRUE)) THEN cstate1 := 7; grant1 := TRUE; grant2 := FALSE; ELSIF ((p0 = TRUE) AND (p1 = TRUE)) THEN cstate1 := 11; grant1 := TRUE; grant2 := FALSE; END_IF; 11: IF (( true )) THEN cstate1 := 11; grant1 := TRUE; grant2 := FALSE; END_IF; END_CASE; CASE cstate2 OF 0: IF ((error = TRUE) AND (TRUE)) THEN cstate2 := 12; light := TRUE; t1(IN:=0, PT:=T1_VALUE); ELSIF ((error = FALSE) AND (TRUE)) THEN cstate2 := 6; light := FALSE; END_IF; 43: IF ((error = TRUE) AND (TRUE)) THEN cstate2 := 12; light := TRUE; t1(IN:=0, PT:=T1_VALUE); ELSIF ((error = FALSE) AND (TRUE)) THEN cstate2 := 43; light := FALSE; END_IF; 6: IF ((error = TRUE) AND (TRUE)) THEN cstate2 := 12; light := TRUE; t1(IN:=0, PT:=T1_VALUE); ELSIF ((error = FALSE) AND (TRUE)) THEN cstate2 := 6; light := FALSE; END_IF; 396: IF ((error = TRUE) AND (TRUE)) THEN cstate2 := 12; light := TRUE; t1(IN:=0, PT:=T1_VALUE); ELSIF ((error = FALSE) AND (t1.Q = FALSE)) THEN cstate2 := 396; light := TRUE; ELSIF ((error = FALSE) AND (t1.Q = TRUE)) THEN cstate2 := 43; light := FALSE; END_IF; 81: IF ((error = TRUE) AND ( TRUE )) THEN cstate2 := 12; light := TRUE; t1(IN:=0, PT:=T1_VALUE); ELSIF ((error = FALSE) AND (t1.Q = FALSE)) THEN cstate2 := 396; light := TRUE; ELSIF ((error = FALSE) AND (t1.Q = TRUE)) THEN cstate2 := 43; light := FALSE; END_IF; 12: IF ((error = TRUE) AND (TRUE)) THEN cstate2 := 12; light := TRUE; t1(IN:=0, PT:=T1_VALUE); ELSIF ((error = FALSE) AND (t1.Q = FALSE)) THEN cstate2 := 81; light := TRUE; ELSIF ((error = FALSE) AND (t1.Q = TRUE)) THEN cstate2 := 6; light := FALSE; END_IF; END_CASE; END_FUNCTION_BLOCK
Appendix B Evaluation
In this section, we outline specifications for each problem under analysis.

Ex1 Original example listed in Figure 1.

Ex2 Simplified specification for equivalence with discrepancy time monitoring: The discrepancy time is the maximum period during which both inputs may have different states without the function block detecting an error. The block should signal error when two input valuation differ in their values for more than time .

Ex3 Simplified specification for safety request: It monitors the response time between the safety function request (s_opmode set to FALSE) and the actuator acknowledgment (s_ack switches to TRUE). Whenever the time exceeds the userspecified threshold , signal error and propose again request to the actuator.

Ex4 Simplified specification for sequential muting. Sequential muting is a standard mechanism to monitor the entry of workpieces into critical region using 4 sensors; it is used when transporting the material into the danger zone without causing the machine to stop. The mechanism should signal the entry and leave of objects, and if the object does not leave the critical region within a userspecified time interval , error should be reported.

Ex5 Control for conveyor belt. Transfer an object when light barrier detects it. If another object appears before the current output leaves, signal light and make alarm sound for seconds. Resume when the reset button is pressed. Also retain silence when no object arrives.

Ex6 Example specification from the paper “Formal Specification and Verification of Industrial Control Logic Components” [13].

Ex7 Control synthesis for simple nonlinear systems, where the underlying dynamics is captured by a predicate transition system, which can be considered as the result of timed relational abstraction [20]. To successfully control the system, one needs to perform numerical reasoning also on the theory level, as the specification and the environment model use different predicates.

Ex8 Lowlevel device function synthesis. Our previous work MGSyn [5] synthesizes highlevel orchestration code (in C++) to control each cell via OPC DA communication^{3}^{3}3http://en.wikipedia.org/wiki/OPC_Data_Access. Nevertheless, it assumes that each station (cell) should provide a set of prespecified functions (as a library) to control lowlevel devices. As an experiment, we use G4LTLST to synthesize some these basic functions for the Pick&Place module of the FESTO modular production system^{4}^{4}4http://didacticonline.de/inten/learningsystems/mpsthemodularproductionsystem/stations/pickplacestationsmallisbeautiful.htm. The combination of MGSyn and G4LTLST therefore completes the whole picture of automatic synthesis.

Ex9 The DCDC boost converter circuit example [18]. The goal is to synthesize a PLC controller which opens or closes switches appropriately such that the behavior of the underlying linear hybrid system is always constrained under a certain threshold. The environment model (as a transition system) is generated from timed relational abstraction [20] extended with predicates^{5}^{5}5NOTICE: For this model, a special input format is used to read the result of relational abstraction and product it with the translated game, rather than viewing them as environmental assumptions (when doing so, the environmental assumption contains around 200 lines) and bring all assumptions into the process of generating Büchi automaton and perform bounded unroll.. Two additional models are provided.

Ex10 Control of inverted pendulum with a physical model processed under timedrelational abstraction.

Ex11 Control of track system with a physical model processed under timedrelational abstraction.

Ex12 ABB Corporate Research inhouse example (wind turbine yaw controller; details restricted).

Ex13 ABB Corporate Research inhouse example (tide gate controller; details restricted).

AS Assumption generation. We use commonly seen examples (e.g., from Lily [11]) to demonstrate the use of assumption generation. G4LTLST fails to synthesize controllers for these examples under the unroll depth 3 (some problems are realizable when increasing the unroll depth), but under this feature G4LTLST simple continues the synthesis process and discovers appropriate assumptions.
Appendix C LTL Synthesis Engine
In this section, we formulate required definitions the implemented algorithms for LTL synthesis.
Linear Temporal Logic (LTL)
Given two disjoint set of atomic propositions and , the LTL formulas over are defined inductively:

is an LTL formula.

If are LTLformulas, then so are , , , , .

If are LTLformulas, then so are , , , .
Given an word and a natural number , the semantics of LTL is defined as follows.

iff .

iff not . Similar definitions follow for other logic operators , and . We use interchangeably and !.

iff for all : .

iff for some : .

iff .

iff for some : , and for all : .
automaton
A nondeterministic Büchi word (NBW) automaton over is a finite automaton , where is the set of states, is the initial state, is the set of final states, and is the transition relation. A run on an input word where , is a sequence over states in such that (1) and (2) for all : . accepts if there exists a run such that for infinitely many . A universal coBüchi word (UCW) automaton follows the above notation, but only accepts if for every run , for only finitely many .
From LTL to automaton
It is known that for every LTL formula , there exists an equivalent Büchi automaton representation , such that a word satisfies iff there exists an accepting run in on (algorithms can be found in, e.g., [9, 10]). Figure 3 shows some simple LTL formulas and the corresponding Büchi automata. Final states are with double circles. For the ease of understanding, in the graphical representation we fold many edges having the same source and destination into one, and represent these edges as a logic formula on the edge label. E.g., req in Figure 3 actually represents the set .
Edgelabeled game
A labeledgame arena has the form , where is the set of locations, is the set of control locations, is the transition relation, is the initial location. is a labeling function mapping from each transition with source in to , and each transition with source in to . Such a graph is partitioned into two areas and (environment locations). A play is a sequence with which is built up based on player selections: if then control (player0) decides the next location, and if then environment (player1) decides the next location.
A strategy for control is a function which allocates a play prefix , a set of vertices such that , for all . A strategy is winning for control at location , if any play starting from following satisfies the winning condition. In this paper we only use safety condition:

Safety condition: a play is safety winning if , where is the set of risk states, and refers to the set of locations that appears in .
c.1 LTL Synthesis
Given a set of input and output variables and , together with an LTL formula on and . Let be the corresponding Büchi automaton of . The LTL synthesis problem (where the environment takes the first move) asks the existence of a controller such that, for every input sequence , where :

Given the prefix produce .

Given the prefix , produce .

The produced output sequence ensures that the word , where , creates an accepting run of .
Equivalently, we can adapt the same definition by applying it to UCW, i.e., given , the controller should only allow the all runs created by produced word to visit the its final states only finitely often. Such a definition will be used later in bounded synthesis via safety games.
(Example) Consider the specification . Based on our definition, any controller which outputs the same value as input in the first inputoutput cycle is considered to be a feasible solution.
c.2 LTL Synthesis via UCW and Boundedunroll Safety Games
Given the LTL specification , the roadmap of our method is to first construct the Büchi word automaton , and view it as an UCW, i.e., if an word can visit final states of only finitely often on every run, is an word of . Again assume that the construction of is provided.
c.2.1 Creating Gamelike Representations
\@dblfloatalgocf[t] \end@dblfloat
The first step, after creating , is to apply Algorithm 1 to create a game representation . Consider again the synthesis process of . Figure 4 (a) and (b) show the corresponding and the translated game. A controller will, for every input sequence, produce the corresponding output sequence to ensure that all paths in the generated game will visit final states in only finitely often. Not difficultly, we can observe a solution highlighted at Figure 4 (b), which outputs grant at (i.e., when input equals req) and outputs grant or !grant at (i.e., when input equals !req). Outputting grant at ensures that is never visited from the initial state.
c.2.2 Bounded Unroll into Safety Games
Once when the game representation of is generated, we then perform a bounded unroll by exploring all finite words of size defined in to create a safety game. For all vertices whose descendants are not fully expanded, we consider them to be risk states. We define equivalence relation which enables to treat the two different vertices as the same one. By doing so, the unfolding in general does not create an arena with a tree structure but rather an arena with loops.
Given with final states provided by Algorithm 1, a node (i.e., an equivalence class) in the translated safety game uses a set as its identifier, where is the last visited vertex and is the number of visited times for final state , for a finite word whose corresponding state sequence ends at . Algorithm LABEL:algo.game.unroll shows a worklist algorithm which performs bounded unroll to create a new safety game.
The worklist algorithm first pushes the initial state into the list (line 1,2). Then it continuously removes elements in the list to perform the expansion. As each state is associated with a number when it is placed in the worklist (line 2,5,9) and will not produce new elements to the list when the value exceeds , the algorithm guarantees termination. If the element taken from the list is an environment vertex, then new vertices are created based on all possible input values (line 4). Otherwise, the algorithm considers, given an output valuation out, what are all possible successor states (line 6, 7). In line 7, for the ease of understanding, we use the following functions.

updates by , if in the list representation of , the index of equals . It is also used in line 1, i.e., if the initial state is a final state, then the value should start with rather than .

Given , the operation replaces in by . For example we derive . Originally, having two elements and means that to visit , there exists two runs where the first traverses the first final state and the other traverses the second final state. We do not maintain two separate information but rather use an overapproximation. It is the reason why our method is called mergeoverallpaths, as such a technique is borrowed from static analysis in program verification.
Therefore, in line 7, when the state is updated from to , at first the algorithm produces . Then it uses function to update the number of visited final states considering . Then it uses to merge the result of newly computed to existing results. Line 8 checks if there exists a vertex in which has the same value of succ (using ). If such a vertex exists, then connect all outgoing edges to the existed vertex rather than succ.
(Example) Consider the following specification: , which specifies that when a request arrives, a grant should be issued true immediately or with at most one unit delay. However, it is disallowed to issue to consecutive grants. Figure 5 shows the Büchi automaton of the complement specification . Two paths (1) and (2) reflect the erroneous scenario where in (1) a request is not granted in time, and in (2) there are two consecutive grants. Let . Figure 6 shows the result of unrolled safety game. starts with initial state , and it has not visited any final state. Therefore the algorithm creates vertex and add to the worklist (line 1). Then the algorithm creates and , reflecting different input values (line 4). can move to via grant when receiving input req. Therefore, we link to a new environment vertex , where denotes that final state has been reached once (recall that is the second element in , so changes to after update()). For and , given any input, if output equals !grant, cannot proceed while can move to or . Therefore, by responding !grant, and will move to . In this example, an unroll of depth is sufficient to create a controller.