Numerical LTL Synthesis for CyberPhysical Systems
(WorkinProgress Report)
Abstract
Submitted to: © ChihHong Cheng, Edward A. Lee This work is licensed under the Creative Commons Attribution License.
Numerical LTL Synthesis for CyberPhysical Systems
(WorkinProgress Report)
ChihHong Cheng \IfArrayPackageLoaded  





cheng@fortiss.org and Edward A. Lee \IfArrayPackageLoaded  




eal@eecs.berkeley.edu 
1 Overview
Cyberphysical systems (CPS) are integrations of computation with physical processes, where computing machineries monitor and interact with the physical world via sensors and actuators. In such a system, the reading of a sensor represents measurements of a physical quantity, and the values are often reals ranged over bounded intervals. The implementation of control laws is based on nonlinear numerical computations over the received sensor values. Synthesizing controllers fulfilling features within CPS brings a huge challenge to the research community in formal methods, as most of the work in automatic controller synthesis (LTL synthesis) is designed to handle specifications having inputs within the Boolean domain [10, 14, 7, 3].
In this report, we present a novel approach that addresses the above challenge to synthesize controllers for CPS. Our core methodology, called numerical LTL synthesis, extends LTL synthesis [12] by using inputs or outputs in real numbers and by allowing predicates of polynomial constraints to be defined within an LTL formula as a specification. The synthesis algorithm is based on an interplay between an LTL synthesis engine that handles the pseudoBoolean structure, together with a nonlinear constraint validity checker that tests the (in)feasibility of a (counter)strategy. The methodology is integrated within the CPS research framework Ptolemy II [8] via the development of an LTL synthesis module G4LTL [1] and a validity checker JBernstein [4]. Although we only target the theory of nonlinear real arithmetic, the use of pseudoBoolean synthesis framework also allows an easy extension to embed a richer set of theories, making the technique applicable to a much broader audience.
2 Numerical LTL Synthesis
2.1 Understanding Numerical LTL Synthesis
We use an example to illustrate key ingredients of numerical LTL synthesis, including the specification methodology and the algorithmic interplay between the pseudoBoolean LTL synthesizer and the theory solver.
Specification.
Consider a reactive system where in each reactive cycle, sensor readings are updated. In this system, two variables are used to store the sensor values in each cycle. The system has two clients Client1 and Client2. Client1 issues a request when holds, while Client2 issues a request when holds. Our goal is to design a controller that grants a client in the next round whenever he requests. However, as the resource is unique, it is disallowed to grant the resource simultaneously to two clients in each cycle. When we use two Boolean variables grant1, grant2 to represent the issuing of the resource in each round, we can describe the specification of a correct controller formally using the following “extended” LTL formula, where G, F and X are temporal operators [11] representing “always,” “eventually” and “next”.
(1) 
PseudoBoolean specification synthesis.
The implemented numerical LTL synthesis algorithm interleaves between the pseudoBoolean level and the theory level. First, rewrite and as predicates req1 and req2. View req1 and req2 as independent input variables, then we have created the following pseudoBoolean specification.
(2) 
In the original specification, valuations of and are interrelated, but req1 and req2 in the new specification are independent input variables. Therefore, the pseudoBoolean specification overapproximates the capability of the environment.
When an LTL synthesis engine analyzes Eq. 2, it reports the unrealizability of the specification. The counterstrategy (i.e., reason of unrealizability) can be understood by a simple input pattern , as when both req1 and req2 are true, a controller needs to assign grant1 and grant2 to be true in the next round. This violates the third conjuncted invariance condition .
Counterstrategy validation (theory level).
Given a counterstrategy on the pseudoBoolean level, one needs to check whether such a strategy is indeed possible. In this example, it is equivalent to check whether it is possible to have and true simultaneously, given . We use a validity checker to examine the negated constraint , or equivalently:
(3) 
Such an assumeguarantee style constraint can be checked automatically by the solver JBernstein. In this example, JBernstein returns true, implying that this counterstrategy is spurious. If all pseudoBoolean input patterns in the counterstrategy are realizable on the theory level, then the counterstrategy is genuine.
Specification refinement and resynthesis (pseudoBoolean level).
As the input pattern (true, true) can never appear, the subsequent step on the pseudoBoolean level is to perform specification refinement. To rule out (true, true), one adds an assumption to the original specification.
(4) 
By posing this assumption and rerunning the LTL synthesis engine, the engine reports the existence of a solution: if any one of req1 () and req2 () is true, grant the corresponding client in the next round.
2.2 Workflow
The whole workflow for numerical LTL synthesis is illustrated in Fig. 1. The input of the workflow contains LTL(Th), the extended LTL formula where Th is the underlying theory. For the presented example, Th is the theory of nonlinear real arithmetic. The workflow first creates the pseudoBoolean specification via the Abstract module, then the pseudoBoolean specification is fed into the LTL controller synthesis engine. If the engine finds a controller , then the workflow stops and reports realizability. Otherwise, the workflow generates , the counterstrategy for the environment to act as a spoiler^{1}^{1}1LTL synthesis is known to be determined: If one can not find a controller realizing the LTL specification, there exists a counterstrategy for the environment..
Given , the Extract module extracts a compact strategy that uses fewer pseudoBoolean input valuations whose validity are not proven on the theory level. It then passes these unproven input valuations to the theory checker. In the previous example, the Extract module generates a counterstrategy that only uses , and . Given , the theory checker checks whether any element in is not realizable. If all of them are realizable, then the counterstrategy is genuine and the workflow stops by reporting the unrealizability of the specification. Otherwise, whenever the theory checker detects one input combination that is not realizable, is used to refine the pseudoBoolean specification. The refinement is demonstrated in the Refine module, and the refined specification is fed again to the LTL synthesis engine. For the set of pseudoBoolean input combinations that are proven to be realizable by the theory checker, it is stored within the Memorize module as elements in (initially, ), so that later in the input extraction process, module Extract does not place any element inside and avoids duplicate checking on the theory level.
Our proposed algorithm can be viewed as analogous to the counterexample guided abstraction refinement (CEGAR) techniques [6] applied in program verification. An intuitive method to replace the above procedure is to check whether all possible input combinations are possible within the theory level. However, this can be overly expensive, as given pseudoBoolean input variables, one needs to perform validity checking of nonlinear constraints for times. Our counterexample guided technique is superior, as demonstrated in the previous example, it is sufficient to trigger the validity checking once rather than four times. Also, given the infeasibility of a certain input vector on the pseudoBoolean level, it is impossible to have a counterstrategy that reuses this input vector, as this makes the specification trivially true. Together with the use of the Memorize module, the workflow guarantees that every input vector on the pseudoBoolean level is checked for its validity at most once.
2.3 Duality between Inputs and Outputs
Clearly, the above problem formulation and workflow are simplified, as they only consider output variables within the Boolean domain. The methodology can be naturally extended so that the every output variable is also replaced by a polynomial constraint^{2}^{2}2Here we pose a restriction on each polynomial constraint such that it can not be mixed with both input and output variables. Without the restriction, in the implementation one needs an analysis tool for existsforall formulas.. In this way, even if a controller is successfully synthesized on the pseudoBoolean level, one still needs to check whether every output of is realizable, similar to the above input validation process for counterstrategies. For pseudoBoolean outputs, the refinement of unrealizability is to add new constraints as guarantees in the pseudoBoolean specification. E.g., let grant1 and grant2 be output predicates on the pseudoBoolean level. If we derive that grant1 and grant2 can not appear true simultaneously as a fact from the theory level, add to refine the pseudoBoolean specification.
3 Towards an Optimized Implementation in Ptolemy II
In this section, we outline how we integrate the presented numerical LTL synthesis technique into Ptolemy II. Ptolemy II is an open source CPS research framework which is implemented in Java and supports easy installation and execution in most operating systems. To achieve seamless integration, the accomplishment of this work involves the development of two independent modules G4LTL and JBernstein.
3.1 G4ltl
G4LTL is the engine that performs (pseudoBoolean) LTL synthesis. G4LTL implements two (incomplete) algorithms for synthesizing controllers. The first algorithm translates the corresponding Büchi automaton of a given specification to a Büchi game and generates the controller via Büchi game solving. The second algorithm parses the Büchi automaton of the negated specification, constructs a safety game via bounded unroll, and generates the controller via safety game solving. Ptolemy II uses actororiented programming techniques, and each actor can be viewed as a function that takes input tokens and produces output tokens. The engine is designed to allow the environment to start the first move; i.e., no output is generated if no input is provided^{3}^{3}3This readinputproduceoutput view is common within the signals and systems community.. G4LTL uses two Javabased libraries LTL2Buchi [9] and JDD [2], where LTL2Buchi is used for converting an LTL specification into its corresponding Büchi automaton, and JDD is used for solving safety and Büchi games symbolically.
G4LTL also implements a new feature to automatically rewrite an LTL specification before synthesis (as a preprocessing step), so that the use of variables can be reduced. This idea was sketched in our earlier technical report [5], and G4LTL is the first tool that realizes this feature for LTL synthesis. The workflow first synthesizes a controller realizing the rewritten specification (thus the synthesis speed can be exponentially faster than doing synthesis on the original specification), followed by automatically producing the signal multiplexer that translates a signal to the original one. The idea is illustrated in the example in Figure 2. For the specification above, G4LTL automatically detects that one can reencode the output signals, as only 4 output combinations are possible. Therefore, it is sufficient to perform synthesis with two output variables. The system integrated with the synthesized modules is shown in Figure 3, where model1 is an FSMActor realizing the translated specification, and OutMultiplexer performs signal translation. The integration into Ptolemy II makes the visualization and simulation easy. In this model, once when links are established, within the simulation the light signal demonstrates whether a certain variable is set to true. In Figure 3, although an error appears, as the operator is also present, the controller can still grant the third client by setting variable grant3 to be true.
3.2 JBernstein
JBernstein is the engine that handles the validation of (counter)strategies. JBernstein implements the validity checking process via the use of Bernstein polynomials. The process contains three steps: range transformation, basis transformation, and subspace refinement to recursively derive more precise bounds. As during the design process, we were unable to use software packages like GNU Multiple Precision Arithmetic Library in C or C++ which can guarantee precision by representing every rational number with two integer values (e.g., represent by ), JBernstein uses double but conservatively estimates the maximum possible error due to the use of double. In this way, JBernstein only proves or disproves the validity on a strengthened property (by considering errors) and can also return unknown. We have used JBernstein to evaluate examples within the NASA PVS benchmark suite. JBernstein outperforms existing tools on complicated examples, while the strengthening is still precise enough to provide answer for all problems.
3.3 Integration
Constructing pseudoBoolean game graphs only once.
Our presented algorithm is based on an assumption where we view the synthesis engine and the validity checker as two black boxes. In the implementation, the algorithm can be further improved as we have full control to modify the LTL synthesis engine. Recall in each refinement step caused by the spurious counterstrategy, the algorithm removes the ability of the environment by disallowing some input combinations. It is equivalent to the removal of environment edges in the generated game for the original pseudoBoolean specification. Therefore, during the integration process, one can modify the internal data structure for games in G4LTL that marks an edge to be present or absent (due to the removal). This process avoids the repeated construction of game arenas from pseudoBoolean LTL specifications^{4}^{4}4The use of CEGAR is an attempt to reduce the number of checks in for the theory solver, as validity checking for nonlinear constraints over reals is very time consuming. However, for the unoptimized method the cost of reducing checks for the theory solver is transferred to the check of realizability for pseudoBoolean LTL specifications, as every refinement requires to trigger the LTL synthesis engine once..
Implementing the Extract module.
The counterstrategy generation process within the pseudoBoolean LTL synthesis engine plays an important role for numerical LTL synthesis. To apply CEGAR techniques, the engine needs to generate a strategy that minimizes the use of input assignments that are not checked on the theory level (otherwise, the validation can be overly timeconsuming). In the presented counterstrategy, a state may have multiple outgoing edges. If only one edge is chosen for every state in the counterstrategy, it is still a counterstrategy. Therefore, the Extract module first tries to pick for every state in an edge whose input element is in . If this is possible, then the counterstrategy is genuine. Otherwise, perform a greedybased approach to cover every state with an edge while maintaining the least use of input assignments that are not checked on the theory level. For the example presented in this paper, G4LTL is able to identify a counterstrategy (from the generated arena) that merely uses .
Using the tool.
To use numerical LTL synthesis in Ptolemy II, currently a user must provide the pseudoBoolean specification (for G4LTL), together with polynomial constraint template where each abstract variable is set to true (for JBernstein; JBernstein will automatically parse the template and concretize based on the actual input variable assignment). The output (whenever a controller exists) is automatically created as an FSMActor component in a design canvas. One can open and see the concrete implementation, link it with other components to complete the design, or even use the codegeneration framework within Ptolemy II to deploy the synthesized module as executable C program on dedicated platforms in cyberphysical systems.
Figure 4 shows a Synchronous Dataflow (SDF) model describing the scenario presented in this paper, together with the synthesized controller (named model1). The Purse actor is used to generate reactive runs, and the value of sensor Sensor:X and Sensor:Y are generated at random with a uniform distribution. After data processing, the value of is fed into the input port req1 of the synthesized FSMActor, while is fed into the input port req2. Inputs and outputs from the FSMActor are connected to a console to show the result of simulation. The FSMActor starts with state 5. Whenever an input (true, true) is provided, the specification holds and the execution moves to state 0. State 7 means that there is a pending grant to be issued for client 2; all outgoing edges (except the one to state 0) set grant2 to true. Analogously, state 9 implies a pending grant to be issued for client 1.
Another example with 3 sensors.
Consider another example where two clients make their requests based on the reading of three sensor values ranging within . Client 1 requests when , while client 2 requests when . The solver detects that there exists a genuine counterstrategy by assigning to be . Under this assignment, and .
4 Concluding Remarks and Discussion
Availability.
Currently the tool is within the development version^{5}^{5}5Visit http://chess.eecs.berkeley.edu/ptexternal/ to download the experimental version and follow the instructions to execute examples demonstrated in this paper.^{6}^{6}6The G4LTL module in Ptolemy II only employs the basic synthesis engine without optimization. The fortiss institute has developed an alternative (academic free) version that contains techniques presented in this paper and the synthesis speed is much faster. of Ptolemy II and is still under active development. Part of the features will be made public in the release of Ptolemy II version 9.0. Users can also download separately G4LTL and JBernstein to experiment the counterexample guided synthesis process manually.
Contribution.
We conclude this report by summarizing our main contributions.

The proposition of numerical LTL synthesis as a novel way to synthesize controllers for cyberphysical systems.

The proposition of a CEGARbased algorithm for numerical LTL synthesis, which involves the interplay between an LTL synthesizer and a (nonlinear real arithmetic) theory checker.

An implementation within the componentbased design tool Ptolemy II that makes both normal and numerical LTL synthesis within the formal method community more approachable to a broader audience.
Discussion.
LTL synthesis has been criticized concerning its practicability for two reasons.

It is very difficult to describe the system specification in full.

For full LTL synthesis, existing technologies commonly fails to scale with more than 10 input and 10 output variables.
Nevertheless, within the context of blockbased languages such as Ptolemy II, one can discover that a system is hardly monolithic but rather composed by several blocks. Each block should be functionally isolated and implements a very specific feature. It turns out that it is highly uncommon to have the number of input and output ports within a block to be excessively high^{7}^{7}7Observe Fig. 3, where for the FSMActor model1, using 5 inputs already occupies the left edge of the block completely.. Therefore, complete specification on the block level should be considered as possible. We believe that understanding the feasibility on blockbased languages while probing further in numerical aspects of control will make synthesis techniques very useful to the CPS community.
For subsequent work, we plan to extend the technique to use it within the project iCyPhy (industrial cyberphysical systems)^{8}^{8}8iCyPhy: http://www.icyphy.org/ to synthesize overvoltage protection units for electric power systems.
Capturing system dynamics.
For the previous workflow, the validity checking only checks whether a certain pseudoBoolean input combination is possible on the theory level. For system dynamics captured by an equational system, checking if a counterstrategy is valid also involves a checking whether two (or more) consecutive pseudoBoolean input valuations are realizable in the theory level.
We also plan to adapt the technique called relational abstraction [13, 15, 16]. Given a time frame , relational abstraction enables to create a sound approximation concerning relations between inputs for time and , for all time . With relational abstraction, our counterstrategy validation process also needs to examine whether all consecutive pseudoBoolean inputs in the counterstrategy is realizable by being contained inside the relational abstraction. If it is impossible to have and as two consecutive pseudoBoolean inputs, then in the refinement process, one does not add a state invariant (as in Figure 1) but an invariant similar in the following form
(5) 
to act as an assumption on the environment.
(Acknowledgement) We thank Christopher Brooks (UC Berkeley) for his supports during the tool integration, and Harald Ruess (fortiss GmbH) for his initial feedback over this work.
References
 [1] The G4LTL project. http://sourceforge.net/projects/g4ltl/.
 [2] The JDD project. http://javaddlib.sourceforge.net/jdd/.
 [3] A. Bohy, V. Bruyère, E. Filiot, J. Nayong, and J. F. Raskin. Acacia+, a tool for LTL synthesis. In CAV, volume 7358 of LNCS, pages 652–657. SpringerVerlag, 2007.
 [4] C.H. Cheng, H. Ruess, and N. Shankar. JBernstein: A validity checker for generalized polynomial constraints. In CAV, LNCS. Springer, 2013, to appear.
 [5] C.H. Cheng, B. Jobstmann, M. Geisinger, S. DiotGirald, A. Knoll, C. Buckl, and H. Ruess. Optimizations for Gamebased Synthesis. In Verimag Annual Technical Report, 2011(12).
 [6] E. Clarke, O. Grumberg, S. Jha, Y. Lu, and H. Veith. Counterexampleguided abstraction refinement. In CAV, volume 1855 of LNCS, pages 154–169. SpringerVerlag, 2007.
 [7] Rüdiger Ehlers. Unbeast: Symbolic Bounded Synthesis. In TACAS, volume 6605 of LNCS, pages 272–275. SpringerVerlag, 2011.
 [8] J. Eker, J. W. Janneck, E. A. Lee, J. Liu, X. Liu, J. Ludvig, S. Neuendorffer, S. Sachs, and Y. Xiong. Taming heterogeneitythe Ptolemy approach. Proceedings of the IEEE, 91(1):127–144, 2003.
 [9] 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.
 [10] B. Jobstmann and R. Bloem. Optimizations for LTL synthesis. In FMCAD, pages 117–124. IEEE, 2006.
 [11] A. Pnueli. The temporal logic of programs. In FOCS, pages 46–57. ACM, 1977.
 [12] A. Pnueli and R. Rosner. On the synthesis of a reactive module. In POPL, pages 179–190. ACM, 1989.
 [13] S. Sankaranarayanan and A. Tiwari. Relational abstractions for continuous and hybrid systems. In CAV, volume 6806 of LNCS, pages 686–702, Springer, 2011.
 [14] S. Schewe and B. Finkbeiner. Bounded synthesis. In ATVA, volume 4762 of LNCS, pages 474–488. SpringerVerlag, 2007.
 [15] A. Tiwari. Hybridsal relational abstracter. In CAV, volume 7358 of LNCS, pages 725–731. Springer, 2012.
 [16] A. Zutshi, S. Sankaranarayanan, and A. Tiwari. Timed relational abstractions for sampled data control systems. In CAV, volume 7358 of LNCS, pages 343–361. Springer, 2012.