Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

autoCode4 synthesizes structured and certifiable reactive controllers from a given realizable specification in the GXW [5] subset of linear temporal logic (LTL). It is released under the LGPLv3 open source license, and can be downloaded, including a hands-on tutorial, from

http://autocode4.sourceforge.net

autoCode4 is based on structural recursion of GXW input formulas [5] for generating synchronous dataflow (SDF) [12] controllers composed from a set of actors, and for maintaining the traceability between given specifications and the generated code blocks. The underlying synthesis algorithm [5] of autoCode4 differs considerably from previous approaches and tools for reactive synthesis [4, 6, 7, 11, 14, 16, 17]. In contrast to these prevailing automata-based approaches, autoCode4 generates a reactive controller in a structured actor language with high-level behavioral constructs and synchronous dataflow communication between connected actors. This choice of generating structured controllers is motivated by the fact that a subset of SDF is compatible with the underlying model of computation for state-of-the-practice design tools including LabVIEWFootnote 1 and SCADEFootnote 2. Indeed, autoCode4 includes pre-defined code generators for Lustre/SCADE and for Ptolemy II [9], where C code or a hardware description, say, in Verilog, can be generated subsequently. Structured SDF controllers also support the integration of manually designed or legacy elements. Furthermore, the structure of the generated SDF controller is often instrumental in pinpointing and isolating problematic (e.g. realizable but demonstrating undesired behavior) specifications for validating requirements.

autoCode4 supports the necessary interfaces for integration into existing development tool chains. In this way, autoCode4 has been embedded into the Ptolemy II [9] platform for the design, simulation, and code generation of cyber-physical systems. The open interfaces of autoCode4 are suitable for realizing additional code generators for, say, Matlab SimulinkFootnote 3 or continuous function charts (IEC 61131-3). Moreover, requirement specification languages for embedded control systems, such as EARS [8], may be translated to the GXW input language of autoCode4.

autoCode4 is unique among reactive synthesis tools in that it explicitly maintains the traceability between individual requirements (as sub-specifications) and the generated controller code blocks. Such a traceability relation is mandated by current industrial standards for safety-related developments such IEC 61508 (e.g. industrial automation), DO-178C (aerospace), and ISO-26262 (automotive).

2 Structural Synthesis in a Nutshell

autoCode4 uses the GXW subset of linear temporal logic (LTL) as defined in [5] for specifying the input-output behavior of reactive controllers. This specification language supports a conjunction of input assumptions, invariance conditions on outputs, transition-like reactions of the form \(\mathbf G (\textsf {{input}} \rightarrow \mathbf X ^i \textsf {{output}})\), and reactions of the form \(\mathbf G (\textsf {{input}} \rightarrow \mathbf X ^i (\textsf {{output}}\, \mathbf W \,\textsf {{release}} ))\), where \(\textsf {{input}}\) is an LTL formula whose validity is determined by the next i input valuations (e.g. falling edge \((\textsf {{in}} \wedge \mathbf X \,\lnot \textsf {{in}})\)). The latter reaction formula states that if there is a temporal input event satisfying the constraint \(\textsf {{input}}\), then the \(\textsf {{output}}\) constraint should hold on output events until there is a \(\textsf {{release}}\) event (or \(\textsf {{output}}\) always holds).

Fig. 1.
figure 1

A hydraulic lifting platform

Full size image

The operator \(\mathbf G \) is the universal path quantifier, \(\mathbf X ^i\) abbreviates i consecutive next-steps, \(\mathbf W \) denotes the weak until temporal operator, the constraint \(\textsf {{output}}\) contains no temporal operator, and the subformula \(\textsf {{release}}\) may contain certain numbers of consecutive next-steps but no other temporal operators. Output response to input events in GXW is immediate and, whenever an event occurs the specification excludes choices of the controller to select among multiple output options (such as setting either out1 or out2 to be true).

The design of the GXW language has been guided by expressiveness, useability, and complexity considerations. We demonstrated the expressiveness of GXW by encoding of a large and rather diverse set of (Booleanized) control specifications from the domain of industrial automation [1, 2]. On the other hand, reactive synthesis for GXW is in PSPACE [5] compared to 2EXPTIME for full LTL. Moreover, the restrictions of GXW support the control designer by excluding non-causal, and commonly unrealizable, specifications, where output assignments are supposed to depend on future input values.

Structural synthesis [5] generates synchronous data flow [12] controllers from LTL specifications. Hereby, a controller is structurally composed from a set of interacting actors (behavior expressed in terms of Mealy machines). One of the main steps of the structural synthesis [5] involves checking for potentially conflicting constraints, from multiple sub-specifications, for the output assignments, and determining satisfiability of given invariance properties.

3 autoCode4 in Action

We illustrate the use of GXW by means of the simple example of controlling a hydraulic ramp as shown in Fig. 1 (cmp. with [2], Sect. 7.1.3, for similar scenarios). By pressing button i2 (up) the motor enables upward movement of the platform by setting output variable k2 to true. Button i3 (stop) stops the movement, and i1 (down) triggers the lowering of the hub by setting output variable k1 to true. Sensors i5 and i4 are used for detecting upper and lower limits. If i1 and i2 are simultaneously pressed, one needs to stop the movement. Finally, simultaneous triggering the motor in both directions (i.e., \(\mathbf G \lnot (\textsf {{k1}} \wedge \textsf {{k2}})\)) is disabled. The corresponding GXW specification is depicted in Fig. 2. Lines starting with “##” are comments, and a total of 8 GXW sub-specifications are listed. Sub-specifications are (implicitly) labeled, from top-to-bottom, by the indices 0 to 7.

Fig. 2.
figure 2

GXW specification for hydraulic lifting platform

Full size image

For the hydraulic lifting platform, Fig. 3 shows the resulting SDF controller synthesized under Ptolemy II. One may run interactive simulation or further use code generation features in Ptolemy II to automatically generate executable code in C or HDL. Due to space limits, we do not show the control structure within each block; instead we refer the reader to Fig. 4 for the corresponding Lustre implementation.

Now, we shortly comment on the requirement-to-implementation traceability using sub-specification S7: \((\lnot \textsf {{k1}} \wedge \lnot \textsf {{k2}})\mathbf W (\textsf {{i1}} \vee \textsf {{i2}})\) (the tool also allows generating a traceability report). In Fig. 3, an or-gate called event7 connects i1 and i2. The output of event7 is fed into an InUB-typed actor called Ctrl_7. The output of Ctrl_7 is negated (via Not_7k1 and Not_7k2) to influence output variables k1 and k2 respectively. One can observe that the specification index “7” can be identified in above mentioned blocks due to the naming convention.

Fig. 3.
figure 3

Control realization as Ptolemy II models

Full size image
Fig. 4.
figure 4

Control realization in Lustre format

Full size image

autoCode4 may also generate reactive controllers in Lustre [13]. Figure 4 includes the Lustre v4 code generated from controlling the hydraulic lifting platform. The requirement-to-implementation traceability is similar to the Ptolemy II graphical representation in Fig. 3. Notice that parameterized blocks such as Res5 in Fig. 4 are instantiated twice. This kind of block reuse makes textual representations of generated code (i.e., define once, instantiate multiple times) highly compact.

4 autoCode4 Software Architecture

The software architecture of autoCode4 is depicted in Fig. 5 and follows the general outline of the structural synthesis algorithm as described [5]. Input specifications are analyzed and categorized by the specification analyzer, which also rejects non-GXW specifications. In our running example, S0 and S1 are of type TrUB (when event A triggers, do B until event C). S3, S4 and S5 are categorized as IfTB (when event A triggers, do B), S7 is InUB (initially, do A until B), and lastly, S2 is an invariance property.

Subsequently, Constraint Builder builds the corresponding SDF structure (via SDF Builder), which is not fully instantiated yet, and constructs a quantified Boolean formula with one quantifier alternation (2QBF) for resolving potential conflicts between individual sub-specifications. In this process, each sub-specification is associated with a set of actors; for example, formula S7 is associated with actors such as event7 or Ctrl_7. The engine can hash a set of actors that was instantiated previously, to enable actor reuse among multiple sub-specifications. Moreover, blocks such as Res5 in Fig. 4 are used for determining an output value A if none of the sub-specifications constrain such an output.

The generated 2QBF constraint is analyzed for potential conflicts on certain output variables from different sub-specifications, and for analyzing invariance properties. These constraints are of the form: \(\exists \) \(\texttt {A}_1\),..., \(\texttt {A}_k\) \(\forall \) system state s: \(\textsf {{(Env-Assumption(s)}} \wedge \textsf {{SDF-dynamics(s)}}) \rightarrow (\textsf {{No-output-conflict(s)}} \wedge \textsf {{Invariance(s)}})\). The open design choices are determined by witnesses for the existentially-quantified variables \(\texttt {A}_1\),..., \(\texttt {A}_k\), as specified in the previous step. Informally, the body of this formula encodes the condition: if the environment assumptions hold and the system adheres to the semantics of the SDF dynamics then there is no output conflict and the specified invariance properties hold. Our 2QBF solver implements an algorithm for alternating two Boolean satisfiability solvers [10] as in SAT4J [3]. It takes the negation of the constraint above with forall-exists top-level quantification. Therefore, whenever the 2QBF solver returns false, the generated counterexample determines a non-conflicting assignment for the uninstantiated variables. Using the definition of Resk1 and Resk2 in Fig. 4 in our running example, the variable A is set to false in both cases.

The internal SDF controller is stored using the class SDFctrl, and can be traversed for generating control code in Ptolemy II, Lustre, and other SDF-based languages. Finally, autoCode4 uses the Report generator for producing a requirement-to-implementation traceability report.

Fig. 5.
figure 5

System architecture of autoCode4, where dashed elements are extension points.

Full size image