Abstract
Simulink is a well-known block diagram-based tool for modular design and multidomain simulation of Cyber-Physical Systems (CPS). However, the simulation by Simulink cannot completely cover the state space or behavior of a target system, which would not ensure the correctness of the developed block diagrams in Simulink. In this work, we present a contract-based method, which supports compositional reasoning and refinement, for proving the correctness of Simulink block diagrams with discrete-time and continuous-time dynamic behavior. We use the assume-guarantee contract as a specification language. The Simulink block diagrams are correct in the sense that if the block diagrams satisfy the formal specifications of the system being modeled. To prove the correctness of a block diagram, we first define semantics for Simulink block diagrams. We study three composition operators, i.e., serial, parallel, and algebraic loop-free feedback with multistep delays. We present a satisfaction relation between the block diagram and contract and present a refinement relation between the contracts. We prove that if the Simulink block diagram satisfies the composition contract and the composition contract refines the system specifications, the block diagram is correct relative to the system specifications. Furthermore, we demonstrate the effectiveness of our method via a real-world case study originating from the control system of a reservoir. Our method can also provide an idea to verify whether the designed CPS is planted with a logic bomb by attackers.
1. Introduction
Cyber-Physical Systems (CPS) are engineering systems where functionalities emerge from the network interaction of physical and computational processes [1]. Designing CPS correctly and efficiently is a critical challenge for computer science and industry. Model-based design (MBD) [2] provides virtual system integration and a visual approach to develop models for CPS. Bugs in the model can be identified and corrected at an early stage of the design process when no hardware is available. Such a method is considered as an effective solution to design CPS correctly.
Simulink [3] is a graphical modeling language for model-based design (MBD). Currently, Simulink greatly appeals to CPS engineers since it captures the dynamic behavior of the modeled system. A Simulink block diagram consists of blocks connected via wires. The blocks (from Simulink library, a set of predefined blocks that can assemble block diagrams of systems with drag-and-drop mouse operations) represent different parts of a system being modeled, and wires indicate the communication between the blocks. The blocks have input and output ports that receive the input signals and send the output signals. The signals are the functions of time that can be continuous-time or discrete-time. Hence, the Simulink block diagrams can be classified based on the time: contain only discrete-time blocks, continuous-time blocks, or a mixture of discrete-time and continuous-time blocks. Our work focuses on the Simulink block diagrams containing only discrete-time blocks and continuous-time blocks, which we call discrete-time Simulink block diagrams or continuous-time Simulink block diagrams.
Simulink supports the design, modeling, simulation, and test of CPS. The test for Simulink block diagrams is based on numerical simulation. One of the drawbacks of numerical simulation is that it does not completely cover a target system’s state space or behavior. In addition, a logic bomb [4] maliciously inserted into Simulink by attackers can persistently change the behavior. In safety-critical systems, an error could lead to incorrect analysis results and thus result in property damage, even significant injury or death. Formal methods can rigorously prove that all possible behaviors satisfy a specific formal specification, thus ensuring correctness. By “correctness,” we mean that all possible behaviors of the Simulink block diagram satisfy the given formal specification of a system to be modeled.
A number of methods have been reported in the literature. To the best of our knowledge, some existing solutions only focus on Simulink block diagrams with discrete-time behaviors, e.g. [5–11]. A common approach for tackling continuous-time Simulink block diagrams is to discretize the continuous-time dynamical behavior [12, 13]. However, the discretization of continuous systems reduces the accuracy of the verification of continuous dynamics. The contract supports compositional reasoning and refinement, enabling hierarchical design and verification of complex systems by decomposed system-level specification into the block-level specification to provide implementations correctly. Based on this advantage, we employ contract as formal specification to specify the observable trajectory of discrete-time and continuous-time blocks and present a contract-based refinement technique for proving Simulink block diagrams’ correctness.
To prove the correctness of Simulink block diagrams, we first define formal semantics for Simulink block diagrams. We consider the blocks in the library to be units and call them elementary blocks. The elementary block expresses the time-dependent (continuous-time or discrete-time) relationships between the inputs, internal states, and outputs. Thus, we define the elementary block as a dynamic system that can model both continuous-time and discrete-time blocks. Based on this definition, we define the observable trajectory for the blocks, i.e., the evolution of the value of input-output variables over time. We formulate the wire as unilateral connection (i.e., the relations of output and input between connected blocks) for communication. Then, to construct the Simulink block diagrams, we define three basic composition operators, namely, serial, parallel, and algebraic loop-free feedback composition. Moreover, we study the algebraic loop-free feedback composition containing multistep delays. Similar works [13, 14] only considered the ones with unit delay.
We then present a contract-based refinement technique to prove the correctness of the Simulink block diagrams, as shown in Figure 1. Our purpose is to prove that the block diagram satisfies the system specification. To this end, we introduce a mid-level called composition contract (i.e., the composition of contracts corresponding to the blocks that construct the Simulink block diagrams) between low-level block diagrams and high-level system specifications for composition. The approach is divided into two stages. Firstly, we define the satisfaction relation that relates block to contract and verify that the satisfaction relation is preserved by composition, i.e., if blocks satisfy their contract, respectively, their composition satisfies the contract composition. Secondly, we define the refinement relation between contracts and prove that the composition of contracts refines the system specifications. The block diagram is correct as long as we prove that the block diagram satisfies the composition contract and the composition contract refines the system specification to imply that the block diagram satisfies the system specification.
1.1. Contributions
Contributions of this paper are summarized as follows: (i)We define the formal semantics for Simulink block diagrams from the viewpoint of dynamic systems to precisely express the trajectory of the Simulink block diagrams with discrete-time and continuous-time(ii)Under the semantics, we propose a contract-based refinement technique mentioned above for proving the correctness of the Simulink block diagrams with discrete-time and continuous-time blocks(iii)We demonstrate the effectiveness of our method through a case study of the control system of a reservoir that is modelled with Simulink block diagrams
1.2. Organization
The remainder of this paper is organized as follows. Section 2 reviews the related works. Section 3 introduces the notations and notions used in our work. Section 4 presents the semantics of the Simulink block diagrams. Section 5 proposes the contract-based refinement method for proving the correctness of Simulink diagram blocks. Section 6 demonstrates the effectiveness of our method with a case study. Section 7 concludes the paper and proposes future works.
2. Related Works
In recent years, there are a range of methods to analyze and verify Simulink.
There exist some works that translate Simulink into other formal modeling languages. For example, Tripakis et al. [5] translated the Simulink block diagrams to a synchronous dataflow language, Lustre. Since the Lustre has a discrete-time semantics, the work [5] only handled discrete-time Simulink block diagrams. In [6], Cavalcanti et al. presented a semantics for discrete-time Simulink blocks diagrams called Circus. The work [6] was based on existing tools that generate CSP and Z specifications from discrete-time block diagrams. It only translated discrete-time Simulink blocks diagrams, Simulink block diagrams with continuous-time were not considered.
Chen and Dong [15, 16] presented the method to automatically transformed Simulink diagrams with discrete-time and continuous-time into Timed Interval Calculus (TIC) models. This method applied the Prototype Verification System (PVS) to validate that TIC fulfils requirements. These works were the first attempt to model Simulink block diagrams with continuous-time. The work [17] presented an operational semantics for Simulink’s simulation engine that formally defines the numerical simulation result, including discrete-time and continuous-time. Zou et al. [18] automatically translated Simulink block diagrams into Hybrid Communicating Sequential Processes (HCSP) and showed how the translated HCSP models are verified using the Hybrid Hoare Logic Verifier. In [19], it showed how different Simulink blocks can be expressed in the synchronous language Zlus, which extends a language Lustre with ODEs and zero-crossing events. The main difference between the articles [15–19] and our work is intentions. Our main goal here is not to translate the Simulink block diagrams to other formalisms, nor to define the semantics of Simulink’s engine, but to directly define the trajectory of the Simulink block diagrams from the point of view of dynamic systems and provide a compositional and refinement technology to prove the correctness of Simulink block diagrams with discrete-time and continuous-time. On the other hand, we have three basic composition operators, i.e., serial, parallel, and algebraic loop-free feedback composition with multistep delays, which more facilitate the composition in construction. However, the work [18] could verify hybrid system, which is not considered in our work.
The contract-based approaches for verifying the correctness of Simulink block diagrams were also widely studied in the literature. Bostro et al. [7] showed definitions of contract and refinement using the action systems for Simulink models, while refinement provides a framework for reasoning about implementation correctness. However, this work only focuses on discrete-time Simulink block diagrams. Ye et al. [10, 11] defined a theoretical reasoning framework for Simulink block diagrams using Unifying Theories of Programming (UTP). The main idea of these papers is to translate each block or subsystem to a design, and the hierarchical connections of blocks are mapped to a variety of compositions of designs, and verify some properties. However, these papers only handled discrete-time Simulink block diagrams. In our work, we provide a compositional and refinement technology to prove the correctness of Simulink block diagrams with discrete-time and continuous-time. Dragomir et al. [13] recently presented a Refinement Calculus of Reactive Systems (RCRS) toolset for compositional formal modeling and reasoning about discrete and continuous reaction systems. RCRS is a discrete-time framework. The continuous systems can be modeled by discretizing time. However, the discretization of continuous systems reduces the accuracy of the verification of continuous dynamics. Our approach differs because we can directly represent and theoretically verify the correctness of discrete-time and continuous-time Simulink block diagrams. Moreover, we study the algebraic loop-free feedback composition with multistep delays.
3. Preliminary
In this section, we introduce some notations and notions that will be used in our work. We denote the set of natural numbers by , i.e., , the set of positive integers by , i.e., , the set of positive real numbers , and the set of nonnegative real numbers by . We denote the set of integers between and by . We denote vectors by bold fonts, and their components are indexed from 1 to ; for example, , and is the component of , .
Following the definitions of vector addition and scalar multiplication in vector spaces, for two vectors and , the vector addition can be expressed as and the scalar multiplication can be expressed as , where and is a field.
We fix a time axis. The continuous-time domain is a subset of with a left endpoint equal to 0. The right endpoint may be open or closed. For any , the discrete-time domain is a set , where the time instant is called sample time point, is the initial time, and keeps increasing at every iteration, i.e., .
We denote the -dimensional real-valued vector space by , where . A signal is a function from a time-domain to , i.e., (or for short). We use to denote a set of all signals . A continuous-time signal is a signal defined over a continuous-time domain . A discrete-time signal is a signal that is defined at the discrete-time domain . The values of the discrete-time signal update at each and remain constant in the intervals .
4. Simulink Block Diagrams and Semantics
In this section, we present the semantics of Simulink block diagrams. We will start by giving a brief introduction to Simulink block diagrams, and we highlight the features relevant to our work. For more details, we refer the reader to [3].
4.1. Introduction of Simulink Block Diagrams
A Simulink block diagram is a graphical representation of a dynamic system. The Simulink block diagrams are composed of blocks and wires. The blocks can be either elementary blocks provided by the Simulink library or composition blocks made up of elementary blocks or other composition blocks. An example that implements the relationship between the vehicle’s power, resistance, and speed is shown in Figure 2. It consists of Constant, Subsystem, and Scope, where Constant and Scope are elementary blocks, and the composition block Subsystem comprises four elementary blocks Gain1, Subtract, Integrator, and Gain2.
In its most general form, the elementary block has Inputports and Outputports that receive the input signals and send the output signals. For some special blocks, the absence of Inputports or Outputports is also allowed. We will explain the details later. An elementary block is either stateful or stateless. We say a block is stateful if the output of this block depends on its inputs and internal states (i.e., memory). We say a block is stateless if the output depends only on its inputs. Wires transmit signals in the direction indicated by the arrow. It must transmit signals from Outputports of one block to Inputports of another block in terms of its sample times. An exception to this is that one wire can be drawn from another. This sends the original signal to two (or more) target blocks. Wire communication is instant. That is, when a block outputs the value to a wire, all blocks connected to that wire will see the new value simultaneously.
To improve the modeling capabilities of Simulink, each elementary block contains some user-tunable parameters. One of the significant parameters is sample time that indicates the rate at which the block executes in simulation. According to the sample time, the blocks are divided into two main categories: continuous and discrete blocks. The sample time comprises two parameters: sample time period and initial time offset. For the continuous blocks, the sample time period. For the discrete blocks, the sample time period is always greater than zero and less than the simulation end time and less than or equal to . Since the default value of the initial offset is , unless otherwise mentioned, we let the initial offset be . As an example, suppose that the time unit is seconds, let the sample time period of a block be 0.02 s, and then the block updates methods (update, derivative or output) each 0.02 s. The Simulink block diagrams can be single rate where all blocks run with the same period or multirate where blocks run on different periods. This work considers single rate discrete-time Simulink block diagrams and continuous-time Simulink block diagrams with .
There are three basic composition operators in Simulink: (i) Serial composition is the composition that the output of the source block is connected to the input of the target block. (ii) Parallel composition is that two blocks are “stacked on top of each other” without any wires between the two blocks. (iii) Feedback composition is that the output of a block connects to one of its inputs. Other forms of composition can be assembled from these three basic composition operations and wires.
4.2. The Semantics of Simulink Block Diagrams
In this subsection, we formally define the semantics for Simulink block diagrams. We focus on the semantics of elementary block, composition semantics for composition operators, and the semantics of communication between blocks.
As introduced in 4.1, an elementary block has Inputports which receive the input signals, internal state, and Outputports that send the output signals. It describes a mathematical relationship between inputs, outputs, and internal states to capture dynamic behavior. We define an elementary block as a dynamical system.
Definition 1 (An elementary block). An elementary block is a tuple , where (i) is an input signal, , is the initial value of the input signal(ii) is an output signal, , is the initial value of the output signal(iii) is an internal state signal, , is the initial value of the internal state signal(iv) is the transition function of internal state(v) is the output function, i.e.,
The above definition can express both discrete-time blocks and continuous-time blocks. We say that a block is continuous if it operates on continuous-time signals. We say a block is discrete if it operates on discrete-time signals. Every block must define its output function and may define initialize, update, or derivative function to realize the corresponding function. For the discrete-time blocks, we denote , i.e., , which refers to the update function of internal state. For the continuous-time blocks, we denote , i.e., , which refers to the derivative function of internal state. The input or internal state of a block can be empty, respectively. In that case, we denote the input or internal state by or and use a symbol “-” to denote the transition function of the internal state. If a block has no internal state, we say the block is stateless.
Some elementary blocks mentioned in our article are shown in Table 1 Three simple examples are shown below.
Example 1 (Unitdelay). An example of a stateful discrete-time elementary block is the Unitdelay block. The Unitdelay expresses that the current output value of this block is equal to the value of the current internal state, and the value of the next internal state is equal to the current input value. It can be represented as , where .
Example 2 (Multistep delays). A block with multistep delays is denoted as , where , and , where means that the block outputs the input of this block after sample periods, .
Example 3 (Integrator). An example of a stateful continuous-time elementary block is the Integrator. The block models the relations, with . The Integrator can be represented as , where .
We use the observable trajectory to model the evolution of the input-output variables.
Definition 2 (The observable trajectory of the discrete-time elementary block). Let be a discrete-time elementary block. An observable trajectory of is a set , where is the input trajectory and is the output trajectory.
Definition 3 (The observable trajectory of the continuous-time elementary block). Let be a continuous-time elementary block. An observable trajectory of is a set , where is the input trajectory and is the output trajectory.
The wires connect some Outputports of a block to some Inputports of other block for communicating. For any blocks, and , where , , , and . We model the wires between and as a relation, called unilateral connection. A unilateral connection is a set of variables pair , for and , where the former of each pair is the output variable that comes from , the latter of each pair is the input variable that comes from . We define the unilateral connection as follows:
Definition 4 (Unilateral connection). Given two blocks and , we define a unilateral connection from to (and vice versa) as a relation satisfying that: (i) is the component of , for all (ii) is the component of , for all (iii), for all
Note that not all the blocks can be connected. Given a source block and a target block , if we connect the output variables of the source block with input variables of the target block, variable names and their types (the sets of values that a variable can take) impose some constraints: First, the names of the input and output variables should not conflict. Second, the types should match and , where is the type of and is the type of . Third, one output port can connect to many input ports, but an input port can connect to at most one output ports.
For readability, we use to denote a set of specific unilateral connection (determined by a relation as defined in Definition 4). Note that, since is a relation, we can also have .
4.3. Composition
A Simulink block diagram is a composition block constructed by elementary blocks according to composition operators. We will define the semantics of three basic composition operators in the following, namely, serial, parallel, and algebraic loop-free feedback composition with multistep delays. We first consider the serial composition.
We can compose blocks and to form a serial composition when there is a unilateral connection between and and the unilateral connection satisfies the connection rules, as shown in Figure 3(a).
Definition 5 (Serial composition). Given blocks and , a serial composition of and is defined as a block if there exists a unilateral connection and The definition of the serial composition of elementary blocks coincides with the definition of an elementary block (i.e., Definition 1), and therefore a composition can be considered a block.
Example 4 (Serial composition). In Figure 3(b), the stateless block Gain takes input , computes times of , and returns as output, where and . Another stateless block Sum has the input and output , where and , . Let be the unilateral connection between Gain and Sum. Then, we can express these blocks as follows: where , , . According to Definition 5, we compute the output function of the serial composition as follows: Therefore, we have .
(a)
(b)
The serial composition of blocks satisfies associative laws.
Lemma 6 (Associativity). Given blocks , , and , we have .
Proof. It is easy to verify using Definition 5. Thus, if we compose multiple blocks in serial, we can first compose two blocks, compose the result with a third one, , and rearranging the brackets in the expression does not change the result as long as the block’s position remains the same.
Parallel composition is a particular case of composition with connection, where the unilateral connection between and is an empty set. We define parallel composition as follows.
Definition 7 (Parallel composition). Given blocks and , we define the parallel composition of and as a block , where
Example 5 (Parallel composition). Consider the parallel composition shown in Figure 4(a). The block Divide models the relation , where is the input signal and requires , is the output signal, and represents time. The Sine Wave block models the relation , where is the input variable and is the output variable. Therefore, the Divide and Sine Wave can be represented as Following Definition 7, we write the parallel composition as follows:
(a)
(b)
Note that Definition 5 defines the case that all the Outputports of match the Inputports of . However, not all Outputports of match the Inputports of and not all Outputports of are connected to all the Inputports of . As an example, we consider Figure 4(b). To handle this composition, we introduce a particular elementary block Id representing its output is identical to its input. We model the wires that connect the and as and , respectively. We then denote the composition by , where .
The parallel composition of blocks satisfies commutative law and associative law.
Lemma 8. Given blocks , and, we have (i)(ii)
Proof. Straightforward from the Definition 7.
We will next define the algebraic loop-free feedback composition with multistep delays. Before defining that, we first introduce the algebraic loop feedback to aid this definition. In Simulink, an algebraic loop occurs when an input port of a direct feedthrough block is driven by the output of the same block in the same time step. The direct feedthrough means that a stateless block computes its output only depending on the input value at the current time. In mathematics, an algebraic loop can be expressed as the algebraic equation , where is the input variable and is the algebraic variable. Simulink solves the algebraic equation for at each time instant.
A simple example of an algebraic loop is the feedback that represents in Figure 5(a). The feedback is a Subtraction block with input and an output . The first element of input is used to communicate with the environment. The second element is used for feedback. The output is split into two equal signals: one is for output, and another is to feed the output back into input . Then, this loop implies that the output of the Subtraction block is an algebraic variable that is constrained to equal the first input minus , i.e., . Let and , we have , and then the solution of this loop is .
(a)
(b)
However, the algebraic loop has inherent difficulties in solving: (1) while Simulink solver solves the algebraic loop, the simulation can execute slowly. (2) Some algebraic loops have no solution (an example shown in Figure 5(b), the expression of this loop is , etc. These problems lead to algebraic loops that are undesirable. To remove the algebraic loop, according to Simulink, we connect to by stateful blocks (such as Delay, Memory, or Integrator) in this feedback to break the algebraic loop. We refer to this kind of acyclic structure as algebraic loop-free feedback, as shown in Figure 6. The work [14] defined the feedback with Unitdelay. We will handle the case of multistep delays.
Definition 9 (Algebraic loop-free feedback composition with multistep delays). Let blocks be feedback with an algebraic loop and be a multistep delays block. Let and be the unilateral connections between and . We denote by the algebraic loop-free feedback composition of and with multistep delays and define , where
(a)
(b)
In the definition above, the calculation process starts with the multistep delays block. When , let the initial state . The output’s initial value of this algebraic loop-free feedback . There exists , s.t. , when . Given a delay step , when , where , the output , where the internal state , and , where is the output of . There exists is the input of , and .
We next give an example to illustrate removing an algebraic loop by introducing Unitdelay, i.e., let the delay step .
Example 6 (An algebraic loop-free feedback composition with Unitdelay). In Figure 6(a), the Sum block is feedback with an algebraic loop. We connect to in this feedback by the Unitdelay to break the algebraic loop. The Unitdelay block , where . Let and , the and satisfy the connection rules, and then an algebraic loop-free feedback composition with Unitdelay is a block , where , and the output function
When , let be the initial value of the internal state of the Unitdelay. We have and . Hence, we get the initial output value of this composition .
When , we first consider Unitdelay. Because of , , and , we have .
Next, we give an example about algebraic loop-free feedback composition with Integrator.
Example 7 (An algebraic loop-free feedback composition with Integrator). An example of continuous time algebraic loop-free feedback composition with Integrator is shown in Figure 6(b). As previously mentioned, the Sum block is feedback with an algebraic loop. The Integrator can be represented as , where . In this composition, there exist unilateral connections and , and the unilateral connections satisfy the connection rules, and then an algebraic loop-free feedback composition with Integrator is a block , where . Let be the initial value of the internal state of the Integrator. We have , and there is a , s.t. . Hence, we get .
When , similarly, we first consider Integrator. Because there is a , s.t. , and . There exists , s.t. , we get
5. A Contract-Based Refinement Approach
The correctness refers to the trajectories of Simulink block diagrams that should satisfy the requirement specifications of the system. Since contracts are centered around trajectories, they are expressive and versatile enough to specify discrete-time and continuous-time blocks. We use the contract as a specification language to formalize and prove system requirements and specify the trajectories of blocks. In this section, we present a generic contract-based method for proving the correctness of Simulink block diagrams with discrete-time and continuous-time blocks.
Because the requirement specifications of a system are informal, we first formalize system requirement specifications into system contract specifications. We construct the Simulink block diagram according to the contract specification. We aim to prove that the Simulink block diagrams satisfy the system contract specification. To this end, the approach is divided into two steps. First, we modularly verify that Simulink block diagrams satisfy the composition contract (i.e., the composition of contracts corresponding to the blocks that construct the Simulink block diagrams). We associate a contract for every elementary block as a specification. After that, we define the satisfaction relation that relates block to contract and verify that the satisfaction relation is preserved by composition. That is, if blocks satisfy their contract, respectively, then the composition of blocks satisfies the composition of contracts. Second, we define the refinement relation between contracts and verify that the composition of contracts refines the system contract specifications. If the block diagram satisfies the composition contracts and the composition contracts refine the system specification, then the block diagram also satisfies the system specification. Hence, the Simulink block diagram is correct with respect to the system specification.
We further elaborate on the concepts and properties mentioned above in the following. We first define the contract specification for the block.
Definition 10 (Contract). A contract is a tuple , where (i) are the input vectors and output vectors, respectively(ii) represents the for the input trajectories of the block, where (iii) represents the for the input-output trajectories of the block, where
The contract specifies the expected trajectory for each elementary block. An example of a contract for a block Gain is shown below.
Example 8 (Contract for Gain). As an example, we consider the Gain block that represented in Example 4. A contract specification for Gain is a tuple: , where
Next, we will define the satisfaction relation, which relates a block to a contract by determining when a given block’s trajectories satisfy the specified specification. To define satisfaction relation, we first define a projection that expresses the input trajectory to aid that definition. A projection of a set into is defined as the set , where can be either the discrete-time domain or the continuous-time domain. We are now in a position to define satisfaction relation.
Definition 11 (Satisfaction). Let be a block and be a contract. We say satisfies , denoted by , if and .
We say that is a correct implementation of if . We have defined the notion of contract and satisfaction relation. The primary task of the proof method is to state that the satisfaction relation is preserved by composition. In the following, we study the composition operators of contracts according to the composition operators of blocks, i.e., serial, parallel, and algebraic loop-free feedback with multistep delays. We first define the serial composition of contracts.
Definition 12 (The serial composition of contracts). Let be contracts for . The serial composition of and , written , is a contract , where
The serial composition preserves the satisfaction relation. That is, if blocks satisfy their contracts, respectively, then the composition of blocks satisfies the composition of contracts.
Theorem 13 (Serial composition preserves satisfaction). If and , then .
Proof. We show a proof here for blocks with continuous-time trajectories, and the proof for blocks with discrete-time trajectories is similar. Let and be continuous-time blocks. The observable trajectories of and are denoted as and , respectively, where . The projection of into is . The projection of into is .
According to Definition 5, we write . We denote the observable trajectories of by . Then. The projection of into is. So, .
Given two contracts and , by Definition 12, we have , where and .
In order to proof , according to Definition 11, we only need to show that: if implies . We first prove that .
Since , according to Definition 11, we have implies . That is, for all , then . Since , according to Definition 11, we have for all , then . There exists a connection , according to Definition 4, we have . Then, , and by the expression of , we have . Thus, . For all , we have , , and . According to the expression of , we have . Thus, . Hence, .
We now define the parallel composition of contracts.
Definition 14 (The parallel composition of contracts). Given contracts and , we define the parallel composition of contracts as , where , and
The parallel composition also preserves the satisfaction relation. That is, if blocks satisfy their contracts, respectively, then the parallel composition of blocks satisfies the parallel composition of contracts.
Theorem 15 (Parallel composition preserves satisfaction). If and , then .
Proof. We show here a proof for blocks with continuous-time trajectories, and the proof for blocks with discrete-time trajectories is similar. Let and be blocks with continuous-time trajectories. The observable trajectories of and are denoted as and , respectively, . The projection of into is . The projection of into is the set . Following Definition 7, we write . We denote the observable trajectories of by . Then . The projection of into is , where .
Let and be contracts. By Definition 14, we write , where , and
To proof , according to Definition 11, we only need to show that if implies . We first prove that . Since , according to Definition 11, we have if implies . That is for all , for all , . Since , we have implies . That is, for all , then , for all , then . Hence, by (1), we have , . Hence, .
The parallel composition of contract is also associative and commutative.
Lemma 16 (Associativity, commutativity). Let , , and be contracts. Then (i)(ii)
Proof. Immediately follows from the Definition 14.
We now define the algebraic loop-free feedback composition of contracts.
Definition 17 (The algebraic loop-free feedback composition of contracts). Let and be the contracts. The algebraic loop-free feedback composition of and be defined as , where , and where , and .
The algebraic loop-free feedback composition also preserves the satisfaction relation.
Theorem 18 (Algebraic loop-free feedback composition preserves satisfaction). Let be the feedback with an algebraic loop and be a block with multistep delays. Let and be the contracts. If and , then .
Proof. It easily follows from Theorem 13 to Theorem 15.
We next turn to the refinement relation between the contract. We follow a standard notion inspired by [20].
Definition 19 (Refinement of contracts). Let and be two contracts. We say refines , denoted by , if and .
Refinement relaxes assumptions and reinforces guarantees, therefore, strengthening the contract. Obviously, the following refinement rule holds.
Lemma 20. Let and be two contracts. Then (i), for (ii)If and , then (iii)If and , then
The refinement implies that every Simulink block diagram satisfies the also satisfies the . This gives us the following property of correctness.
Theorem 21 (Correctness). Let be a block. Let and be contracts. The is said to be correct for , if .
Proof. Suppose , in terms of Definition 19, then , and . Suppose , then, for all , and . Hence, if , then .
Theorem 21 is essential in our contract theory since it relates the Simulink block diagram (composition block) to a system contract specification. That is, if a Simulink block diagram satisfies the composition contract, and the composition contract refines the system contract, then it also satisfies the system contract. This ensures that the Simulink block diagram is correct.
6. Case Study
We have discussed the proof approach in the previous section, and in this section, the approach that we proposed is being implemented through a real-world case study.
6.1. Problem Statement
We examine a case, a safety-critical water level control system of reservoir, to illustrate how to verify that the controller model of a reservoir originating from the farmland irrigation satisfy the safety requirements.
This reservoir mainly is used for irrigation and considers the comprehensive utilization of flood control and aquaculture. An inlet water pipe and a spillway exist on the top and bottom of the dam, respectively. The maximum dam height is m, the maximum is m, and the minimum water level is m. The management facilities of the reservoir are very backward. There are no special management agencies to observe and safety check the water level and no timely flood control.
We will use Simulink to model the water level control system of the reservoir and simulate the water level trajectories to monitor the water level control operation. Then we adopt the method that we presented to verify the Simulink block diagram’s correctness for ensuring the water level’s safety according to the reservoir’s actual situation. The water level controls the opening or closing of the valves. That is, the water level is neither higher than the highest water level, which causes the dam to be overloaded, nor can the aquaculture industry and farmland irrigation be affected by the water level being lower than the lowest water level.
6.2. Architectural Overview of Control System
The control system of water level consists of the following two major components: Sensor and Plant. (i)Sensor. The Sensor is a water level sensor. Inputs about the water level of the reservoir from its corresponding level sensor, and we suppose that the Sensor works properly(ii)Plant. The Plant is made up of four principal components, as shown in Figure 7(a): Reservoir, Valves, Controller, and Water inlet and outlet pipe (a)Reservoir. The Reservoir has parameters giving the maximum water lever , the minimum water lever , and the water level of the reservoir (b)Water valves. The Reservoir has two water valves. The inlet valve is at the top of the Reservoir, and the outlet valve is at the bottom. We suppose that the valves are either fully opened or fully closed immediately(c)Controller. The Controller is able to read the current water level provided by the sensor, and the output is the command signal open or closed. The controller’s target is to keep the water level between the minimum water lever and the maximum water lever (d)Water inlet and outlet. The inlet pipe and , and .
(a)
(b)
As the system is a closed-loop system, the controller must work with the reservoir. In Figure 8(a), a system including both controller and plant is given. We only focus on the controller.
(a)
(b)
6.3. The Safety Requirements of Water Level
The safety requirements for water level in the controller are given below, and the purpose is to avoid the water empty and filling of reservoir.
Requirement 1 When the of reservoir is above , the is opened, and when the of reservoir is below , the is closed.
Requirement 2 When the of reservoir is above , the is closed, and when the of reservoir is below , the is opened.
Driven by requirement, we now refine system-level requirements into block-level implementations. When the system is refined, subsystem details are added. We first decompose the controller into three different controllers: Decision controller, controller, and controller. The block diagrams of these controllers can be depicted graphically as in Figure 8(b). In the block diagram, the Decision decides that the water level is high or low. The computes whether the should be open, while the computes if the should be open.
For the Decision, if the water level is above , it is high. If the water level is below , it is low. For the , if the water level is high, then should be close(0). Otherwise, the should be open(1). For the , if the water level is low, then should be close(0). Otherwise, then should be open(1).
We use the contract as a formal specification language. We suppose , , and . The system-level safety requirement specification 1 is denoted as .
The system-level safety requirement specification 2 is denoted as , where
6.4. Verification of Correctness for the Controller System
We construct a Simulink block diagram for the control system according to requirements shown in Figure 7(b). Following the previous technical route, the verification method applied in this case consists of two stages.
Stage 1: verifying the Simulink block diagram satisfies the corresponding composition of contract.
The Decision controller has two controllers: and . The determines whether the water level is higher than the highest water level. The composition of Simulink block diagrams of is denoted as , where . We denote the by , and then , where,
Therefore, the observable trajectories of are denoted as , where
The main task in the next step is to apply the composition rules to calculate the composition contract and prove that the composition of blocks satisfies the composition of the corresponding contracts. We first specify a contract for each elementary block following Table 1. Then we apply the composition rules to calculate the composition contract and prove that the composition of blocks satisfies the composition contracts.
The composition contract of the is stated as , where
Since where
We use quantifier elimination law to simplify the expression. Therefore, the composition contract of the controller was written in the following form.
Similarly, the determines whether the water level is below the lowest water level. The composition of Simulink block diagrams of is denoted as , where . Let and . We denote the Simulink block diagrams of by , where
The observable trajectories of is denoted as , where
The composition contract of the controller for is stated as , where
Since variables and are used to read the values of water level, so and . According to Definition 11, , we have , , and , . Hence, and .
We next turn to research the controller . It can be represented as a composition block , where . Let , where
Therefore, the observable trajectories of is denoted as , where
The composition contract of is stated as , where
According to Definition 11, , we have , and . Hence, .
For requirement 1 Next, we will compose the controller and controller for verifying requirement 1. We denote the composition of and by . We denote the by . We write , where
The observable trajectories of is denoted as , where
The composition contract of is defined as , and
, we have , and . Hence, .
Stage 2: correctness verification. Our primary goal in this step is to verify that the Simulink block diagram is correct for system contract . In terms of Definition 19, we get and , then, . According to Theorem 21, we have .
For requirement 2
We next turn to verify the correctness of the Simulink block diagrams for requirement 2. Similar to the method above, the controller can be represented as a composition block = , where . Then , where
Therefore, the observable trajectories of the subsystem is denoted as , where
Stage 1: verifying the Simulink block diagram satisfies the corresponding composition of contract.
The composition contract of is defined as , where
According to Definition 11, , we have , and . Hence, .
Next, we will compose the and to verify requirement 2. Let , where
The observable trajectories of are denoted as , where
The composition contract is defined as , and
Stage 2: correctness verification. Our main goal in this step is to verify that the Simulink block diagram () is a correct implementation of system contract . , we have , and . Hence, . In terms of Definition 19, we get . Then, . According to Theorem 21, we have .
In the example above, when an attacker adds a malicious logic bomb to Simulink, it can maliciously manipulate the input and output behaviors of any block in the block diagrams and the water level values read from the Sensor. This may lead to the block diagram’s behavior not satisfying the system’s formal specification. Considering from this perspective, our approach can identify and verify whether the designed CPS is planted with the logic bomb.
7. Conclusion and Future Work
In this paper, we presented a method to prove the correctness of Simulink block diagrams with discrete-time or continuous-time blocks using contract. This approach addressed the problem of proving that the system formal specifications are satisfied by composition and refinement of trajectories. We showed the usability of our proposals via a use case (as an example) which models the control system of a reservoir. Our method can improve the reliability of Simulink and reduce the development costs by performing early safety verification on verification of the target system.
In this work, we made the first step towards the contract-based verification of cyber-physical models in Simulink. Future work includes extending the work along several dimensions. First, this work considers single rate Simulink block diagrams. We will extend this work to consider the multiple sample times (multirate systems) diagrams. Another nontrivial extension involves applying our idea to prove the correctness of Simulink block diagrams mixture of discrete-time and continuous-time blocks. More challenging would be to develop a contract-based refinement approach to handle Stateflow. Second, this work only considers the blocks whose inputs-outputs can be explicitly represented through the mathematical relation. It is interesting to prove the correctness of the Simulink block diagrams, whose input-output behavior be expressed implicitly by a mathematical relation. Third, we plan to automatically verify the correctness of the Simulink block diagrams based on our method.
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that there is no conflict of interest regarding the publication of this article.
Acknowledgments
This work was funded in part by the Chongqing Graduate Research and Innovation Project (grant No. CYB20098), the National Natural Science Foundation of China (Nos. 62032019, 61732019, 61672435, and 62002298), and the Capacity Development Grant of Southwest University (SWU116007). We are grateful for the valuable comments from Prof. Xinxin Liu and Prof. Zheng Yang on the earlier versions of this paper. We thank the anonymous referees whose suggestions improved the presentation.