Model-Based Automatic Test Generation for Simulink/Stateflow usingExtended Finite Automaton

Meng Li, Member IEEE, and Ratnesh Kumar, Fellow IEEEDept. of Electrical and Computer Engineering

Iowa State UniversityAmes, IA 50010, USA

Abstract— Simulink/Stateflow is a popular commercialmodel-based development tool for many industrial domains. Forsafety and security concerns, verification and testing must beperformed on the Simulink/Stateflow designs and the generatedcode. In this paper, we present an automatic test generationapproach for Simulink/Stateflow based on its translation toInput/Output Extended Finite Automata (I/O-EFA) that wehave developed in our prior works. The test generation problemrequires identifying the executable paths of the I/O-EFA modeland also generating a test input for those paths. Note inorder to execute a path, a certain sequence of other pathsmust be executed first, which we automatically identify. Theapproach is implemented by applying two different techniques,model checking and constraint solving. Both test generationimplementations are validated by a case study. The results showthat both implementations can generate test cases as expectedand the implementation based on constraint solving is in generalfaster.

I. INTRODUCTION

Simulink/Stateflow [1] is a model-based development tool,which is widely used in many industrial domains, such aspower systems, nuclear plants, aircraft, and automotives.Code generators are used within the Simulink/Stateflow toautomatically generate the embedded software for the targetsystem from the Simulink/Stateflow diagram, and therebyconsiderably increasing the productivity.

The existing code generators cannot guarantee that thegenerated code complies correctly the functional behaviorsspecified in the design. Verification and testing of the gener-ated code is necessary to find errors in the code generationprocess and thus avoid software faults in any future use ofthe system.

Model-based test generation is an essential step in themodel-based development process. It aims to validate that theobject code to be implemented in the target processor com-plies with the design requirements. For Simulink/Stateflow,model-based test generation intends to validate whether thegenerated code (for example ANSI C) preserves the func-tional behaviors of the Simulink/Stateflow diagram.

Several type of errors may occur in the implementationprocess from the Simulink/Stateflow diagram to the targetcode, such as:

The research was supported in part by the NationalScience Foundation under the grants NSF-ECS-0601570, NSF-ECCS-0801763, NSF-CCF-0811541, and NSF-ECCS-0926029;email:mengl,rkumar@iastate.edu

• Errors in the Simulink/Stateflow diagram models willget carried over.

• Errors in the automatic code generator for theSimulink/Stateflow diagram caused for example by fi-nite precision arithmetic or timing constraints.

• Any human errors in the selection of code generationoptions, library naming/inclusion, and others.

A model-based approach to reveal these errors is to createa set of test cases from Simulink/Stateflow and then executethem on the generated code to see if the test passes. Anyfailed test cases can be used to find the errors introducedduring the code generation process.

Since Simulink/Stateflow has originally been designedfor the simulation purposes, automated test generation forSimulink/Stateflow diagram is greatly needed to identifythe errors. Several authors have tried different ways oftest generation and verification for Simulink/Stateflow di-agram. Scaife et al. [2] are able to translate a subset ofSimulink/Stateflow into Lustre and verify the model usinga model checking tool called Lesar. Gadkari et al. [3] havetranslated Simulink/Stateflow to a formal language, calledSymbolic Analysis Laboratory (SAL), and they generate testcases based on SAL model checking. Reactis [4] and T-VEC [5] are two popular commercial tools for automatedtest generation for Simulink/Stateflow models. In our case,we derive the test suite based on the translation fromSimulink/Stateflow to an automaton, which preserves thediscrete behaviors (behaviors observed at discrete time stepswhen the inputs are sampled and the outputs are computed).

In our previous works [6] [7] [8], we introduced a re-cursive method to translate a Simulink/Stateflow diagram toan Input/Output Extended Finite Automata (I/O-EFA), whichis a formal model of reactive untimed infinite state system,amenable to formal analysis. It captures each computationcycle of Simulink/Stateflow in form of an automata extendedwith data-variables to capture internal states and also the in-put and output variables. This paper discusses the method togenerate test cases for the Simulink/Stateflow diagram basedon the corresponding I/O-EFA derived using the approachof [6] [7] [8]. To provide coverage for all computation flowsof a Simulink/Stateflow diagram which corresponds to theexecution paths in the translated I/O-EFA model, each execu-tion path is analyzed for feasibility and reachability, and testcases are generated accordingly. The test generation approach

8th IEEE International Conference on Automation Science and EngineeringAugust 20-24, 2012, Seoul, Korea

978-1-4673-0430-6/12/$31.00 ©2012 IEEE 857

is implemented by using two techniques, model-checkingand constraint solving using mathematical optimization. Themodel-checking based implementation abstracts the I/O-EFAand checks each execution path for eventual reachability(note in order to execute a path some other sequence ofpaths may have to be executed in earlier cycles and hencethe requirement of eventual reachability); while the con-straint solving based implementation recursively evaluatesthe longer and longer path-sequences and the associatedpredicate for reachability. The test cases are generated fromthe counterexamples (resp. path-sequence predicates) for thecase of model-checking (resp. constraint solving) process.

We have integrated the translation tool along with boththe test generation implementations into an automated testgeneration tool, written in Matlab script. A simple exampleof a counter has been used as the case study to validateand compare the test generation implementations. The testgeneration results show that both of the implementationmethods can generate the expected test cases while theconstraint solving based approach is in general faster. Thecontributions of the paper are:• We have developed a systematic test generation method

for I/O-EFA models that representing the computationsof a Simulink/Stateflow diagram.

• Two implementation techniques, model-checking andconstraint solving, are implemented and compared.

• We have developed an automated test generation toolbased on the above two techniques within the Matlabenvironment.

II. INTRODUCTION TO I/O-EFA [8]An I/O-EFA is a symbolic description of a reactive un-

timed infinite state system in form of an automaton, extendedwith discrete variables of inputs, outputs and data.

Definition 1: An I/O-EFA is a tuple P =(L,D,U, Y,Σ,∆, L0, D0, Lm, E), where• L is the set of locations (symbolic-states),• D = D1 × · · · ×Dn is the set of data (numeric-states),• U = U1 × · · · × Um is the set of numeric inputs,• Y = Y1 × · · · × Yp is the set of numeric outputs,• Σ is the set of symbolic-inputs,• ∆ is the set of symbolic-outputs,• L0 ⊆ L is the set of initial locations,• D0 ⊆ D is the set of initial-data values,• Lm ⊆ L is the set of final locations,• E is the set of edges, and each e ∈ E is a 7-tuple,e = (oe, te, σe, δe, Ge, fe, he), where

– oe ∈ L is the origin location,– te ∈ L is the terminal location,– σe ∈ Σ ∪ {ε} is the symbolic-input,– δe ∈ ∆ ∪ {ε} is the symbolic-output,– Ge ⊆ D × U is the enabling guard (a predicate),– fe:D × U → D is the data-update function, and– he:D × U → Y is the output-assignment function.

I/O-EFA P starts from an initial location l0 ∈ L0 withinitial data d0 ∈ D0. When at a state (l, d), a transitione ∈ E with oe = l is enabled, if the input σe arrives, and the

data d and input u are such that the guard Ge(d, u) holds.P transitions from location oe to location te through theexecution of the enabled transition e and at the same time thedata value is updated to fe(d, u), whereas the output variableis assigned the value he(d, u) and a discrete output δe isemitted. For notational convenience, if d ∈ D and u ∈ Uis such that for an edge e ∈ E, Ge(d, u) hold, then lettingd′ := fe(d, u) and y := he(d, u), we write (oe, d)

σe,u,δe,y−→(te, d

′) to denote the state transition from (oe, d) to (te, d′)

under the input (σe, u) and producing the output (δe, y).

III. TEST GENERATION BASED ON I/O-EFA

Our previous works [6] [7] [8] presented a translationapproach from a Simulink/Stateflow diagram to an I/O-EFA model while preserving the discrete behaviors observedat sample times. In such an I/O-EFA model, each tran-sition sequence from the initial location l0 back to theinitial location l0 through the time advancement edge e =(lm, l0,−,−,−,−, {k := k + 1}) represents a computationsequence of the Simulink/Stateflow diagram at a samplingtime. Note for the time advancement edge e, it holds thathe ≡ {k := k + 1} that advances the discrete time counterby a single step. Such a transition sequence is called acomputation path as defined next.

Definition 2: A computation path (or simply a c-path) πin an I/O-EFA P = (L,D,U, Y,Σ,∆, L0, D0, Lm, E) is a fi-nite sequence of edges π ∈ {eπ0 ...eπ|π|−1 ∈ E

∗|oeπ0 , teπ|π|−1∈

L0, heπ|π|−1≡ {k := k + 1},∀i ∈ [1, |π| − 1] : oeπi = teπi−1

}.Our test generation approach is to find a set of input

sequences, also called test cases, which execute a certainset of computation sequences specified by a desired cov-erage criterion. For this, first the paths, representing thosecomputation sequences, are located in the I/O-EFA model,and next the input sequences which activate those pathsare obtained. Our previous Simulink/Stateflow to I/O-EFAtranslation approach formalizes and automates this mappingfrom computation sequences of Simulink/Stateflow diagramto the c-paths in the translated I/O-EFA model.

Example 1: Consider the Simulink diagram Ψ of abounded counter shown in Figure 1, consisting of an enabledsubsystem block and a saturation block. The output y5

increases by 1 at each sample-period when the control inputu is positive, and y5 resets to its initial value when thecontrol input u is not positive. The saturation block limitsthe value of y5 in the range between −0.5 and 7. Thetranslated I/O-EFA P using the method of [6] is shown inFigure 2. Each c-path in P represents a possible computationof the counter at a sampling instant. For example, the pathπ3 = e2e8e10e12e13e19e20e21 in I/O-EFA P represents the“reset” behavior, which is the computation sequence of theSimulink diagram Ψ in which the input is zero so thatthe subsystem is disabled and its output remains as theinitial level and hence the saturation is not triggered in thesaturation block. There are totally 18 c-paths in the I/O-EFAP , representing all 18 computation sequences in the Simulinkdiagram Ψ.

858

Fig. 2. I/O-EFA of a Counter System

Fig. 1. Simulink Diagram of a Counter System

Some of the computation sequences involving certainsequence of Simulink/Stateflow computations may not bepossible. This property is made transparent in our I/O-EFAby showing conflict among the conditions along the corre-sponding c-paths. In Example 1, five out of 18 computationsequences are possible and the corresponding five c-paths inI/O-EFA are valid. As an example consider an invalid compu-tation sequence “subsystem disabled” and “saturation reachesupper limit”. Since the disabled subsystem generates aninitial output 2, which is within the saturator’s limit, the sat-urator cannot reach its upper limit. This conflict also showsup in the corresponding c-path π5 = e2e8e9e12e13e19e20e21

over the edges e2 and e9, where y5(k) := 2 on edge e2,whereas y5(k) > 7 on edge e9.

Besides the conflict among the conditions along the edgesof a path, some of the impossibilities of certain computationsequences are caused by the initial condition of the system.Consider the saturation condition y5(k) < −0.5 in Example1. None of the computation sequences with this saturationcondition can be executed, since the counter output startsfrom zero and increments by one each time it counts, andthus the count can never be less than zero. The I/O-EFA

model also captures these impossible computation sequencesby showing the corresponding c-paths as unreachable fromthe initial conditions.

Based on the above discussion, the test generation problemfor Simulink/Stateflow can be converted to finding the inputsequences that execute the corresponding c-paths in the I/O-EFA. We obtain the feasible and reachable paths and choosea subset of these paths satisfying a desired coverage criterion.

In summary, our I/O-EFA based test generation forSimulink/Stateflow has the following steps.• Translate the Simulink/Stateflow diagram to I/O-EFA.• Find all the paths in I/O-EFA.• Analyze the paths in I/O-EFA for feasibility and reach-

ability.• Invalid paths are reported for model soundness and

robustness analysis.• Valid paths satisfying the coverage criterion are used to

generate a set of test cases for activating them.The translation method is implemented in our previous

work. The remaining challenges to implement this test gen-eration approach are listed as follows.• How to identify the valid paths. The feasibility of these

paths relies on not only itself but also the initial conditionand other paths that may be executed as prefixes.• How to obtain the input sequences activating the valid

paths. Some of the valid paths cannot be activated at the veryfirst time step. These paths require some prefix before theycan be activated.

In the next section, we discuss the implementations of ourI/O-EFA based test generation approach to deal with thesechallenges.

IV. IMPLEMENTATION OF TEST GENERATION APPROACH

The proposed test generation approach forSimulink/Stateflow has been implemented by applying twodifferent methods. Our previous translation tool SS2EFAhas been integrated with these two implementations tosupport the translation from Simulink/Stateflow diagram toI/O-EFA. The following discussion focuses on the part oftest generation to be executed following the translation step.

859

A. Implementation using Model-CheckingModel-checking is a method to check automatically

whether a model of a system meets a given specification.NuSMV [9] is an open source symbolic model checker,which supports the CTL and LTL expressed specificationanalysis and provides interface to Matlab, so that the testgeneration tool (written in Matlab script) can call NuSMVfor model-checking.

In this implementation, paths in I/O-EFA are checkedagainst the abstracted I/O-EFA model in NuSMV for fea-sibility and reachability. Since NuSMV only allows for therepresentation of finite state systems, the translated I/O-EFAis first converted into a finitely abstracted transition systemas defined in Definition 3 below.

The finite abstraction of the model is based on the imple-mentation requirements. Most of the real world systems havefinite data space and running time. The finite abstraction isimplemented in NuSMV input language as described below.• Variable “steplimit” is set to a value to limit the number

of time steps the system can evolve, i.e. to upper bound thediscrete time counter k < steplimit in the I/O-EFA model.In the NuSMV file, when the system evolves exceeding thedefined value of “steplimit”, the variable “location” is giventhe value “deadend” and has no further outgoing transitions.• Variable “precision” is the limit for the number of

significant digits. Since NuSMV can only verify integervalues, “precision” determines how the non-interger valuein the I/O-EFA model can be transformed into integer. Eachnon-integer value is transformed as follows: valuenew =round(valueold ∗ 10precision), where valueold is the valuein the I/O-EFA model, and valuenew is the value in NuSMVfile.• Each variable dj is converted to an integer with upper

limit dmaxj × 10precision and lower limit dminj × 10precision,so that data space is finite. dmaxj and dminj are determinedby the requirements on the system.

Definition 3: Given an I/O-EFA P =(L,D,U, Y,Σ,∆, L0, D0, Lm, E), its finite abstracted tran-sition system P f is a tuple P f = (S,Uf , Y f ,Σ, Ef , S0),where• S = L × Df is the set of its states, where Df is the

finite abstraction of D,• Ef := {((l1, df1 ), σ, uf , δ, yf , (l2, d

f2 )) | ∃d1 ∈ df1 , u ∈

uf , y ∈ yf , d2 ∈ df2 : (l1, d1)σ,u,δ,y−→ (l2, d2)} is its set

of transitions,• S0 = L0 ×Df

0 is the set of its initial states, where Df0

is the finite abstraction of D0,• Uf is the finite abstraction of U ,• Y f is the finite abstraction of Y .The finite abstracted transition system is implemented in

the NuSMV input language, where:• The locations L of the I/O-EFA model is set as a variable

and each location li is a value for the variable “locations”,• Each discrete variable dj in the I/O-EFA has its cor-

responding variable in NuSMV file. Data update functionsfe:D × U → D are expressed by the “next()” functions inthe assignment part of NuSMV file,

• Each input variable uk is defined in the NuSMV modelas a nondeterministic variable. It can choose any value in itsrange at the beginning of each time-step.• Edges E in I/O-EFA model are mapped to a variable

“edgeNum”, and each edge ei corresponds to an integer valueof variable “edgeNum”. This integer value is determined bythe edge number in the I/O-EFA model. Thus, a sequence of“edgeNum” value in NuSMV file represents a sequence ofedges, i.e. a path, in the I/O-EFA model.

The corresponding NuSMV file is used to check if the c-paths in the I/O-EFA model are reachable. This is done asan instance of finding a counterexample as prescribed in thefollowing algorithm.

Algorithm 1: A c-path π = eπ0 ...eπ|π|−1 of an I/O-EFA

P = (L,D,U, Y,Σ,∆, L0, D0, Lm, E) is determined to bereachable if in the finite abstraction P f |= φ holds, where φis the CTL formula EF (eπ0 ∧EX(eπ1 ∧ · · ·EXeπ|π|−1) · · · ),meaning path π can eventually be activated in the finiteabstraction P f . An input sequence that makes π eventuallyexecutable is found as a counterexample to the model-checking problem P f |= ¬φ.

If a counterexample for P f |= ¬φ is found, then P f |= φholds, and the sequence of inputs within the counterexampleis a test case activating the path π. The final test suite is theset of input sequences obtained from a subset of reachablepaths Π satisfying a desired coverage criterion.

In summary, the model-checking based test generationimplementation generates the test cases by the followingsteps.• Translate the Simulink/Stateflow diagram into I/O-EFA

model;• Map the I/O-EFA model to the corresponding NuSMV

file;• Extract all the paths from the I/O-EFA model and

translate them into corresponding CTL specifications;• Check the CTL representations of the paths against the

NuSMV model. Select the reachable paths satisfying thecoverage criterion and the set of input sequences activatingthose paths as the test suite. Report the unreachable pathsfor the analysis of model soundness and robustness.

The above implementation utilizes the existing modelchecker NuSMV and automates the test generation forSimulink/Stateflow. However, model-checking process istime-consuming as the state space explodes and the finiteabstraction may also cause problems in the test generation.So we investigate another approach as described next.B. Implementation using Constraint Solving

Mathematical optimization is used to check feasibility ofa set of constraints and to select a best element from a set ofavailable alternatives. The standard form of an optimizationproblem is:

minimizex f(x)subject to gi(x) ≤ 0, i = 1, . . . ,m

hi(x) = 0, i = 1, . . . , pwhere• f(x) : Rn → R is the objective function to be

minimized over the variable x,

860

• gi(x) ≤ 0 are called inequality constraints, and• hi(x) = 0 are called equality constraints.Finding whether a c-path π of an I/O-EFA is reachable

can be converted to a constraint solving problem, which isan optimization problem without regard to an objective valueas follows:

minimizex≡(d,u,y) 1subject to Pπ(x)

where, Pπ(x) is called the path-predicate of the path π.It is a set of conditions activating the path π. The aboveconstraint solving problem has solution if the path predicatePπ(x) is satisfiable (does not equate to False). The pathpredicate Pπ along with its data dπ and output yπ can beobtained as follows.

Algorithm 2: For a path π = eπ0 ...eπ|π|−1, its path-

predicate Pπ can be computed recursively backward, anddata dπ and output yπ can be computed recursively forwardas:

Base step:Pπ|π|(d, u, y) := True;dπ0 (d, u, y) := d;yπ0 (d, u, y) := y.Recursion step:Pπj−1(d, u, y) := Geπj−1

(d, u, y) ∧Pπj (feπj−1

(d, u, y), u, heπj−1(d, u, y));

dπj+1(d, u, y) := fπej (dπj (d, u, y), u, yπj (d, u, y));

yπj+1(d, u, y) := heπj ((dπj (d, u, y), u, yjπ (d, u, y)).Termination step:Pπ(d, u, y) := Pπ0 (d, u, y);dπ(d, u, y) := dπ|π|(d, u, y);yπ(d, u, y) := yπ|π|(d, u, y).Note: If any of Ge is undefined, it is simply assumed

true, ie, Ge(d, u, y) = True, and similarly if any of heis undefined, then it is simply assumed to be the same asidentity, ie, he(d, u, y) = y.

Constraint solving problem is constructed to check ifPπ(d, u, y) 6= False, in which case, the path π is feasible.The feasible paths obtained in Algorithm 2 are the candidatepaths for test generation. They are further checked to seeif they can be reached from the initial condition, i.e. ifthere exists a feasible path-sequence Π starting at the initialcondition and ending with the path under evaluation forreachability. The algorithm to determine the feasibility andreachability of a path-sequence Π is as follows.

Algorithm 3: Given a path-sequence Π = π0 . . . π startingat the initial condition I(d, u, y) ending with the path π,the feasibility/reachability of Π can be checked recursivelybackward as:

Base step:PΠ|Π|(d, u, y) := Pπ;

Recursion step:PΠj−1(d, u, y) := P

πjj−1 ∧ PΠ

j (dπjj−1, uj , y

πjj−1);

Termination condition:If PΠ

j (d, u, y) = False, then Π is infeasible and alsounreachable, stop;

If PΠj (d, u, y) 6= False and j 6= 0, then decrement j and

return to recursion step;

If j = 0, then Π is reachable iff PΠj (d, u, y)∧I(d, u, y) 6=

False, stop.Given a feasible path π, if none of the path-sequence

with |Π| <= steplimit ending with π is reachable, π isunreachable within the steplimit. Otherwise, π is reachable.Note steplimit is the test case length requirement of thesystem.

Given a feasible path-sequence Π = π0...π ending withpath π, a test input sequence tπ = u0...u|Π|−1 activatingthe reachable path π is obtained by letting uj ∈ Pπj , j =0...|Π| − 1. This input sequence tπ is the test case for pathπ.

The constraint solving based test suite is derived with anopen source optimization tool CVX [10], written in Matlab.Our test generation tool calls the CVX tool to check thefeasibility of the problem.

In summary, this constraint solving based test generationimplementation generates the test cases using the followingsteps.• Translate the Simulink/Stateflow diagram into I/O-EFA

model;• Extract all the paths from the I/O-EFA.• Apply Algorithm 2 to obtain the feasible paths;• Apply Algorithm 3 to obtain the reachable paths (the test

cases are generated based on the reachable paths satisfyingthe coverage criterion);• Report the unreachable paths identified in the previous

two steps for the analysis of model soundness and robustness.The above implementation applies the constraint solving

to solve for the recursively obtained path predicates. Thismethod does not require finite abstraction of the data spaceand loading of the model in another tool. This implemen-tation is thus exact (requiring no abstraction) and is able togenerate test cases faster than the implementation based onthe model checker.

V. VALIDATION OF TEST GENERATIONIMPLEMENTATIONS

Both of the test generation implementations describedabove, as well as the Simulink/Stateflow to I/O-EFA trans-lation tool, have been incorporated in an automated testgeneration tool. Upon specifying a source Simulink/Stateflowmodel file, both of our implementation methods can beexecuted to output the test suite for the correspondingSimulink/Stateflow diagram.

Example 2: Model Checker based Test Generator: Con-sider the I/O-EFA model (see Figure 2) of the countersystem (see Figure 1). By specifying steplimit = 10,precision = 0, all variables within [−2, 10], u ∈ {0, 1},and path-covered criterion (all paths be covered), the modelchecker based test generator generates four reachable pathsand the corresponding test cases are shown in Table I.

The test generation time (using Intel Core 2 Duo P84002.27GHz, 2GB RAM) is 349.3 seconds and the results areas expected.

Example 3: Constraint Solving based Test Generator:Consider the same I/O-EFA model (see Figure 2) of thecounter system (see Figure 1). By specifying steplimit =

861

TABLE IREACHABLE PATHS AND TEST CASES FROM IMPLEMENTATION WITH

MODEL-CHECKING

Path Test Case (u at each sampletime)

e0e3e4e5e6e7e8e10e12e14e15e16e17e18e19e20e21

1

e1e3e4e5e6e7e8e10e12e14e15e16e17e18e19e20e21

1, 1

e1e3e4e5e6e7e8e9e12e14e15e16e17e18e19e20e21

1, 1, 1, 1, 1, 1, 1, 1, 1

e2e8e10e12e13e20e21 0

TABLE IIFEASIBLE PATHS FROM IMPLEMENTATION WITH CONSTRAINT SOLVING

PathNo.

Path Predicate Path Data Path Outputs

π0 u(k) > 0∧ d(k) := 0, y2(k) := 0

d′ = 0 d′ := 1,

y3 := 1,

y5(k) := 0,

y4(k) := 1,

d(k + 1) := 1,

k := k + 1

π1 u(k) > 0∧ y3(k) := 1, y2(k) := d(k)

d′ = 1∧ y5(k) := d(k),

−0.5 ≤ d(k) y4(k) := d(k) + 1,

≤ 7 d(k+1) := d(k)+1,

k := k + 1

π2 u(k) > 0∧ y3(k) := 1, y2(k) := 7

d′ = 1∧ y5(k) := d(k),

d(k) > 7 y4(k) := d(k) + 1,

d(k+1) := d(k)+1,

k := k + 1

π3 u(k) > 0∧ y3(k) := 1, y2(k) := −0.5d′ = 1∧ y5(k) := d(k),

d(k) < −0.5 y4(k) := d(k) + 1,

d(k+1) := d(k)+1,

k := k + 1

π4 u(k) ≤ 0 y5(k) := 2, y2(k) := 2

d′ := 0,

d(k + 1) := d(k),

k := k + 1

10, u ∈ {0, 1}, and path-covered criterion (all paths becovered), the constraint solving based test generator providesfive feasible paths as shown in Table II and four of them arereachable (π3 is identified as unreachable). The test cases aregenerated as shown in Table III.

The test generation time (using Intel Core 2 Duo P84002.27GHz, 2GB RAM) is 102.7 seconds and the results areas expected.

The two test generators provide identical test cases regard-ing the same Simulink/Stateflow diagram and specifications.Constraint solving based implementation is able to obtainthe result about two times faster than model checker basedimplementation.

TABLE IIITEST CASES FROM IMPLEMENTATION WITH CONSTRAINT SOLVING

Path Number Test Case (u at each sample time)

π0 1

π1 1, 1

π2 1, 1, 1, 1, 1, 1, 1, 1, 1

π4 0

VI. CONCLUSIONWe presented an Input/Ouput Extended Finite Au-

tomata (I/O-EFA) based test generation approach forSimulink/Sateflow. While preserving the discrete behaviors,a Simulink/Stateflow diagram is translated to an I/O-EFAmodel, with each path of the I/O-EFA model representinga computation sequence of the Simulink/Stateflow diagram.Paths are inspected for feasibility and reachability. Theyare further used for test generation and model soundnessanalysis. Two techniques, model-checking and constraintsolving, are applied to implement this approach. Model-checker based implementation maps I/O-EFA to a finiteabstracted transition system modeled in NuSMV file. Testcases are generated by checking each path in I/O-EFA againstthe model in NuSMV. Constraint solving based implemen-tation utilizes two algorithms to recursively compute thepath and path-sequence predicate respectively for capturingthe feasibility problems. Test cases are obtained from thepredicates of the reachable paths. The performance of bothimplementations was evaluated with a case study. The resultsshowed that both implementations can generate the expectedresults and the implementation based on constraint solvingis superior to the implementation based on model checkerwith respect to the speed of test generation.

REFERENCES

[1] Simulink/Stateflow, “http://www.mathworks.com/products/simulink/.”[2] N. Scaife, C. Sofronis, P. Caspi, S. Tripakis, and F. Maraninchi,

“Defining and translating a ”safe” subset of simulink/stateflow intolustre,” in EMSOFT ’04: Proceedings of the 4th ACM internationalconference on Embedded software. New York, NY, USA: ACM, 2004,pp. 259–268.

[3] A. Gadkari, S. Mohalik, K. Shashidhar, A. Yeolekar, J. Suresh, andS. Ramesh, “Automatic generation of test-cases using model checkingfor sl/sf models,” 4th International Workshop on Model Driven Engi-neering, Verification and Validation, 2007.

[4] Reactis, “http://www.reactive-systems.com/.”[5] T-VEC, “http://www.t-vec.com/.”[6] C. Zhou and R. Kumar, “Semantic translation of simulink diagrams

to input/output extended finite automata,” Discrete Event DynamicSystems, pp. 1–25, 2010.

[7] C. Zhou and R. Kumar, “Modeling simulink diagrams using in-put/output extended finite automata,” Computer Software and Applica-tions Conference Workshops (COMPSACW), 2009 IEEE 33rd Annual,pp. 462 – 467, 2009.

[8] M. Li and R. Kumar, “Stateflow to extended finite automata translation,”Computer Software and Applications Conference Workshops (COMP-SACW), 2011 IEEE 35th Annual, pp. 1 – 6, 2011.

[9] NuSMV, “http://nusmv.fbk.eu/.”[10] CVX, “http://cvxr.com/cvx/.”

862