The Refinement Calculus of Reactive Systems Toolset
 2 Citations
 5.3k Downloads
Abstract
We present the Refinement Calculus of Reactive Systems Toolset, an environment for compositional modeling and reasoning about reactive systems, built on top of Isabelle, Simulink, and Python.
1 Introduction
The Refinement Calculus of Reactive Systems (RCRS) is a compositional framework for modeling and reasoning about reactive systems. RCRS has been inspired by componentbased frameworks such as interface automata [3] and has its origins in the theory of relational interfaces [14]. The theory of RCRS has been introduced in [13] and is thoroughly described in [11].

A full implementation of RCRS in the Isabelle proof assistant [9].

A set of analysis procedures for RCRS components, implemented on top of Isabelle and collectively called the Analyzer.

A Translator of Simulink diagrams into RCRS code.

A library of basic RCRS components, including a set of basic Simulink blocks modeled in RCRS.
2 Modeling Systems in RCRS
Id models the identity function: it takes input x and returns y such that \(y=x\). Add returns the sum of its two inputs. Constant is parameterized by c, takes no input (equivalent to saying that its input variable is of type unit), and returns an output which is always equal to c. UnitDelay is a stateful component: s is the currentstate variable and s’ is the nextstate variable. SqrRoot is a noninputreceptive component: its input x is required to satisfy x\(\ge \)0. (SqrRoot may be considered nonatomic as it is defined as the serial composition of two predicate transformers – see Sect. 3.) NonDetSqrt is a nondeterministic version of SqrRoot: it returns an arbitrary (but nonnegative) y, and not necessarily the squareroot of x. ReceptiveSqrt is an inputreceptive version of SqrRoot: it accepts negative inputs, but may return an arbitrary output for such inputs. RCRS also allows to describe components using the temporal logic QLTL, an extension of LTL with quantifiers [11]. An example is component A above. A accepts an infinite input sequence of x’s, provided x is infinitely often true, and returns a (nondeterministic) output sequence which satisfies the same property.
3 The Implementation of RCRS in Isabelle
RCRS is fully implemented in the Isabelle theorem prover. The RCRS implementation currently consists of 22 Isabelle theories (.thy files), totalling 27588 lines of Isabelle code. Some of the main theories are described next.
Theory Refinement.thy (1209 lines) contains a standard implementation of refinement calculus [1]. Systems are modeled as monotonic predicate transformers [4] with a weakest precondition interpretation. Within this theory we implemented nondeterministic and deterministic update statements, assert statements, parallel composition, refinement and other operations, and proved necessary properties of these.
Theory RefinementReactive.thy (1144 lines) extends Reactive.thy to reactive systems by introducing predicates over infinite traces in addition to predicates over values, and property transformers in addition to predicate transformers [11, 13].
Theory Temporal.thy (788 lines) implements a semantic version of QLTL, where temporal operators are interpreted as predicate transformers. For example, the operator \(\Box \), when applied to the predicate on infinite traces \((x>0): (\mathtt {nat}\rightarrow \mathtt {real}) \rightarrow \mathtt {bool}\), returns another predicate on infinite traces \(\Box (x>0): (\mathtt {nat}\rightarrow \mathtt {real}) \rightarrow \mathtt {bool}\). Temporal operators have been implemented to be polymorphic in the sense that they apply to predicates over an arbitrary number of variables.
The syntax [ x\(\leadsto f\)(x) ] assumes that f is a function, whereas [: :] can be used also for relations (i.e., nondeterministic systems). Using the former instead of the latter to describe deterministic systems aids the Analyzer to perform simplifications – see Sect. 5.
Theory SimplifyRCRS.thy (2175 lines) implements several of the Analyzer’s procedures. In particular, it contains a simplification procedure which reduces composite RCRS components into atomic ones (see Sect. 5).
In addition to the above, there are several theories containing a proof of correctness of our blockdiagram translation strategies (see Sect. 4 and [10]), dealing with Simulink types [12], generating Python simulation code, and many more. A detailed description of all these theories and graphs depicting their dependencies is included in the documentation of the toolset.
The syntax of RCRS components is implemented in Isabelle using a shallow embedding [2]. This has the advantage of all datatypes and other mechanisms of Isabelle (e.g., renaming) being available for component specification, but also the disadvantage of not being able to express properties and simplifications of the RCRS language within Isabelle, as discussed in [11]. A deep embedding, in which the syntax of components is defined as a datatype of Isabelle, is possible, and is left as an open future work direction.
4 The Translator
The Translator, called simulink2isabelle, translates hierarchical block diagrams (HBDs), and in particular Simulink models, into RCRS theories [5]. The Translator (implemented in about 7100 lines of Python code) takes as input a Simulink model (.slx file) and a list of options and generates as output an Isabelle theory (.thy file). The output file contains: (1) the definition of all instances of basic blocks in the Simulink diagram (e.g., all Adders, Integrators, Constants, etc.) as atomic RCRS components; (2) the bottomup definition of all subdiagrams as composite RCRS components; (3) calls to simplification procedures; and (4) theorems stating that the resulting simplified components are equivalent to the original ones. The .thy file may also contain additional content depending on user options as explained below.
For example, when run on the Simulink diagram of Fig. 3, the Translator produces a file similar to the one shown in Fig. 4. IC_Model and FP_Model are composite RCRS components generated automatically w.r.t. two different translation strategies, implemented by user options ic and fp. The simplify_RCRS construct is explained in Sect. 5 that follows.
5 The Analyzer
The Analyzer is a set of procedures implemented on top of Isabelle and ML, the programming language of Isabelle. These procedures implement a set of functionalities such as simplification, compatibility checking, refinement checking, etc. Here we describe the main functionalities, implemented by the simplify_RCRS construct. As illustrated in Fig. 4, the general usage of this construct is simplify_RCRS "Model = C" "in" "out", where C is a (generally composite) component and in, out are (tuples of) names for its input and output variables. When such a statement is executed in Isabelle, it performs the following steps: (1) It creates the definition Model = C. (2) It expands C, meaning that it replaces all atomic components and all composition operators in C with their definitions. This results in an Isabelle expression E. E is generally a complicated expression, containing formulas with quantifiers, case expressions for tuples, function compositions, and several other operators. (3) simplify_RCRS simplifies E, by eliminating quantifiers, renaming variables, and performing several other simplifications. The simplified expression, F, is of the form {. p .} o [: r :], where p is a predicate on input variables and r is a relation on input and output variables. That is, F is an atomic RCRS component. (4) simplify_RCRS generates a theorem stating that Model is semantically equivalent to F, and also the mechanized proof of this theorem (in Isabelle). Note that the execution by the Analyzer of the .thy file generated by the Translator is fully automatic, despite the fact that Isabelle generally requires human interaction. This is thanks to the fact that the theory generated by the Translator contains all declarations (equalities, rewriting rules, etc.) neccessary for the Analyzer to produce the simplifications and their mechanical proofs, without user interaction.
If the model contains incompatibilities, where for instance the input condition of a block like SqrRoot cannot be guaranteed by the upstream diagram, the toplevel component automatically simplifies to \(\bot \) (i.e., false). Thus, in this usage scenario, RCRS can be seen as a static analysis and behavioral type checking and inference tool for Simulink.
6 Case Study
We have used the RCRS toolset on several case studies, the most significant of which is a realworld benchmark provided by Toyota [8]. The benchmark consists of a set of Simulink diagrams modeling a Fuel Control System.^{1} A typical diagram in the above suite contains 3 levels of hierarchy, 104 Simulink blocks in total (out of which 8 subsystems), and 101 wires (out of which 8 are feedbacks, the most complex composition operator in RCRS). Using the Translator on this diagram results in a .thy file of 1671 lines and 57037 characters. Translation time is negligible. The Analyzer simplifies this model to a toplevel atomic STS component with no inputs, 7 (external) outputs and 14 state variables (note that all internal wires have been automatically eliminated in this toplevel description). Simplification takes approximately 15 seconds and generates a formula which is 8337 characters long. The formula is consistent (not false), which proves statically that the original Simulink diagram has no incompatibilities. More details about the case study can be found in [5, 6].
7 Data Availability Statement
All results mentioned in this paper as well as in the extended version of this paper [6] are fully reproducible using the code, data, and instructions available in the figshare repository: https://doi.org/10.6084/m9.figshare.5900911.v1.
The figshare repository contains the full implementation of the RCRS toolset, including the formalization of RCRS in Isabelle, the Analyzer, the RCRS Simulink library, and the Translator. The figshare repository also contains sample Simulink models, including the Toyota model discussed in Sect. 6, a demo file named RCRS_Demo.thy, and detailed stepbystep instructions on how to conduct a demonstration and how to reproduce the results of this paper. Documentation on RCRS is also provided.
The figshare repository provides a snapshot of RCRS as of February 2018. Further developments of RCRS will be reflected on the RCRS web page: http://rcrs.cs.aalto.fi/.
Footnotes
 1.
We downloaded the Simulink models from https://cpsvo.org/group/ARCH/benchmarks. One of those models is made available in the figshare repository [7] – see also Section “Data Availability Statement”.
References
 1.Back, R.J., von Wright, J.: Refinement Calculus. Springer, Heidelberg (1998)CrossRefGoogle Scholar
 2.Boulton, R.J., Gordon, A., Gordon, M.J.C., Harrison, J., Herbert, J., Tassel, J.V.: Experience with embedding hardware description languages in HOL. In: IFIP TC10/WG 10.2 International Conference on Theorem Provers in Circuit Design, pp. 129–156. NorthHolland Publishing Co., Amsterdam (1992)Google Scholar
 3.de Alfaro, L., Henzinger, T.: Interface automata. In: Foundations of Software Engineering (FSE). ACM Press, New York (2001)Google Scholar
 4.Dijkstra, E.: Guarded commands, nondeterminacy and formal derivation of programs. Comm. ACM 18(8), 453–457 (1975)MathSciNetCrossRefGoogle Scholar
 5.Dragomir, I., Preoteasa, V., Tripakis, S.: Compositional semantics and analysis of hierarchical block diagrams. In: Bošnački, D., Wijs, A. (eds.) SPIN 2016. LNCS, vol. 9641, pp. 38–56. Springer, Cham (2016). https://doi.org/10.1007/9783319325828_3CrossRefGoogle Scholar
 6.Dragomir, I., Preoteasa, V., Tripakis, S.: The Refinement Calculus of Reactive Systems Toolset. CoRR, abs/1710.08195:1–12 (2017)Google Scholar
 7.Dragomir, I., Preoteasa, V., Tripakis, S.: The Refinement Calculus of Reactive Systems Toolset, February 2018. figshare. https://doi.org/10.6084/m9.figshare.5900911.v1
 8.Jin, X., Deshmukh, J.V., Kapinski, J., Ueda, K., Butts, K.: Powertrain control verification benchmark. In: Proceedings of the 17th International Conference on Hybrid Systems: Computation and Control, HSCC 2014, pp. 253–262. ACM (2014)Google Scholar
 9.Nipkow, T., Wenzel, M., Paulson, L.C. (eds.): Isabelle/HOL. LNCS, vol. 2283. Springer, Heidelberg (2002). https://doi.org/10.1007/3540459499CrossRefzbMATHGoogle Scholar
 10.Preoteasa, V., Dragomir, I., Tripakis, S.: A nondeterministic and abstract algorithm for translating hierarchical block diagrams. CoRR, abs/1611.01337 (2016)Google Scholar
 11.Preoteasa, V., Dragomir, I., Tripakis, S.: The Refinement Calculus of Reactive Systems. CoRR, abs/1710.03979 (2017)Google Scholar
 12.Preoteasa, V., Dragomir, I., Tripakis, S.: Type inference of Simulink hierarchical block diagrams in Isabelle. In: Bouajjani, A., Silva, A. (eds.) FORTE 2017. LNCS, vol. 10321, pp. 194–209. Springer, Cham (2017). https://doi.org/10.1007/9783319602257_14CrossRefGoogle Scholar
 13.Preoteasa, V., Tripakis, S.: Refinement calculus of reactive systems. In: 2014 International Conference on Embedded Software (EMSOFT), pp. 1–10, October 2014Google Scholar
 14.Tripakis, S., Lickly, B., Henzinger, T.A., Lee, E.A.: A theory of synchronous relational interfaces. ACM TOPLAS 33(4), 14:1–14:41 (2011)CrossRefGoogle Scholar
Copyright information
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the book's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.