figure a

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 component-based 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].

RCRS comes with a publicly available toolset, the RCRS toolset (Fig. 1), which consists of:

  • 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.

An extended version of this paper contains an additional six-page appendix describing a demo of the RCRS toolset [6]. The extended paper can also be found in a figshare repository [7]. The figshare repository contains all data (code and models) required to reproduce all results of this paper as well as of [6]: see Section “Data Availability Statement” for more details. The RCRS toolset can be downloaded also from the RCRS web page: http://rcrs.cs.aalto.fi/.

Fig. 1.
figure 1

The RCRS toolset.

Full size image

2 Modeling Systems in RCRS

RCRS provides a language of components to model systems in a modular fashion. Components can be either atomic or composite. Here are some examples of atomic RCRS components:

figure b

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 current-state variable and s’ is the next-state variable. SqrRoot is a non-input-receptive component: its input x is required to satisfy x\(\ge \)0. (SqrRoot may be considered non-atomic as it is defined as the serial composition of two predicate transformers – see Sect. 3.) NonDetSqrt is a non-deterministic version of SqrRoot: it returns an arbitrary (but non-negative) y, and not necessarily the square-root of x. ReceptiveSqrt is an input-receptive 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 (non-deterministic) output sequence which satisfies the same property.

Composite components are formed by composing other (atomic or composite) components using three primitive composition operators, as illustrated in Fig. 2: \(C\texttt { o }C'\) (in series) connects outputs of C to inputs of \(C'\); \(C\texttt { ** }C'\) (in parallel) “stacks” C and \(C'\) “on top of each other”; and \(\mathtt {feedback}(C)\) connects the first output of C to its first input. These operators are sufficient to express any block diagram, as described in Sect. 4.

Fig. 2.
figure 2

The three composition operators of RCRS.

Full size image

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 non-deterministic 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.

Theory Simulink.thy (873 lines) defines a subset of the basic blocks in the Simulink library as RCRS components (at the time of writing, 48 Simulink block types can be handled). In addition to discrete-time, we can handle continuous-time blocks with a fixed-step forward Euler integration scheme. For example, Simulink’s integrator block can be defined in two equivalent ways as follows:

figure c

The syntax [- x\(\leadsto f\)(x) -] assumes that f is a function, whereas [: :] can be used also for relations (i.e., non-deterministic 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 block-diagram 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 bottom-up 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.

As shown in [5], there are many possible ways to translate a block diagram into an algebra of components with the three primitive composition operators of RCRS. This means that step (2) above is not unique. simulink2isabelle implements the several translation strategies proposed in [5] as user options.

Fig. 3.
figure 3

A Simulink diagram.

Full size image

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.

Other user options to the Translator include: whether to flatten the input diagram, optional typing information for wires, and whether to generate in addition to the top-level STS component, a QLTL component representing the temporal behavior of the system. The user can also ask the Translator to generate: (1) components w.r.t. all translation strategies; (2) the corresponding theorems showing that these components are all semantically equivalent; and (3) Python simulation scripts for the top-level component.

Fig. 4.
figure 4

Auto-generated Isabelle theory for the Simulink diagram of Fig. 3

Full size image

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.

For example, when the theory in Fig. 4 is executed, the following theorem is generated and proved automatically:

figure d

where Model is either IC_Model or FP_Model. The rightmost expression is the automatically generated simplification of the top-level system to an atomic RCRS component.

If the model contains incompatibilities, where for instance the input condition of a block like SqrRoot cannot be guaranteed by the upstream diagram, the top-level 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 real-world benchmark provided by Toyota [8]. The benchmark consists of a set of Simulink diagrams modeling a Fuel Control System.Footnote 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 top-level atomic STS component with no inputs, 7 (external) outputs and 14 state variables (note that all internal wires have been automatically eliminated in this top-level 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 step-by-step 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/.