G4ltl-St: Automatic Generation of PLC Programs
G4LTL-ST automatically synthesizes control code for industrial Programmable Logic Controls (PLC) from timed behavioral specifications of input-output signals. These specifications are expressed in a linear temporal logic (LTL) extended with non-linear arithmetic constraints and timing constraints on signals. G4LTL-ST generates code in IEC 61131-3-compatible Structured Text, which is compiled into executable code for a large number of industrial field-level devices. The synthesis algorithm of G4LTL-ST implements pseudo-Boolean abstraction of data constraints and the compilation of timing constraints into LTL, together with a counterstrategy-guided abstraction-refinement synthesis loop. Since temporal logic specifications are notoriously difficult to use in practice, G4LTL-ST 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 generation
Programmable Logic Controllers (PLC) are ubiquitous in the manufacturing and processing industries for realizing real-time 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 user-defined 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 61131-3 norm are the industry standard for programming PLCs . Programming in these rather low-level 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 .
With this motivation in mind, we developed the synthesis engine G4LTL-ST for generating IEC 61131-3-compatible Structured Text programs from behavioral specifications. Specifications of industrial control problems are expressed in a suitable extension of linear temporal logic (LTL) . The well-known 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 G4LTL-ST may also include
non-linear arithmetic constraints for specifying non-linear constraints on real-valued inputs;
timing constraints based on timer constructs specified in IEC 61131-3.
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 G4LTL-ST 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 G4LTL-ST 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 transition-style 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 G4LTL-ST 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 controller111Appendex 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 input-output traces satisfy the given specification. Notably, arithmetic constraints and timers are viewed as theories and thus abstracted into a pseudo-Boolean LTL formula. This enables G4LTL-ST to utilize CEGAR-like [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, G4LTL-ST 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 G4LTL-ST uses built-in 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, , RE-2 on page 44). The synthesis engine G4LTL-ST is planned to be an integral part of a complete development tool chain towards meeting these challenges. G4LTL-ST is written in Java and is available(under the GPLv3 open source license) at
In the following we provide an overview of the main features of G4LTL-ST including Pseudo-Boolean abstractions of timing constraints, the abstraction-refinement synthesis loop underlying G4LTL-ST and its implementation, and, finally, the template-based generation for suggesting new constraints of the behavior of the environment for making the control synthesis problem realizable. These features of G4LTL-ST are usually only illustrated by means of examples, but the initiated reader should be able to fill in missing technical details.
|Real-time 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 time-out 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 61131-3 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 61131-3. The additional output variable t1.start starts the timer t1, and the additional input variable t1.expire receives a time-out 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 time-out exactly after 10 seconds, however, the precise expected behavior of the time-out environment is over-approximated.
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, time-out signals t1.expire are simply replaced with the variable t1.Q of the IEC 61131-3 timing construct.
In Table 1 we describe some frequently encountered specification patterns and their translations using IEC 61131-3-like timing constructs. Each of these patterns requires the introduction of a fresh timer variable t1 together with the assumption on the environment providing time-outs. These specification patterns, however, are not part of the G4LTL-ST input language, since there is no special support in the synthesis engine for these language constructs, and G4LTL-ST is intended to be used in integrated development frameworks, which usually come with their own specification languages.
3 Abstraction-Refinement Synthesis Loop
The input to the synthesis engine of G4LTL-ST are LTL formulas with non-linear arithmetic constraints with bounded real (or rational) variables, and the workflow of this engine is depicted in Figure 2. Notice, however, that the abstraction-refinement 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 over-approximation 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 pseudo-Boolean specification
Clearly, this pseudo-Boolean specification with input variables req1 and req2 over-approximates the behavior of the environment, since it does not account for inter-relationships of the arithmetic input constraints.
In the next step, LTL controller synthesis checks whether or not the pseudo-Boolean 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 counter-strategy, say , for defeating the controller’s purpose is generated.
The pseudo-Boolean specification (1), for example, is unrealizable. A candidate counter-strategy 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 counter-strategies with fewer pseudo-Boolean input valuations (via a greedy-based method) whose validity are not proven at the theory level. Consequently, the Extract module generates a candidate counter-strategy that only uses and the input valuations are passed to the Theory Checker.
A candidate counter-strategy is a genuine counter-strategy only if all pseudo-Boolean input patterns are satisfiable at the theory level; in these cases the environment wins and Theory Checker reports the un-realizability 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 . G4LTL-ST uses the JBernstein  verification engine for discharging quantifier-free verification conditions involving non-linear 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.
In this way, Refine successively refines the over-approximation 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 over-approximations 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 counter-strategy, one might strengthen this initial assumption with
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 industry-standard 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 G4LTL-ST 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 G4LTL-ST is restricted to specifications with arithmetic constraints on inputs only, the abstraction-refinement 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 pseudo-Boolean specification with in, out fresh input variables for the constraints and , respectively. Now, pseudo-Boolean 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 pseudo-Boolean 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 pseudo-Boolean outputs, refinement due to un-realizability of the control synthesis problem is achieved by adding new constraints as guarantees to the pseudo-Boolean specification. For example the constraint is added to the pseudo-Boolean specification, if pseudo-Boolean outputs grant1 and grant2 are mutually exclusive at the theory level.
In this way, the abstraction-refinement synthesis loop in Figure 2 may handle arbitrary theory constraints on input and output variables as long as corresponding verification conditions in a first-order theory with one quantifier-alternation can be decided. The implementation of G4LTL-ST could easily be extended in this direction by using, for examples the verification procedure for the exists-forall fragment of non-linear arithmetic as described in . 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.
lines of spec
|Ex1||T, D||9||1.598s (comp)||110|
|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|
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. G4LTL-ST supports the generation of these assumptions from a set of given templates. For example, instantiations of the template , where ?a and ?b are meta-variables for inputs, disallows successive arrivals of an input signal ?a. For a pre-specified set of templates, G4LTL-ST performs a heuristic match of the meta-variables with input variables by analyzing possible ways of the environment to defeat the control specification.
The underlying LTL synthesis engine performs bounded unroll  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 G4LTL-ST 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 pre-defined threshold but no controller is generated, the engine stops and reports its inability to decide the given controller synthesis problem.
The synthesis engine of G4LTL-ST 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, G4LTL-ST can still provide a practical alternative to the prevailing low-level encodings of PLC programs222Short 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 G4LTL-ST together with counter-strategy-based lazy refinement are particularly effective in fighting the state explosion problem, since unnecessary unrolling (for timing) and bit-blasting (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 wide-spread deployment of G4LTL-ST 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 front-end language for high-level temporal specification of typical control problems for (networks of) PLCs needs to be developed .
-  International Electrotechnical Commission IEC 61131-3 Ed. 3.0: Programmable Controllers – Part 3: Programming languages. International Electrotechnical Commission, Geneva, Switzerland, 2013.
-  Recommendations for implementing the strategic initiative - INDUSTRIE 4.0. German National Academy of Science and Engineering (AcaTech). April, 2013.
-  Die Deutsche Normungs-Roadmap - INDUSTRIE 4.0. DKE German Commission for Electrical, Electronic & Information Technologies. December, 2013.
-  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.
-  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.
-  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.
-  C.-H. Cheng, N. Shankar, H. Ruess, and S. Bensalem. EFSMT: A Logical Framework for Cyber-Physical Systems. arXiv:1306.3456. 2013.
-  E. Clarke, O. Grumberg, S. Jha, Y. Lu, H. Veith. Counterexample-guided abstraction refinement. In CAV, volume 1855 of LNCS, pages 154–169. Springer, 2000.
-  P. Gastin and D. Oddoux. Fast LTL to Büchi automata translation. In CAV, volume 2102 of LNCS, pages 53–65. Springer-Verlag, 2001.
-  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. Springer-Verlag, 2002.
-  B. Jobstmann and R. Bloem. Optimizations for LTL synthesis. In FMCAD, pages 117–124. IEEE, 2006.
-  T. A. Henzinger, R. Jhala, and R. Majumdar. Counterexample-Guided Control. ICALP 2003: 886-902 In ICALP, volume 2719 of LNCS, pages 886–902. Springer, 2003.
-  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.
-  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.
-  A. Pnueli and R. Rosner. On the synthesis of a reactive module. In POPL, pages 179–190. ACM, 1989.
-  A. Pnueli. The temporal logic of programs. In FOCS, pages 46–57. IEEE, 1977.
-  S. Schewe and B. Finkbeiner. Bounded synthesis. In ATVA, volume 4762 of LNCS, pages 474–488. Springer-Verlag, 2007.
-  M. Senesky, G. Eirea, and T. J. Koo. Hybrid modelling and control of power electronics. In HSCC, pages 450–465. Springer, 2003.
-  A. Solar-Lezama, R. Rabbah, R. Bodík, and K. Ebcioğlu. Programming by sketching for bit-streaming programs. In PLDI, pages 281–294. ACM, 2005.
-  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 G4LTL-ST 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 user-specified 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 user-specified 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” .
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 . 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 Low-level device function synthesis. Our previous work MGSyn  synthesizes high-level orchestration code (in C++) to control each cell via OPC DA communication333http://en.wikipedia.org/wiki/OPC_Data_Access. Nevertheless, it assumes that each station (cell) should provide a set of pre-specified functions (as a library) to control low-level devices. As an experiment, we use G4LTL-ST to synthesize some these basic functions for the Pick&Place module of the FESTO modular production system444http://didacticonline.de/int-en/learning-systems/mps-the-modular-production-system/stations/pick-place-station-small-is-beautiful.htm. The combination of MGSyn and G4LTL-ST therefore completes the whole picture of automatic synthesis.
Ex9 The DC-DC boost converter circuit example . 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  extended with predicates555NOTICE: 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 timed-relational abstraction.
Ex11 Control of track system with a physical model processed under timed-relational abstraction.
Ex12 ABB Corporate Research in-house example (wind turbine yaw controller; details restricted).
Ex13 ABB Corporate Research in-house example (tide gate controller; details restricted).
AS Assumption generation. We use commonly seen examples (e.g., from Lily ) to demonstrate the use of assumption generation. G4LTL-ST 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 G4LTL-ST 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 LTL-formulas, then so are , , , , .
If are LTL-formulas, then so are , , , .
Given an -word and a natural number , the semantics of LTL is defined as follows.
iff not . Similar definitions follow for other logic operators , and . We use interchangeably and !.
iff for all : .
iff for some : .
iff for some : , and for all : .
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 co-Bü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 .
A labeled-game 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 (player-0) decides the next location, and if then environment (player-1) 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 input-output cycle is considered to be a feasible solution.
c.2 LTL Synthesis via UCW and Bounded-unroll 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 Game-like Representations\@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 merge-over-all-paths, 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.