# Compositional Semantics and Analysis of Hierarchical Block Diagrams

- 12 Citations
- 626 Downloads

## Abstract

We present a compositional semantics and analysis framework for hierarchical block diagrams (HBDs) in terms of atomic and composite predicate transformers. Our framework consists of two components: (1) a compiler that translates Simulink HBDs into an algebra of transformers composed in series, in parallel, and in feedback; (2) an implementation of the theory of transformers and static analysis techniques for them in Isabelle. We evaluate our framework on several case studies including a benchmark Simulink model by Toyota.

## Keywords

Composition Operator Basic Block Parallel Composition Hybrid Automaton Serial Composition## 1 Introduction

Simulink^{1} is a widely used tool for modeling and simulating embedded control systems. Simulink uses a graphical language based on *hierarchical block diagrams* (HBDs). HBDs are networks of interconnected *blocks*, which can be either *basic* blocks from Simulink’s libraries, or *composite* blocks (*subsystems*), which are themselves HBDs. Hierarchy is the primary *modularization* mechanism that languages like Simulink offer. It allows to structure large models and thus master their complexity, improve their readability, and so on.

*compositional*semantics and analysis framework for HBDs, including but not limited to Simulink models. By “compositional” we mean exploiting the hierarchical structure of these diagrams, for instance, reasoning about individual blocks and subsystems independently, and then composing the results to reason about more complex systems. By “analysis”, we mean different types of checks, including exhaustive verification (model-checking), but also static analysis such as

*compatibility checking*, which aims to check whether the connections between two or more blocks in the diagram are valid, i.e., whether the blocks are compatible.

Our framework is based on the theories of *relational interfaces* and *refinement calculus of reactive systems* [19, 23]. The framework can express *open*, *non-deterministic*, and *non-input-receptive* systems, and both *safety* and *liveness* properties. As syntax, we use (temporal or non) logic formulas on input, output, and state variables. As semantics we use *predicate* and *property transformers* [2, 19]. To form complex systems from simpler ones we use composition in *series*, in *parallel*, and in *feedback*. Apart from standard verification (of a system against a property) the framework offers: (1) *compatibility* checking during composition; and (2) *refinement*, a binary relation between components, which characterizes *substitutability* (when can a component replace another one while preserving system properties). Compatibility checking is very useful, as it offers a lightweight alternative to verification, akin to type-checking [23]. Refinement has multiple usages, including compositional and incremental design, and reusability. This makes the framework compelling for application on tools like Simulink, which have a naturally compositional hierarchical language.

In order to define the semantics of HBDs in a compositional framework, one needs to do two things. First, define the semantics of every basic block in terms of an *atomic* element of the framework. We do this by defining for each Simulink basic block a corresponding (atomic) *monotonic predicate transformer* (MPT). Second, one must define the semantics of composite diagrams. We do this by mapping such diagrams to *composite* MPTs (CPTs), i.e., MPTs composed in series, in parallel, or in feedback.

As it turns out, mapping HBDs to CPTs raises interesting problems. For example, consider the block diagram in Fig. 1a. Let \(P_A\) and \(P_B\) be transformers modeling the blocks *A* and *B* in the diagram. How should we compose \(P_A\) and \(P_B\) in order to get a transformer that represents the entire diagram? As it turns out, there are several possible options. One option is to compose first \(P_A\) and \(P_B\) in series, and then compose the result in feedback, following Fig. 1a. This results in the composite transformer \(\mathsf {feedback}_{a}(P_A \circ (P_B \mathop {\Vert }\mathsf {Id}))\), where \(\circ \) is composition in series, \(\mathop {\Vert }\) in parallel, and \(\mathsf {feedback}_x\) is feedback applied on port *x*. \(\mathsf {Id}\) is the transformer representing the identity function. *A* has two outputs and *B* only one input, therefore to connect them in series we first form the parallel composition \(P_B\mathop {\Vert }\mathsf {Id}\), which represents a system with two inputs.

Another option is to compose the blocks in series in the opposite order, \(P_B\) followed by \(P_A\), and then apply feedback. This results in the transformer \(\mathsf {feedback}_{c}((P_B \mathop {\Vert }\mathsf {Id}) \circ P_A)\). A third option is to compose the two blocks first in parallel, and then apply feedback on the two ports *a*, *c*. This results in the transformer \(\mathsf {feedback}_{a,c}(P_A \mathop {\Vert }P_B)\). Although semantically equivalent, these three transformers have different computational properties.

Clearly, for complex diagrams, there are many possible translation options. A main contribution of this paper is the study of these options in depth. Specifically, we present three different translation strategies: *feedback-parallel* translation which forms the parallel composition of all blocks, and then applies feedback; *incremental* translation which orders blocks topologically and composes them one by one; and *feedbackless* translation, which avoids feedback composition altogether, provided the original block diagram has no algebraic loops.

Having defined the compositional semantics of HBDs in terms of CPTs, we turn to analysis. Our main focus in this paper is checking diagram *compatibility*, which roughly speaking means that the input requirements of every block in the diagram are satisfied [19, 23]. We check compatibility by (1) *expanding* the definitions of CPTs to obtain an atomic MPT; (2) *simplifying* the formulas in the atomic MPT; and (3) checking satisfiability of the resulting formulas.

We report on a toolset which implements the framework described above. The toolset consists of (1) the simulink2isabelle compiler which translates hierarchical Simulink models into CPTs implemented in the Isabelle proof assistant^{2}, and (2) the implementation of the theory of CPTs, together with expansion and simplification techniques in Isabelle. We evaluate our framework on several case studies, including a Fuel Control System benchmark by Toyota [10, 11].

## 2 Hierarchical Block Diagrams

A *hierarchical block diagram* (HBD) is a network of interconnected blocks.^{3} Blocks can be either *basic* blocks (from Simulink libraries), or *composite* blocks (*subsystems*). A basic block is described by: (1) a label, (2) a list of parameters, (3) a list of in- and out-ports, (4) a vector of state variables with predefined initial values (i.e., the local memory of a block) and (5) functions to compute the outputs and next state variables. The outputs are computed from the inputs, current state and parameters. State variables are updated by a function with the same arguments. Subsystems are defined by their label, list of in- and out-ports, and the list of block instances that they contain – both atomic and composite.

*n*the input at step \(n-1\). An Integrator is a continuous-time block whose output is described by a differential equation solved with numerical methods. We interpret a Simulink model as a discrete-time model (essentially an input-output state machine, possibly infinite-state) which evolves in a sequence of discrete steps. Each step has duration \(\varDelta t\), which is a parameter (user-defined or automatically computed by Simulink based on the blocks’ time rates).

**Algebraic-Loop-Free Diagrams.** In this paper we consider diagrams which are free from *algebraic loops*. By “algebraic loop” we mean a feedback loop resulting in instantaneous cyclic dependencies. More precisely, the way we define and check for algebraic loops is the following: first, we build a directed dependency graph whose nodes are the input/output ports of the diagram, and whose edges correspond to connections or to input-output dependencies within a block; second, we check whether this graph has a cycle. The class of algebraic-loop-free diagrams includes all diagrams whose feedback loops are “broken” by blocks such as Integrator or UnitDelay. The output of such blocks does not depend on their input (it only depends on their state), which prevents a cycle from forming in the dependency graph. For example, the diagram of Fig. 1 is algebraic-loop-free if the output of block *B* does not depend on its input.

But algebraic-loop-free diagrams can also be diagrams where feedback loops are not broken by Integrators or UnitDelays. An example is shown in Fig. 2. Despite the feedback loop in red, which creates an apparent dependency cycle, this diagram is algebraic-loop-free. The reason is that the Fuel Cmd Open block is the function \(\dfrac{1}{14.7}(-0.366 + 0.08979 u_7 u_3 - 0.0337 u_7 u_3^2 + 0.0001 u_7^2 u_3)\), where \(u=(u_1,u_2,...,u_7)\) is the input vector. This function only depends on variables \(u_3,u_7\) of the vector *u*, and is independent from \(u_1\), \(u_2\), \(u_4\), \(u_5\), \(u_6\). Since the output of the block does not depend on the 6th input link (i.e., \(u_6\)), the cycle is broken. Similarly, the outputs of Fuel Cmd Open Pwr and Fuel Cmd Closed are also independent from \(u_6\), which prevents the other two feedback loops from forming a cyclic dependency. This type of algebraic-loop-free pattern abounds in Simulink models found in the industry.

**Running Example.**Throughout the paper we illustrate our methods using a simple example of a counter, shown in Fig. 3. This is a hierarchical (two-level) Simulink model. The top-level diagram (Fig. 3a) contains three block instances: the step of the counter as a Constant basic block, the subsystem DelaySum, and the Scope basic block which allows to view simulation results. The subsystem DelaySum (Fig. 3b) contains a UnitDelay block instance which models the state of the counter. UnitDelay can be specified by the formula \(a = s\wedge s' = c\), where

*c*is the input,

*a*the output,

*s*the current state and \(s'\) the next state variable. We assume that

*s*is initially 0. The \(\mathsf {Add}\) block instance adds the two input values and outputs the result in the same time step: \(c=f+e\). The

*junction*after link

*a*(black dot in the figure) can be seen as a basic block duplicating (or

*splitting*) its input to its two outputs: \(f=a\wedge g=a\).

## 3 Basic Blocks as Monotonic Predicate Transformers

Monotonic predicate transformers [6] (MPTs) are an expressive formalism, used within the context of programming languages to model non-determinism, correctness (both functional correctness and termination), and refinement [2]. In this paper we show how MPTs can also be used to give semantics to HBDs. We consider basic blocks in this section, which can be given semantics in terms of *atomic* MPTs. In the next section we consider general diagrams, which can be mapped to *composite* MPTs.

### 3.1 Monotonic Predicate Transformers

A *predicate* on an arbitrary set \(\varSigma \) is a function \(q:\varSigma \rightarrow \mathsf {Bool}\). Predicate *q* can also be seen as a subset of \(\varSigma \): for \(\sigma \in \varSigma \), \(\sigma \) belongs to the subset iff \(q(\sigma )\) is true. Predicates can be ordered by the subset relation: we write \(q\le q'\) if predicate *q*, viewed as a set, is a subset of \(q'\). \(\mathsf {Pred}(\varSigma )\) denotes the set of predicates \(\varSigma \rightarrow \mathsf {Bool}\).

A *predicate transformer* is a function \(S: (\varSigma '\rightarrow \mathsf {Bool})\rightarrow (\varSigma \rightarrow \mathsf {Bool})\), or equivalently, \(S: \mathsf {Pred}(\varSigma ')\rightarrow \mathsf {Pred}(\varSigma )\). *S* takes a predicate on \(\varSigma '\) and returns a predicate on \(\varSigma \). *S* is *monotonic* if \(\forall q,q' : q\le q' \Rightarrow S(q) \le S(q')\).

Traditionally, MPTs have been used to model sequential programs using weakest precondition semantics. Given a MPT \(S: (\varSigma '\rightarrow \mathsf {Bool})\rightarrow (\varSigma \rightarrow \mathsf {Bool})\), and a predicate \(q':\varSigma '\rightarrow \mathsf {Bool}\) capturing a set of *final* states, \(S(q')\) captures the set of all *initial* states, such that if the program is started in any state in \(S(q')\), it is guaranteed to finish in some state in \(q'\). But this is not the only possible interpretation of *S*. *S* can also model input-output systems. For instance, *S* can model a *stateless* system with a single inport ranging over \(\varSigma \), and a single outport ranging over \(\varSigma '\). Given a predicate \(q'\) characterizing a set of possible *output values*, \(S(q')\) characterizes the set of all *input values* which, when fed into the system, result in the system outputting a value in \(q'\). As an example, the identity function can be modeled by the MPT \(\mathsf {Id}:\mathsf {Pred}(\varSigma )\rightarrow \mathsf {Pred}(\varSigma )\), defined by \(\mathsf {Id}(q)= q\), for any *q*.

*stateful*systems. For instance, consider the \(\mathsf {UnitDelay}\) described in Sect. 2. Let the input, output, and state variable of this system range over some domain \(\varSigma \). Then, this system can be modeled as a MPT \(S: \mathsf {Pred}(\varSigma \times \varSigma )\rightarrow \mathsf {Pred}(\varSigma \times \varSigma )\). The Cartesian product \(\varSigma \times \varSigma \) captures pairs of

*(input, current state)*or

*(output, next state)*values. Intuitively, we can think of this system as a function which takes as input (

*x*,

*s*), the input

*x*and the current state

*s*, and returns \((y,s')\), the output and the next state \(s'\), such that \(y=s\) and \(s'=x\). The MPT

*S*can then be defined as follows:

*q*and

*S*(

*q*) as sets.

Syntactically, a convenient way to specify systems is using formulas on input, output, and state variables. For example, the identity system can be specified by the formula \(y=x\), where *y* is the output variable and *x* is the input. The UnitDelay system can be specified by the formula \(y=s\wedge s'=x\). We next introduce operators which define MPTs from predicates and relations.

*assert*MPT, \(\{p\}:\mathsf {Pred}(\varSigma )\rightarrow \mathsf {Pred}(\varSigma )\), and the

*non-deterministic update*MPT, \([r]:\mathsf {Pred}(\varSigma ')\rightarrow \mathsf {Pred}(\varSigma )\), where:

*p*. It accepts only those inputs and behaves like the identity function. That is, \(\{p\}\) models a partial identity function, restricted to the domain

*p*. Transformer [

*r*] models an input-receptive but possibly non-deterministic system. Given input \(\sigma \), the system chooses non-deterministically some output \(\sigma '\) such that \(\sigma ' \in r(\sigma )\) is true. If no such \(\sigma '\) exists, then the system behaves

*miraculously*[2]. In our framework we ensure non-miraculous behavior as explained below, therefore, we do not detail further this term.

### 3.2 Semantics of Basic Blocks as Monotonic Predicate Transformers

To give semantics to basic Simulink blocks, we often combine \(\{p\}\) and [*r*] using the *serial composition* operator \(\circ \), which for predicate transformers is simply function composition. Given two MPTs \(S:\mathsf {Pred}(\varSigma _2)\rightarrow \mathsf {Pred}(\varSigma _1)\) and \(T:\mathsf {Pred}(\varSigma _3)\rightarrow \mathsf {Pred}(\varSigma _2)\), their serial composition \((S\circ T):\mathsf {Pred}(\varSigma _3)\rightarrow \mathsf {Pred}(\varSigma _1)\) is defined as \((S\circ T)(q) = S(T(q))\).

*x*,

*y*and one output

*z*, performing the division \(z = \frac{x}{y}\). We want to state that division by zero is illegal, and therefore, the block should reject any input where \(y=0\). This block can be specified as the MPT

In general, and in order to ensure non-miraculous behavior, we model non-input-receptive systems using a suitable assert transformer \(\{p\}\) such that in \(\{p\} \circ [r]\), if *p* is true for some input *x*, then there exists output *y* such that (*x*, *y*) satisfies *r*. MPTs which do not satisfy this condition are not considered in our framework. This is the case, for example, of the MPT \([\lambda (x,y), z : y \not = 0 \wedge z = \frac{x}{y}]\).

*functional update*\([f]:\mathsf {Pred}(\varSigma ')\rightarrow \mathsf {Pred}(\varSigma )\) is defined as \([\lambda \sigma ,\sigma ':\sigma '=f(\sigma )]\) and we have

*Functional predicate transformers*are of the form \(\{p\}\circ [f]\), and

*relational predicate transformers*are of the form \(\{p\}\circ [r]\), where

*p*is a predicate,

*f*is a function, and

*r*is a relation.

*Atomic predicate transformers*are either functional or relational transformers. \(\mathsf {Div}\) is a functional predicate transformer which can also be written as \(\mathsf {Div} = \{\lambda x,y: y \not = 0\}\circ [\lambda x,y : \frac{x}{y}].\)

*P*is a Boolean expression on some variables \(x_1,\ldots ,x_n\), then \(\{x_1,\ldots ,x_n:P\}\) denotes the assert transformer \(\{\lambda x_1,\ldots ,x_n:P\}\). Similarly if

*R*is a Boolean expression on variables \(x_1,\ldots ,x_n,y_1,\ldots ,y_k\) and

*F*is a tuple of expressions on variables \(x_1,\ldots ,x_n\), then \([x_1,\ldots ,x_n\leadsto y_1,\ldots ,y_k:R]\) and \([x_1,\ldots ,x_n\leadsto F]\) are notations for \([\lambda (x_1,\ldots ,x_n), (y_1,\ldots ,y_k):R]\) and \([\lambda x_1,\ldots ,x_n : F]\), respectively. With these notations the \(\mathsf {Div}\) transformer becomes:

*c*has no input, and a single output equal to

*c*. As a predicate transformer the constant block has as input the empty tuple (), and outputs the constant

*c*:

*integrator*, which computes the integral \(\int _0^x f\) of a function

*f*. Simulink uses different integration methods to simulate this block. We use the Euler method with fixed time step \( \varDelta t \) (a parameter). If

*x*is the input,

*y*the output, and

*s*the state variable of the integrator, then \(y=s\) and \(s'=s+x\cdot \varDelta t \). Therefore, the integrator can be modeled as the MPT

## 4 HBDs as Composite Predicate Transformers

### 4.1 Composite Predicate Transformers

The semantics of basic Simulink blocks is defined using monotonic predicate transformers. To give semantics to arbitrary block diagrams, we map them to *composite predicate transformers* (CPTs). CPTs are expressions over the atomic predicate transformers using *serial*, *parallel*, and *feedback* composition operators. Here we focus on how these operators instantiate on functional predicate transformers, which are sufficient for this paper. The complete formal definitions of the operators can be found in [7] and in the Isabelle theories that accompany this paper.^{4}

*x*is legal for \(S \circ T\) if

*x*is legal for

*S*and the output of

*S*,

*f*(

*x*), is legal for

*T*, i.e., \((p\wedge (p' \circ f))(x) = p(x) \wedge p'(f(x))\) is true. The output of \(S \circ T\) is \((f' \circ f)(x) = f'(f(x))\).

*x*is a legal input for

*S*and \(x'\) is a legal input for

*T*, and that the output of \(S \mathop {\Vert }T\) is the pair \((f(x),f'(x'))\).

For \(S:\mathsf {Pred}(U\times Y) \rightarrow \mathsf {Pred}(U\times X)\) as in Fig. 4a, the feedback of *S*, denoted \(\mathsf {feedback}(S):\mathsf {Pred}(Y)\rightarrow \mathsf {Pred}(X)\) is obtained by connecting output *v* to input *u* (Fig. 4b). The \(\mathsf {feedback}\) operator that we use in this paper is a simplified version of the one defined in [20]. It is specifically designed for a component *S* having the structure shown in Fig. 4c, i.e., where the first output *v* depends only on the second input *x*. We call such components *decomposable*. The result of applying feedback to a decomposable block is depicted in Fig. 4d.

*S*is a decomposable functional predicate transformer, i.e., if \(S = \{p\} \circ [u,x \leadsto f'(x),f(u,x)]\), then it can be shown that \(\mathsf {feedback}(S)\) is functional and it satisfies:

*x*is legal for the feedback if \(p(f'(x),x)\) is true, and the output for

*x*is \(f(f'(x), x)\).

*S*is guaranteed to be decomposable. However, we only know that \(S=\{p\}\circ [h]\) for some

*p*and

*h*, and we do not know what

*f*and \(f'\) are. We can compute

*f*and \(f'\) by setting \(f = snd \circ h\), \(f_0 = fst \circ h\), and \(f'(x) = f_0(u_0,x)\) for some arbitrary fixed \(u_0\), where \( fst \) and \( snd \) are the functions that select the first and second elements of a pair, respectively.

*simplified*MPTs for the entire system:

### 4.2 Translating HBDs to CPTs

As illustrated in the introduction, the mapping from HBDs to CPTs is not unique: for a given HBD, there are many possible CPTs that we could generate. Although these CPTs are semantically equivalent, they have different *simplifiability* properties (see Sects. 4.3 and 5). Therefore, the problem of how exactly to map a HBD to a CPT is interesting both from a theoretical and from a practical point of view. In this section, we describe three different translation strategies.

In what follows, we describe how a *flat* (non-hierarchical), *connected* diagram is translated. If the diagram consists of many disconnected “islands”, we can simply translate each island separately. Hierarchical diagrams are translated bottom-up: we first translate the subsystems, then their parent, and so on.

**Feedback-Parallel Translation.**The

*feedback-parallel translation*strategy (FPT) first composes all components in parallel, and then connects outputs to inputs by applying feedback operations. FPT is illustrated in Fig. 5a, for the DelaySum component of Fig. 3b. The \(\mathsf {Split}\) MPT models the junction after link

*a*.

*f*,

*c*, and

*a*, respectively (recall that \(\mathsf {feedback}\) works only on one variable at a time, the first input and first output of the argument transformer). In order to apply \(\mathsf {feedback}^3\) to the parallel composition \(\mathsf {Add} \mathop {\Vert }\mathsf {UnitDelay} \mathop {\Vert }\mathsf {Split}\), we first have to reorder its inputs and outputs, such that the variables on which the feedbacks are applied come first in matching order. This is achieved by the

*rerouting*transformers \([f,c,a,e,s \leadsto f, e, c, s, a]\) and \([c, a, s', f, g \leadsto f, c, a, s', g]\).

**Incremental Translation.** The *incremental translation* strategy (IT) composes components one by one, after having ordered them in topological order according to the dependencies in the diagram. When composing *A* with *B*, a decision procedure determines which composition operator(s) should be applied, based on dependencies between *A* and *B*. If *A* and *B* are not connected, parallel composition is applied. Otherwise, serial composition is used, possibly together with feedback if necessary.

*c*, serial composition is applied, obtaining the CPT

**Feedbackless Translation.** Simplifying a CPT which contains \(\mathsf {feedback}\) operators involves performing decomposability tests, function compositions which include variable renamings, and other computations which turn out to be resource consuming (see Sect. 5). For reasons of scalability, we would therefore like to avoid \(\mathsf {feedback}\) operators in the generated CPTs. The *feedbackless translation* strategy (NFBT) avoids \(\mathsf {feedback}\) altogether, provided the diagram is algebraic-loop-free. The key idea is that, since the diagram has no algebraic loops, we should be able to eliminate feedback and replace it with direct operations on current- and next-state variables, just like with basic blocks. In particular, we can *decompose* \(\mathsf {UnitDelay}\) into two \(\mathsf {Id}\) transformers, denoted \(\mathsf {Id}_{\mathsf {ud1}}\) and \(\mathsf {Id}_\mathsf {ud2}\): \(\mathsf {Id}_\mathsf {ud1}\) computes the next state from the input, while \(\mathsf {Id}_\mathsf {ud2}\) computes the output from the current state.

Generally, we decompose all components having multiple outputs into several components having each a single output. For each new component we keep only the inputs they depend on, as shown in Fig. 5c. Thus, the \(\mathsf {Split}\) component from Fig. 5b is also divided into two \(\mathsf {Id}\) components, denoted \(\mathsf {Id}_\mathsf {splt1}\) and \(\mathsf {Id}_\mathsf {splt2}\).

### 4.3 Simplifying CPTs and Checking Compatibility

Once a set of CPTs has been generated, they can be subjected to various static analysis and verification tasks. Currently, our toolset mainly supports static *compatibility* checks, which amount to checking whether any CPT obtained from the diagram is equivalent to the MPT \(\mathsf {Fail}= \{x:\mathsf {false}\}\). \(\mathsf {Fail}\) corresponds to an invalid component, indicating that the composition of two or more blocks in the diagram is illegal [19, 23].

Compatibility checking is not a trivial task. Two steps are performed in order to check whether a certain CPT is equivalent to \(\mathsf {Fail}\): the CPT is (1) *expanded*, and (2) *simplified*. By *expansion* we mean replacing the serial, parallel, and feedback composition operators by their definitions (2), (3), (4). As a result of expansion, the CPT is turned into an MPT of the form \(\{p\}\circ [f]\). By *simplification* we mean simplifying the formulas *p* and *f*, e.g., by eliminating internal variables.

## 5 Implementation and Evaluation

Our framework has been implemented and is publicly downloadable from http://users.ics.aalto.fi/iulia/sim2isa.shtml. The implementation consists of two components: (1) the simulink2isabelle compiler, which takes as input Simulink diagrams and translates them into CPTs, using the strategies described in Sect. 4.2; and (2) an implementation of the theory of CPTs, together with simplification strategies and static analysis checks such as compatibility checks, in the Isabelle theorem prover. In this section we present the toolset and report evaluation and analysis results on several case studies, including an industrial-grade benchmark by Toyota [10, 11].

### 5.1 Toolset

simulink2isabelle, written in Python, takes as input Simulink files in XML format and produces valid Isabelle theories that can be subjected to compatibility checking and verification. The compiler currently handles a large subset of Simulink’s blocks, including math and logical operators, continuous, discontinuous and discrete blocks, as well as sources, sinks, and subsystems (including enabled and switch case action subsystems). This subset is enough to express industrial-grade models such as the Toyota benchmarks.

During the parsing and preprocessing phase of the input Simulink file, the tool performs a set of checks, including algebraic loop detection, unsupported blocks and/or block parameters, malformed blocks (e.g., a function block referring to a nonexistent input), etc., and issues possible warnings/errors.

simulink2isabelle implements all three translation strategies as options -fp, -ic and -nfb, and also takes two additional options: -flat (flatten diagram) and -io (intermediate outputs, applicable to -ic). All options apply to any Simulink model. Option flat flattens the hierarchy of the HBD and produces a single diagram consisting only of basic blocks (no subsystems), on which the translation is then applied. Option io generates and names all intermediate CPTs produced during the translation process. These names are then used in the CPT for the top-level system, to make it shorter and more readable. In addition, the intermediate CPTs can be expanded and simplified incrementally by Isabelle, and used in their simplified form when computing the CPT for the next level up. This generally results in more efficient simplification. Another benefit of producing intermediate CPTs is the detection of incompatibilities early during the simplification phase. Moreover, this indicates the group of components at fault and helps localize the error.

The second component of our toolset includes a complete implementation of the theory of MPTs and CPTs in Isabelle. In addition, we have implemented in Isabelle a set of functions (keyword **simulink**) which perform expansion and simplification automatically in the generated CPTs, and also generate automatically proved theorems of the simplified formulas. After expansion and simplification, we obtain for the top-level system a single MPT referring only to the external input, output, and state/next state variables of the system (and not to the internal links of the diagram).

As another example, when we run the tool on the example of Fig. 6, we obtain the theorem \(\mathsf {ConstDiv} = \mathsf {Fail}\), which states that the system has no legal inputs. This reveals the incompatibility due to performing a division by zero.

### 5.2 Evaluation

We evaluated our toolset on several case studies, including the Foucault pendulum, house heating and anti-lock braking systems from the Simulink examples library.^{5} Due to space limitations, we only present here the results obtained on the running example (Fig. 3) and the Fuel Control System (FCS) model described in [10, 11]. FCS solves the problem of maintaining the ratio of air mass and injected fuel at the stoichiometric value [5], i.e., enough air is provided to completely burn the fuel in a car’s engine. This control problem has important implications on lowering pollution and improving engine performance. Three designs are presented in [10, 11], all modeled in Simulink, but differing in their complexity. The first model is the most complex, incorporating already available subsystems from the Simulink library. The second and third models represent abstractions of this main design, but they are still complicated for verification purposes. The second model is formalized as Hybrid I/O Automata [15], while the third is presented as Polynomial Hybrid I/O Automata [8]. We evaluate our approach on the third model designed with Simulink, available from http://cps-vo.org/group/ARCH/benchmarks. This model has a 3-level hierarchy with a total of 104 block instances (97 basic blocks and 7 subsystems), and 101 connections, of which 8 feedbacks.

Experimental results for the running example (Fig. 3).

FPT | IT | NFBT | ||||||
---|---|---|---|---|---|---|---|---|

HBD | FBD | HBD | FBD | IO-HBD | IO-FBD | |||

Translation | \(\mathcal {T}_{\text{ trans }}\) | 0.082 | 0.093 | 0.081 | 0.087 | 0.081 | 0.085 | 0.096 |

\(\mathcal {L}_{\text{ cpt }}\) | 722 | 629 | 1131 | 1246 | 1146 | 1134 | 1159 | |

\(\mathcal {N}_{\text{ cpt }}\) | 10 | 9 | 10 | 9 | 14 | 14 | 15 | |

Expansion, simplication, and compatibility check | \(\mathcal {T}_{\text{ simp }}\) | 0.596 | 0.575 | 0.184 | 0.225 | 0.240 | 0.279 | 0.214 |

\(\mathcal {P}_{\text{ simp }}\) | 0.006 | 0.005 | 0.005 | 0.006 | 0.006 | 0.007 | 0.006 |

Experimental results for the FCS model.

FPT | IT | NFBT | ||||||
---|---|---|---|---|---|---|---|---|

HBD | FBD | HBD | FBD | IO-HBD | IO-FBD | |||

Translation | \(\mathcal {T}_{\text{ trans }}\) | 0.249 | 0.329 | 0.213 | 0.222 | 0.220 | 0.260 | 0.605 |

\(\mathcal {L}_{\text{ cpt }}\) | 18895 | 17432 | 87006 | 116550 | 86318 | 108001 | 46863 | |

\(\mathcal {N}_{\text{ cpt }}\) | 127 | 120 | 127 | 120 | 236 | 236 | 269 | |

Expansion, simplification, and compatibility check | \(\mathcal {T}_{\text{ simp }}\) | 894.472 | 3471.317 | 617.873 | 2439.229 | 267.052 | 417.05 | 57.425 |

\(\mathcal {P}_{\text{ simp }}\) | 7.144 | 7.267 | 7.856 | 7.161 | 6.742 | 6.228 | 5.18 | |

\(\mathcal {L}_{\text{ simp }}\) | 158212 | 158212 | 157791 | 157797 | 127132 | 127642 | 122001 |

The notations used in the tables are as follows: (1) \(\mathcal {T}_{\text{ trans }}\): time to generate the Isabelle CPTs from the Simulink model, (2) \(\mathcal {L}_{\text{ cpt }}\): length of the produced CPTs (# characters), (3) \(\mathcal {N}_{\text{ cpt }}\): number of generated CPTs, (4) \(\mathcal {T}_{\text{ simp }}\): total time needed for expansion and simplification, (5) \(\mathcal {P}_{\text{ simp }}\): time to print the simplified formula, (6) \(\mathcal {L}_{\text{ simp }}\): length of the simplified formula (# chars). All times are in seconds. We report separately the time to print the final formulas (\(\mathcal {P}_{\text{ simp }}\)), since printing takes significant time in the Isabelle/ML framework.

Let us now focus on Table 2 since it contains the most relevant results due to the size and complexity of the system. Observe that the translation time (\(\mathcal {T}_{\text{ trans }}\)) is always negligible compared to the other times.^{6} Also, NFBT generates the most CPTs, which are relatively short compared to the other translations. This is one of the reasons why CPTs produced by NFBT are easier to expand/simplify than those produced by the other methods. The other and main reason is that applying the \(\mathsf {feedback}\) operator requires identifying *f* and \(f'\), computing several function compositions, etc. We note that a Simulink feedback connection can transfer an array of *n* values, which is translated by our tool as *n* successive applications of \(\mathsf {feedback}\).

**Readability.** An important aspect of the produced CPTs is their *readability*. Defining quantitative readability measures such as number, length, nesting depth, etc., of the generated CPTs, is beyond the scope of this paper. Nevertheless, we can make the following (subjective) observations: (1) IT with option -io improves readability as the intermediate outputs allow to parse the result step by step. (2) NFBT reduces readability because this method decomposes blocks and does not preserve the hierarchy of the original model.

**Equivalence of the Different Translations.** One interesting question is whether the different translation options generate equivalent CPTs. Proving a meta-theorem stating that this is indeed the case for every diagram is beyond the scope of this paper, and part of future work. Nevertheless, we did prove that in the case of the FCS model, the final simplified MPTs resulting from each translation method are all equivalent. These proofs have been conducted in Isabelle.

**Analysis.** Our tool proves that the final simplified MPT of the entire FCS model is not \(\mathsf {Fail}\). This proves compatibility of the components in the FCS model. The obtained MPT is functional, i.e., has the form \(\{p\}\circ [f]\). Its assert condition *p* states that the state value of an integrator which is fed into a square root is \(\ge 0\). We proved in Isabelle that this holds for all \(\varDelta t > 0\). Therefore, compatibility holds independently of the value of the time step.

*simTime*is mistakenly set to 10, the model contains a division by zero. Our tool catches this error during compatibility checking, in 51.71 s total (including NFBT translation, expansion, and simplification, which results in \(\mathsf {Fail}\)).

**Comparison with Simulink.**In this work we give semantics of Simulink diagrams in terms of CPTs. One question that may be raised is how the CPT semantics compares to Simulink’s own semantics, i.e., to “what the simulator does”. Our toolset includes an option to generate simulation code (in Python) from the Isabelle CPTs. Then, we can compare the simulation results obtained from Simulink to those obtained from the CPT-generated simulation code. We performed this comparison for the FCS model: the results are shown in Fig. 8. Since the FCS model is closed (i.e., has no external inputs) and deterministic, it only has a single behavior. Therefore, we only generate one simulation plot for each method. The plot from Fig. 8a is obtained with variable step and the ode45 (Dormand-Prince) solver. The difference between the values computed by Simulink and our simulation ranges from 0 to 6.1487e-05 (in absolute value) for this solver. Better results can be obtained by reducing the step length. For instance, a step of 5e-05 gives an error difference of 2.0354e-06.

## 6 Related Work

A plethora of work exists on translating Simulink models to various target languages, for verification purposes or for code-generation purposes. Primarily focusing on verification and targeting discrete-time fragments of Simulink, existing works describe translations to BIP [22], NuSMV [17], or Lustre [24]. Other works study transformation of continuous-time Simulink to Timed Interval Calculus [4], Function Blocks [25], I/O Extended Finite Automata [26], or Hybrid CSP [27], and both discrete and continuous time fragments to SpaceEx Hybrid Automata [18]. The Stateflow module of Simulink, which allows to model hierarchical state machines, has been the subject of translation to hybrid automata [1, 16].

Contract-based frameworks for Simulink are described in [3, 21]. [3] uses pre/post-conditions as contracts for discrete-time Simulink blocks, and SDF graphs [12] to represent Simulink diagrams. Then sequential code is generated from the SDF graph, and the code is verified using traditional refinement-based techniques [2]. In [21] Simulink blocks are annotated with rich types (separate constraints on inputs and outputs, but no relations between inputs and outputs which is possible in our framework). Then the SimCheck tool extracts verification conditions from the Simulink model and the annotations, and submits them to an SMT solver for verification.

Our work offers a compositional framework which allows compatibility checks and refinement, which is not supported in the above works. We also study different translation strategies from HBDs to an algebra with serial, parallel, and feedback composition operators, which, to the best of our knowledge, have not been previously studied.

In [9], the authors propose an *n*-ary parallel composition operator for the Lotos process algebra. Their motivation, namely, that there may be several different process algebra terms representing a given process network, is similar to ours. But their solution (the *n*-ary parallel composition operator) is different from ours. Their setting is also different from ours, and results in some significantly different properties. For instance, they identify certain process networks which cannot be expressed in Lotos. In our case, *every* HBD can be expressed as a CPT (this includes HBDs with algebraic loops, even though we do not consider these in this paper).

Modular code generation methods for Simulink models are described in [13, 14]. The main technical problem solved there is how to cluster subsystems in as few clusters as possible without introducing false input-output dependencies.

## 7 Conclusion

In this paper we present a compositional semantics and analysis framework for hierarchical block diagrams such as those found in Simulink and similar tools. Our contributions are the following: (1) semantics of basic Simulink blocks (both stateless and stateful) as atomic monotonic predicate transformers; (2) compositional semantics of HBDs as composite MPTs; (3) three translation strategies from HBDs to CPTs, implemented in the simulink2isabelle compiler; (4) the theory of CPTs, along with expansion and simplification methods, implemented in Isabelle; (5) automatic static analysis (compatibility checks) implemented in Isabelle; and (6) proof of concept and evaluation of the framework on a real-life Simulink model from Toyota. Our approach enables compositional and correct-by-construction system design. The top-level MPT, which can be viewed as a formal interface or contract for the overall system, is automatically generated. Moreover, it is formally defined and checked in Isabelle (the theorems are also automatically generated and proved).

As future work, the current code generation process, used to compare the Isabelle code to the Simulink code via simulation, could be extended to also generate proof-carrying, easier-to-certify embedded code, from the Isabelle theories. Other future work directions include: (1) studying other translation strategies; (2) improving the automated simplification methods within Isabelle or other solvers; (3) extending the toolset with automatic verification methods (proving requirements against the top-level MPT); and (4) extending the toolset with fault localization methods whenever the compatibility or verification checks fail.

## Footnotes

- 1.
- 2.
- 3.
Our exposition focuses on HBDs as implemented in Simulink, but our method and tool can also be applied to other block-diagram based languages with minor changes.

- 4.
Available at: http://users.ics.aalto.fi/iulia/sim2isa.shtml.

- 5.
- 6.
\(\mathcal {T}_{\text{ trans }}\) for NFBT is almost twice larger than for FPT, IT and IT-IO. The reason is that NFBT executes extra steps, such as splitting blocks with multiple outputs and removing CPTs that are not used in calculating the system’s output.

## References

- 1.Agrawal, A., Simon, G., Karsai, G.: Semantic translation of Simulink/Stateflow models to hybrid automata using graph transformations. Electron. Notes Theor. Comput. Sci.
**109**, 43–56 (2004)CrossRefzbMATHGoogle Scholar - 2.Back, R.-J., von Wright, J.: Refinement Calculus: A Systematic Introduction. Springer, New York (1998)CrossRefzbMATHGoogle Scholar
- 3.Boström, P.: Contract-based verification of Simulink models. In: Qin, S., Qiu, Z. (eds.) ICFEM 2011. LNCS, vol. 6991, pp. 291–306. Springer, Heidelberg (2011)CrossRefGoogle Scholar
- 4.Chen, C., Dong, J.S., Sun, J.: A formal framework for modeling and validating Simulink diagrams. Formal Aspects Comput.
**21**(5), 451–483 (2009)CrossRefzbMATHGoogle Scholar - 5.Cook, J.A., Sun, J., Buckland, J.H., Kolmanovsky, I.V., Peng, H., Grizzle, J.W.: Automotive powertrain control - A survey. Asian J. Control
**8**(3), 237–260 (2006)MathSciNetCrossRefGoogle Scholar - 6.Dijkstra, E.: Guarded commands, nondeterminacy and formal derivation of programs. Comm. ACM
**18**(8), 453–457 (1975)MathSciNetCrossRefzbMATHGoogle Scholar - 7.Dragomir, I., Preoteasa, V., Tripakis, S.: Translating hierarchical block diagrams into composite predicate transformers. CoRR, abs/1510.04873 (2015)Google Scholar
- 8.Frehse, G., Han, Z., Krogh, B.: Assume-guarantee reasoning for hybrid I/O-automata by over-approximation of continuous interaction. In: CDC, pp. 479–484 (2004)Google Scholar
- 9.Garavel, H., Sighireanu, M.: A graphical parallel composition operator for process algebras. In: FORTE XII. IFIP Conference Proceedings, vol. 156, pp. 185–202. Kluwer (1999)Google Scholar
- 10.Jin, X., Deshmukh, J., Kapinski, J., Ueda, K., Butts, K.: Benchmarks for model transformations and conformance checking. In: ARCH (2014)Google Scholar
- 11.Jin, X., Deshmukh, J.V., Kapinski, J., Ueda, K., Butts, K.: Powertrain control verification benchmark. In: HSCC, pp. 253–262. ACM (2014)Google Scholar
- 12.Lee, E., Messerschmitt, D.: Synchronous data flow. Proc. IEEE
**75**(9), 1235–1245 (1987)CrossRefGoogle Scholar - 13.Lublinerman, R., Szegedy, C., Tripakis, S.: Modular code generation from synchronous block diagrams - modularity vs. code size. In: POPL, pp. 78–89. ACM, January 2009Google Scholar
- 14.Lublinerman, R., Tripakis, S.: Modularity vs. reusability: code generation from synchronous block diagrams. In: DATE, pp. 1504–1509. ACM, March 2008Google Scholar
- 15.Lynch, N., Segala, R., Vaandrager, F.: Hybrid I/O automata. Inf. Comput.
**185**(1), 105–157 (2003)MathSciNetCrossRefzbMATHGoogle Scholar - 16.Manamcheri, K., Mitra, S., Bak, S., Caccamo, M.: A step towards verification and synthesis from Simulink/Stateflow models. In: HSCC, pp. 317–318. ACM (2011)Google Scholar
- 17.Meenakshi, B., Bhatnagar, A., Roy, S.: Tool for translating Simulink models into input language of a model checker. In: Liu, Z., Kleinberg, R.D. (eds.) ICFEM 2006. LNCS, vol. 4260, pp. 606–620. Springer, Heidelberg (2006)CrossRefGoogle Scholar
- 18.Minopoli, S., Frehse, G.: SL2SX Translator: from Simulink to SpaceEx verification tool. In: HSCC (2016)Google Scholar
- 19.Preoteasa, V., Tripakis, S.: Refinement calculus of reactive systems. In: EMSOFT, pp. 1–10, October 2014Google Scholar
- 20.Preoteasa, V., Tripakis, S.: Towards compositional feedback in non-deterministic and non-input-receptive systems. CoRR, abs/1510.06379 (2015)Google Scholar
- 21.Roy, P., Shankar, N.: SimCheck: a contract type system for Simulink. Innovations Syst. Softw. Eng.
**7**(2), 73–83 (2011)CrossRefGoogle Scholar - 22.Sfyrla, V., Tsiligiannis, G., Safaka, I., Bozga, M., Sifakis, J.: Compositional translation of Simulink models into synchronous BIP. In: SIES, pp. 217–220, July 2010Google Scholar
- 23.Tripakis, S., Lickly, B., Henzinger, T.A., Lee, E.A.: A theory of synchronous relational interfaces. ACM Trans. Program. Lang. Syst.
**33**(4), 14:1–14:41 (2011)CrossRefGoogle Scholar - 24.Tripakis, S., Sofronis, C., Caspi, P., Curic, A.: Translating discrete-time Simulink to Lustre. ACM Trans. Embed. Comput. Syst.
**4**(4), 779–818 (2005)CrossRefGoogle Scholar - 25.Yang, C., Vyatkin, V.: Transformation of Simulink models to IEC 61499 Function Blocks for verification of distributed control systems. Control Eng. Pract.
**20**(12), 1259–1269 (2012)CrossRefGoogle Scholar - 26.Zhou, C., Kumar, R.: Semantic translation of Simulink diagrams to input/output extended finite automata. Discrete Event Dyn. Syst.
**22**(2), 223–247 (2012)MathSciNetCrossRefzbMATHGoogle Scholar - 27.Zou, L., Zhany, N., Wang, S., Franzle, M., Qin, S.: Verifying Simulink diagrams via a hybrid Hoare logic prover. In: EMSOFT, pp. 9:1–9:10, September 2013Google Scholar