# Scalable Verification of Linear Controller Software

- 9 Citations
- 1.3k Downloads

## Abstract

We consider the problem of verifying software implementations of linear time-invariant controllers against mathematical specifications. Given a controller specification, multiple correct implementations may exist, each of which uses a different representation of controller state (e.g., due to optimizations in a third-party code generator). To accommodate this variation, we first extract a controller’s mathematical model from the implementation via symbolic execution, and then check input-output equivalence between the extracted model and the specification by similarity checking. We show how to automatically verify the correctness of C code controller implementation using the combination of techniques such as symbolic execution, satisfiability solving and convex optimization. Through evaluation using randomly generated controller specifications of realistic size, we demonstrate that the scalability of this approach has significantly improved compared to our own earlier work based on the invariant checking method.

## Keywords

Step Function Transition Equation Equivalence Check Symbolic Execution Linear Controller## 1 Introduction

Control systems are at the core of many safety- and life-critical embedded applications. Ensuring the correctness of these control system implementations is an important practical problem. Modern techniques for the development of control systems are model driven. Control design is performed using a mathematical model of the system, where both the controller and the plant are represented as sets of equations, using well established tools, such as Simulink and Stateflow.

Verification of the control system and evaluation of the quality of control is typically performed at the modeling level [3]. Once the control engineer is satisfied with the design, a software implementation of the controller is produced from the model using a generator such as Simulink Coder. To ensure that the generated implementation of the controller is correct with respect to its model, we ideally would like to have verified code generators that would guarantee that any generated controller correctly implements its model. In practice, however, code generators for control software are complex tools that are not easily amenable to formal verification, and are typically offered as black boxes. Subtle bugs have been found in earlier versions of commercially available code generators [22].

In the absence of verified code generators, it is desirable to verify instances of generated code against their models. In this paper, we consider an approach to perform such instance verification. Our approach is based on extracting a model from the controller code and establishing equivalence between the original and the extracted models. We limit our attention to linear time-invariant (LTI) controllers, since these are the most commonly used controllers in control systems. In such controllers, relations between the values of inputs and state variables, and between state variables and outputs, are linear functions of input and state variables with constant (i.e., time-invariant) coefficients.

Our technical approach relies on symbolic execution of the generated code. Symbolic expressions for state and output variables of the control function are used to reconstruct the model of the controller. The reconstructed model is then checked for input-output equivalence between the original and reconstructed model, using the well-known necessary and sufficient condition for the equivalence of two minimal LTI models. Verification is performed using real arithmetic. We account for some numerical errors by allowing for a bounded discrepancy between the models. We compare two approaches for checking the equivalence; one reduces the equivalence problem to an SMT problem, while the other uses a convex optimization formulation. We compare equivalence checking to an alternative verification approach introduced in [23], which converts the original LTI model into input-output based code annotations for verification at the code level.

The paper is organized as follows. Section 2 provides necessary background on LTI systems. Section 3 introduces the approach based on code annotations. Section 4 presents model extraction from code, followed by the equivalence checking in Sect. 5. Section 6 evaluates the performance of the approaches. In Sects. 7 and 8, we provide a brief overview of related work and conclude the paper.

## 2 Preliminaries

In this section, we present preliminaries on linear controllers and the structure of linear controller implementations (e.g., step function generated by Embedded Coder). We also describe a couple of motivating examples and the notations used in this paper.

*state-space representation*form

*k*, \(\mathbf {y}_k \in \mathbb {R}^m\) denotes the output vector of the controller at time

*k*, \(\mathbf {z}_k \in \mathbb {R}^n\) denotes the state vector of the controller. In addition, the size of the controller state

*n*is referred to as the size of the controller and we use a common assumption that the specified controller has minimal realization [26]; this implies that

*n*is also the degree of the controller (i.e., the degree of the denominator of its characteristic polynomial). Note that the matrices \(\mathbf {A} \in \mathbb {R}^{n \times n}\), \(\mathbf {B} \in \mathbb {R}^{n \times p}\), \(\mathbf {C} \in \mathbb {R}^{m \times n}\) and \(\mathbf {D} \in \mathbb {R}^{m \times p}\) together with the initial controller state \(\mathbf {z}_0\) completely specify an LTI controller. Thus, we will let \(\mathbf {\Sigma (A,B,C,D,z_\mathrm {0})}\) denote an LTI controller, or simply write \(\mathbf {\Sigma (A,B,C,D)}\) when the initial controller state \(\mathbf {z}_0\) is zero.

The model of LTI controllers can be implemented in software as a function that takes as input the current state of the controller and a set of input sensor values, and computes control output (i.e., inputs applied to the plant) and the new state of the controller. We refer to this function as the *step function*. The step function is called by the control software periodically, or whenever new sensor measurements arrive. We assume that data is exchanged with the step function through global variables.^{1} In other words, the input, output and state variables are declared in the global scope, and the step function reads both input and state variables, and updates both output and state variables as the effect of its execution. However, we note that this assumption does not critically limit our approach because it can be easily extended to support a different code interface for the step function.

### 2.1 Motivating Examples

We start by introducing two motivating examples that illustrate limitations of the straightforward verification based on the mathematical model from (1). This is caused by the fact that controller code might be generated by a code generator whose optimizations may potentially violate the model, while still guaranteeing the desired control functionality.

**A Scalar Linear Integrator.**We begin with an example from [23], where the controller should compute a scalar control input \({u}_k\) as a scaled sum of all previous measurements \({y}_i\in \mathbb {R}, i=0,1,...,k-1\) – i.e.,

**Multiple-Input-Multiple-Output Controllers.**The second example we will consider is a Multiple-Input-Multiple-Output (MIMO) controller, maintaining four states with two inputs and two outputs

In this example, the controllers \(\varSigma \) and \(\hat{\varSigma }\) are *similar*,^{2} meaning that if the same inputs \(\mathbf {y}_k\) are delivered to both controllers, the outputs of the controllers will be identical for all *k*, although the states maintained by the controllers will most likely be different. As a result, although it does not obey the state evolution of the initial controller \({\varSigma }\), the ‘diagonalized’ controller \(\hat{\varSigma }\) provides the same control functionality as \({\varSigma }\) at a significantly reduced computational cost – making it more suitable for embedded applications.

### 2.2 Problem Statements

The introduced examples illustrate that code generation tools for embedded systems could produce more efficient code that deviates from the initial controller model as specified in (1), while being functionally correct from the input-output perspective. Consequently, in this work we will focus on verification methods that facilitate reasoning about the correctness of linear controllers without relying on the state-space representation of the controller. We will compare our approach with a verification approach we introduced in [23] which, to enable verification at the code level, converts the original LTI model into input-output code annotations based on the controllers’ transfer functions. Thus, we start by providing an overview of the code annotation method for LTI controllers introduced in [23].

## 3 Overview of Invariant-Based Approach

*z*. To simplify the notation in this summary, we consider Single-Input-Single-Output (SISO) controllers, meaning that the transfer function

*G*(

*z*) takes the form

*n*is the size of the initial controller model (referred also as the degree of the transfer function). This allows us to specify the dependency between the controller’s input and output signals as the following difference equation [26]

## 4 Model Extraction from Linear Controller Implementation

In order to verify a linear controller implementation against its specification, we first extract an LTI model from the implementation (i.e., step function), and then compare it to the specification (i.e., the initial model). To obtain an LTI model from the step function, it is first necessary to identify the computation of the step function based on the program semantics. By the computation of a program, we mean how the execution of the program affects the global state.^{3} This is also known as the *big-step transition relation* of a program, which is the relation between states before and after the execution of the program. In the next subsection, we explain how to identify the big-step transition relation of the step function via symbolic execution.

### 4.1 Symbolic Execution of Step Function

According to the symbolic execution semantics [6, 7, 18], we symbolically execute the step function with symbolic inputs and symbolic controller state. When the execution is finished, we examine the effect of the step function on the global state where output and new controller state are produced as symbolic formulas.

Model extraction via symbolic execution may not be applicable to any arbitrary program (e.g., non-terminating program, file/network IO program). However, we argue that it is feasible when focusing on the linear controller implementations which are self-contained (i.e., no dependencies on external functions) and have simple control flows (e.g., for the sake of deterministic real-time behaviors). During symbolic execution, we check if each step of the execution satisfies certain rules (i.e., restrictions), otherwise it is rejected. The rules are as follows: first of all, the conditions of conditional branches should be always evaluated to concrete boolean values. We argue that the step functions of linear controllers are unlikely necessary to branch over symbolic values such as symbolic inputs or symbolic controller states. Moreover, in many cases, the upper bound of the loops of step functions are statically fixed based on the size of the controllers, so the loop condition can be evaluated to concrete values as well. This rule results in yielding the finite and deterministic symbolic execution path of the step function. The second rule is that it is not allowed to use symbolic arguments when calling the standard mathematical functions (e.g., sin, cos, log, exp) because the use of such non-linear functions may result in non-linear input-output relation of the step function. Moreover, it is also not allowed to call external libraries (e.g., file/network IO APIs, functions without definitions provided). This rule restricts the step function to be self-contained and to avoid using non-linear mathematical functions. Lastly, dereferencing a symbolic memory address is not allowed because the non-deterministic behavior of memory access is undesirable for controller implementations and may result in unintended information flow.

*t*is the number of variables used in the symbolic formula

*f*, \(v, v_i\) are the global variables, \(v^{(new)}\) denotes that the variable

*v*is updated with the symbolic formula on the right-hand side of the equation, the variable without the superscript “(new)” denotes the initial symbolic value of the variable (i.e., from the initial state before symbolic execution of the step function). We call this equation

*transition equation*.

### 4.2 Linear Time-Invariant System Model Extraction

*t*is the number of product terms, \(v \in V_{updated}\) is the updated variable, \(v_i \in V_{used}\) are the used variables, and \(c_i \in \mathbb {R}\) are the coefficients. When converting the transition equations into canonical form, we regard floating-point arithmetic expressions as real arithmetic expressions. The analysis of the discrepancy between them is left for future work. Instead, in the next section, the discrepancy issue between two LTI models due to numerical errors of floating-point arithmetic is addressed as the first step toward the full treatment of the problem.

*vec*(

*V*) denotes the vectorization of the set

*V*(e.g., \(vec(\{v_1,v_2,v_3\})= [v_1,v_2,v_3]^\mathrm {T}\)). This allows for rewriting each transition equation in terms of the state variable vector \(\mathbf {x}\) and the input variable vector \(\mathbf {u}\) as

*n*is the length of the state variable vector,

*p*is the length of the input variable vector and \(c_i, d_i \in \mathbb {R}\) are constants. Finally, we rewrite the transition equations as two matrix equations as follows

### *Remark 1*

In general, the size of the extracted model \(\mathbf {\hat{\Sigma }}\) may not be equal to the size of the initial controller model \(\mathbf {\Sigma }\) from (1) (i.e., *n*). As we assume that \(\mathbf {\Sigma }\) is minimal, if the obtained model has the size less than *n* it would clearly have to violate input-output (IO) requirements of the controller. However, if the size of \(\mathbf {\hat{\Sigma }}\) is larger than *n*, we consider a controllable and observable subsystem computed via Kalman decomposition [26] from the extracted model, as the \(\mathbf {\hat{\Sigma }(\hat{A},\hat{B},\hat{C},\hat{D})}\) model extracted from the code. Note that \(\mathbf {\hat{\Sigma }}\) is minimal in this case, and thus its size has to be equal to *n* to provide IO conformance with the initial model.

## 5 Input-Output Equivalence Checking Between Linear Controller Models

In order to verify a linear controller implementation against an LTI specification, in the previous section we described how to extract an LTI model from the implementation. This section introduces a method to check input-output (IO) equivalence between two linear controller models: (1) the original LTI specification and (2) the LTI model extracted from the implementation.

*similar*to each other. Two LTI models \(\mathbf {\Sigma (A,B,C,D)}\) and \(\mathbf {\hat{\Sigma }(\hat{A},\hat{B},\hat{C},\hat{D})}\) are said to be

*similar*if there exists a non-singular matrix \(\mathbf {T}\) such that

*similarity transformation matrix*[26]. Thus, given two minimal LTI models, the problem of equivalence checking between the models is reduced to the problem of finding a similarity transformation matrix for the models. The rest of this section explains how to formulate this problem as a satisfiability problem and a convex optimization problem.

### 5.1 Satisfiability Problem Formulation

*i*-th row and

*j*-th column of the matrix \(\mathbf {T}\). The following constraints rephrase the equations of (10) in an element-wise manner

### 5.2 Convex Optimization Problem Formulation

## 6 Evaluation

To evaluate our verification approach described in Sects. 4 and 5, we compared it to our earlier work based on invariant checking [23].

### 6.1 Verification Toolchain

We implemented an automatic verification framework (presented in Fig. 1) based on the proposed approach described in Sects. 4 and 5. We refer to this approach as similarity checking (SC)-based approach. Given a step function (i.e., C code), we employ the off-the-shelf symbolic execution tool PathCrawler [32] to symbolically execute the step function and generate a set of transition equations. The model extractor which implements the method in Sect. 4.2 extracts an LTI model from the transition equations. Finally, the equivalence checker based on the method in Sect. 5 decides the similarity between the extracted LTI model and the given specification (i.e., LTI model), and produces the verification result. The equivalence checker uses either the SMT solver CVC4 [4]^{4} or the convex optimization solver CVX [14] depending on the formulation employed, which is described in Sect. 5.

For the invariant checking (IC)-based approach described in Sect. 3, we use the toolchain Frama-C/Why3/Z3 to verify C code with annotated controller invariants [23]. The step function is annotated with the invariants as described in Sect. 3. Given annotated C code, Frama-C/Why3 [5, 9] generates proof obligations as SMT instances. The SMT solver Z3 [11]^{5} solves the proof obligations and produces the verification result (see [23] for more details).

### 6.2 Scalability Evaluation

To evaluate the SC-based approach compared to the IC-based approach, we randomly generate stable linear controller specifications (i.e., the elements of \(\mathbf {\Sigma (A,B,C,D)}\)). Since we observed that the controller dimension *n* dominates the performance (i.e., running time) of both approaches, we vary *n* from 2 to 14, and generate three controller specifications for each *n*. For each controller specification, we employ the code generator Embedded Coder to generate the step function in C. Since we use the LTI system block of Simulink for code generation, the structure of generated C code is not straightforward, having multiple loops and pointer arithmetic operations as illustrated in the step function [24]. This negatively affects the performance of the IC-based approach for reasons to be described later in this subsection. For a comparative evaluation, we use both SC-based and IC-based approaches to verify the generated step function C code against its specification. For each generated controller, we checked that IC-based and SC-based approaches give the same verification result, as long as both complete normally.

*n*increases, while the SC-based approach remains scalable. The main reason for this is that the IC-based approach requires the preprocessing of code [23], which is unrolling the execution of the step function multiple times (e.g., \(2n+1\) or \(3n+1\) times) as well as unrolling each loop in the step function \((n+1)\) times. Therefore, in contrast with the SC-based approach, the IC-based approach needs to handle the significantly increased lines of code due to unrolling, so it does not scale up.

Next, we evaluate the back-end of both approaches (i.e., constraint solving). Figure 3 shows the average running time of the back-ends of both approaches, where missing bars result from the lack of scalability of either the constraint solver used at this stage or the front-end tools. “SC-based (CVC4)” denotes the SMT-based formulation while “SC-based (CVX)” denotes the convex optimization-based formulation. Recall that the SC-based approach using CVC4 and the IC-based approaches employ the SMT solvers for constraint solving, which uses the arbitrary-precision arithmetic. We observe that the running time of the back-ends of those approaches exponentially increase as the controller dimension *n* increases because of the cost of the bignum arithmetic, while the SC-based approach using CVX remains scalable.

## 7 Related Work

Recently, there has been much attention to research on high-assurance control software for cyber physical systems (e.g., [1, 10, 12, 19, 20, 21, 28]). First of all, there has been a line of work focused on robust controller software implementations. For example, in [28], a model-based simulation platform is presented to analyze controllers’ robustness. In [1, 21], the authors present a fixed-point design method for robust, stable, error-minimized controller implementations. [19] presents a robustness analysis tool to analyze the uncertainties of measurements and plant states. In [10, 12], the authors address the synthesis of fixed-point controller software using SMT solvers. Moreover, there exists work on verifying the control-related properties of Simulink models using theorem proving [2]. Yet, the verification is done at the model level, not at the code level.

However, there has been less attention given to the code-level verification of controller software. In [20, 27], the authors present equivalence checking between Simulink diagrams and generated code. Yet, they are based on the compliance of the structures between Simulink models and code, instead of observational equivalence checking. In addition, there is a closely related work based on the concept of proof-carrying code for control software [13, 15, 30, 31]. The authors propose the code annotations for control-related properties based on Lyapunov functions, and introduce the PVS linear algebra libraries [15] to verify the properties. However, their focus is limited to only stability and convergence properties rather than the correctness of controller implementation against its model. Moreover, their approaches require the control of code generators, which may introduce intellectual property concerns. Our own earlier work [23] presents a method to verify the correctness of controller implementations by annotating the controllers’ invariants. However, the scalability of this method is challenged for real controller implementations with large state dimensions.

Finally, the model extraction technique has been used in software verification [8, 16, 17, 25, 29]. The authors in [8, 16, 17] extract finite state models from implementations to facilitate software model checking. [29] and [25] apply the symbolic execution technique to implemented source code to extract mathematical functional models and high-level state machine models, respectively.

## 8 Conclusion

We have presented an approach for the verification of linear controller implementations against mathematical specifications. By this, a higher degree of assurance for generated control code can be provided without trusting a code generator. We have proposed to use the symbolic execution technique to reconstruct mathematical models from linear time-invariant controller implementations. We have presented a method to check input-output equivalence between the specification model and the extracted model using the SMT formulation and the convex optimization formulation. Through the evaluation using randomly generated specification and code by Matlab, we showed that the scalability of our new approach has significantly improved compared to our own eariler work. Future work includes the analysis of the effect of floating-point calculations in control code.

## Footnotes

- 1.
This convention is used by Embedded Coder, a code generation toolbox for Matlab/Simulink.

- 2.
We formally define the similarity transform in Sect. 5.

- 3.
Note that we assume that data is exchanged with the step function via global variables.

- 4.
CVC4 was chosen among other SMT solvers because it showed the best performance for our QF_LRA SMT instances.

- 5.
Z3 was chosen among other SMT solvers because it showed the best performance for the generated proof obligations in our experiment.

## Notes

### Acknowledgments

This work was supported in part by NSF CNS-1505799, NSF CNS-1505701, and the Intel-NSF Partnership for Cyber-Physical Systems Security and Privacy. This material is based on research sponsored by DARPA under agreement number FA8750-12-2-0247. The U.S. Government is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright notation thereon. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of DARPA or the U.S. Government. This research was supported in part by Global Research Laboratory Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Science, ICT & Future Planning (2013K1A1A2A02078326) with DGIST.

## References

- 1.Anta, A., Majumdar, R., Saha, I., Tabuada, P.: Automatic verification of control system implementations. In: Proceedings of 10th ACM International Conference on Embedded Software, EMSOFT 2010, pp. 9–18 (2010)Google Scholar
- 2.Araiza-Illan, D., Eder, K., Richards, A.: Formal verification of control systems’ properties with theorem proving. In: UKACC International Conference on Control (CONTROL), pp. 244–249 (2014)Google Scholar
- 3.Aström, K.J., Murray, R.M.: Feedback Systems: An Introduction for Scientists and Engineers. Princeton University Press, Princeton (2010)Google Scholar
- 4.Barrett, C., Conway, C.L., Deters, M., Hadarean, L., Jovanović, D., King, T., Reynolds, A., Tinelli, C.: CVC4. In: Gopalakrishnan, G., Qadeer, S. (eds.) CAV 2011. LNCS, vol. 6806, pp. 171–177. Springer, Heidelberg (2011)CrossRefGoogle Scholar
- 5.Bobot, F., Filliâtre, J.C., Marché, C., Paskevich, A.: Why3: shepherd your herd of provers. In: Boogie 2011: First International Workshop on Intermediate Verification Languages, pp. 53–64 (2011)Google Scholar
- 6.Botella, B., Gotlieb, A., Michel, C.: Symbolic execution of floating-point computations. Softw. Test. Verification Reliab.
**16**(2), 97–121 (2006)CrossRefGoogle Scholar - 7.Clarke, L.: A system to generate test data and symbolically execute programs. IEEE Trans. Softw. Eng.
**3**, 215–222 (1976)MathSciNetCrossRefGoogle Scholar - 8.Corbett, J.C., Dwyer, M.B., Hatcliff, J., Laubach, S., Păsăreanu, C.S., Bby, R., Zheng, H.: Bandera: extracting finite-state models from java source code. In: Proceedings of the 2000 International Conference on Software Engineering, pp. 439–448. IEEE (2000)Google Scholar
- 9.Cuoq, P., Kirchner, F., Kosmatov, N., Prevosto, V., Signoles, J., Yakobowski, B.: Frama-C. In: Eleftherakis, G., Hinchey, M., Holcombe, M. (eds.) SEFM 2012. LNCS, vol. 7504, pp. 233–247. Springer, Heidelberg (2012)CrossRefGoogle Scholar
- 10.Darulova, E., Kuncak, V., Majumdar, R., Saha, I.: Synthesis of fixed-point programs. In: Proceedings of 11th ACM International Conference on Embedded Software, EMSOFT 2013, pp. 22:1–22:10 (2013)Google Scholar
- 11.de Moura, L., Bjørner, N.S.: Z3: an efficient SMT solver. In: Ramakrishnan, C.R., Rehof, J. (eds.) TACAS 2008. LNCS, vol. 4963, pp. 337–340. Springer, Heidelberg (2008)CrossRefGoogle Scholar
- 12.Eldib, H., Wang, C.: An SMT based method for optimizing arithmetic computations in embedded software code. IEEE Trans. Comput. Aided Des. Integr. Circ. Syst.
**33**(11), 1611–1622 (2014)CrossRefGoogle Scholar - 13.Feron, E.: From control systems to control software. IEEE Control Syst.
**30**(6), 50–71 (2010)MathSciNetCrossRefGoogle Scholar - 14.Grant, M., Boyd, S.: CVX: Matlab software for disciplined convex programming, version 2.1., March 2014. http://cvxr.com/cvx
- 15.Herencia-Zapana, H., Jobredeaux, R., Owre, S., Garoche, P.-L., Feron, E., Perez, G., Ascariz, P.: PVS linear algebra libraries for verification of control software algorithms in C/ACSL. In: Goodloe, A.E., Person, S. (eds.) NFM 2012. LNCS, vol. 7226, pp. 147–161. Springer, Heidelberg (2012)CrossRefGoogle Scholar
- 16.Holzmann, G.J., Smith, M.H.: Software model checking: extracting verification models from source code. Softw. Test. Verification Reliab.
**11**(2), 65–79 (2001)CrossRefGoogle Scholar - 17.Holzmann, G.J., Smith, M.H.: An automated verification method for distributed systems software based on model extraction. IEEE Trans. Softw. Eng.
**28**(4), 364–377 (2002)CrossRefGoogle Scholar - 18.King, J.C.: Symbolic execution and program testing. Commun. ACM
**19**(7), 385–394 (1976)MathSciNetCrossRefzbMATHGoogle Scholar - 19.Majumdar, R., Saha, I., Shashidhar, K.C., Wang, Z.: CLSE: closed-loop symbolic execution. In: Goodloe, A.E., Person, S. (eds.) NFM 2012. LNCS, vol. 7226, pp. 356–370. Springer, Heidelberg (2012)CrossRefGoogle Scholar
- 20.Majumdar, R., Saha, I., Ueda, K., Yazarel, H.: Compositional equivalence checking for models and code of control systems. In: 52nd Annual IEEE Conference on Decision and Control (CDC), pp. 1564–1571 (2013)Google Scholar
- 21.Majumdar, R., Saha, I., Zamani, M.: Synthesis of minimal-error control software. In: Proceedings of 10th ACM International Conference on Embedded Software, EMSOFT 2012, pp. 123–132 (2012)Google Scholar
- 22.Mathworks: Bug Reports for Incorrect Code Generation. http://www.mathworks.com/support/bugreports/?product=ALL&release=R2015b&keyword=Incorrect+Code+Generation
- 23.Pajic, M., Park, J., Lee, I., Pappas, G.J., Sokolsky, O.: Automatic verification of linear controller software. In: 12th International Conference on Embedded Software (EMSOFT), pp. 217–226. IEEE Press (2015)Google Scholar
- 24.Park, J.: Step function example. http://dx.doi.org/10.5281/zenodo.44338
- 25.Pichler, J.: Specification extraction by symbolic execution. In: 2013 20th Working Conference on Reverse Engineering (WCRE), pp. 462–466. IEEE (2013)Google Scholar
- 26.Rugh, W.J.: Linear System Theory. Prentice Hall, Upper Saddle River (1996)zbMATHGoogle Scholar
- 27.Ryabtsev, M., Strichman, O.: Translation validation: from simulink to C. In: Bouajjani, A., Maler, O. (eds.) CAV 2009. LNCS, vol. 5643, pp. 696–701. Springer, Heidelberg (2009)CrossRefGoogle Scholar
- 28.Sangiovanni-Vincentelli, A., Di Natale, M.: Embedded system design for automotive applications. IEEE Comput.
**10**, 42–51 (2007)CrossRefGoogle Scholar - 29.Wang, S., Dwarakanathan, S., Sokolsky, O., Lee, I.: High-level model extraction via symbolic execution. Technical reports (CIS) Paper 967, University of Pennsylvania (2012). http://repository.upenn.edu/cis_reports/967
- 30.Wang, T., Jobredeaux, R., Herencia, H., Garoche, P.L., Dieumegard, A., Feron, E., Pantel, M.: From design to implementation: an automated, credible autocoding chain for control systems. arXiv preprint (2013). arxiv:1307.2641
- 31.Wang, T.E., Ashari, A.E., Jobredeaux, R.J., Feron, E.M.: Credible autocoding of fault detection observers. In: American Control Conference (ACC), pp. 672–677 (2014)Google Scholar
- 32.Williams, N., Marre, B., Mouy, P., Roger, M.: PathCrawler: automatic generation of path tests by combining static and dynamic analysis. In: Dal Cin, M., Kaâniche, M., Pataricza, A. (eds.) EDCC 2005. LNCS, vol. 3463, pp. 281–292. Springer, Heidelberg (2005)Google Scholar