SLDG: A Metamodel for Simulink/Stateflow Models and its Applications

Transcription

1 Innovations in Systems and Software Engineering manuscript No. (will be inserted by the editor) SLDG: A Metamodel for Simulink/Stateflow Models and its Applications Shambhu Prasad Suraj Nayak Vamshi Vijay Rajib Mall the date of receipt and acceptance should be inserted later Abstract Simulink and Stateflow(SL/SF) models are being widely used to design and develop embedded systems. Often the SL/SF models of embedded controllers turn out to be large and consist of many subsystems and hierarchies. When such a system is maintained, it becomes difficult to manually analyse the model to identify the impacted elements due to the existence of several explicit and implicit depencies among the model elements. To automate the analysis of an SL/SF model, we propose a metamodel to capture various types of depencies existing across the basic blocks. We have named this metamodel Simulink depency graph (SLDG). We investigate the use of SLDG in change impact visualization and regression test selection. We have developed a prototype tool by implementing our approach for the aforementioned applications. Keywords hybrid systems reactive systems Simulink Stateflow slicing regression test selection impact analysis 1 Introduction Over the last few decades, the size and complexity of embedded programs have been increasing at a rapid Shambhu Prasad shambhu.prasad@cse.iitkgp.ernet.in Suraj Nayak suraj.j.nayak@gmail.com Vamshi Vijay vamshi1252@gmail.com Rajib Mall rajib@cse.iitkgp.ernet.in Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur, India rate. Multi-million line embedded programs have now become common. For example, the size of programs used in high- automobiles have been reported to be over tens of million lines of source code[2]. With the increase in size and complexity of programs, the use of appropriate design models for various software engineering tasks has become important. In this context, Model-Driven Development(MDD) has gained prominence and models are at present being used not only for design, but also in other software engineering activities such as visualization, code understanding, code generation, and testing. In the embedded software development domain, Simulink/ Stateflow (SL/SF) models have become popular. Use of SL/SF models offers several advantages, including automated facilities for system simulation, test generation, test execution, code generation and rapid prototyping of various controller and monitor software designs. Simulink/ Stateflow tool suite from MathWorks[1] consists of two modeling languages: Simulink and Stateflow. Simulink is used to model continuous dynamics, while Stateflow is used to specify discrete control logic and the modal behavior of a system. An SL/SF model can consist of multiple subsystems and hierarchies. When a system is maintained, it becomes difficult to manually analyse the model to identify the impacted elements due to a change. This is specially true for large systems. The culprit is the existence of explicit and implicit depencies among the elements contained in several SL/SF diagrams. Manual analysis of SL/SF models is not only tedious but also error prone. Thus, for automated analysis of the SL/SF models, we propose a metamodel to capture the existing depencies among the blocks. We have named this metamodel Simulink depency graph(sldg). We investigate the

2 2 Shambhu Prasad et al. use of SLDG in change impact visualization and regression test selection. We first propose a graph based metamodel to capture the relevant information from Simulink and Stateflow diagrams of a model. We also use our graph model to important software engineering tasks. This metamodel has been designed to capture various types of depencies existing among different SL/SF model elements. Though an SL/SF model for a non-trivial system may comprise several subsystems, a single SLDG explicitly captures different types of depencies existing across different blocks of the design model. This is expected to make the tasks requiring static as well as dynamic model analysis easier and more efficient. We argue that the SLDG can gainfully be used in software engineering activities requiring model depence analysis such as change impact visualization, regression test selection, test case prioritization, design model comparison and prioritization based on block criticality. In this paper, in addition to proposing SLDG as an intermediate representation for accurate slicing of SL/SF models, we report our investigations into the application of SLDG to two challenging software engineering activities, namely change impact visualization and regression test selection. In the following, we outline the challenges in automating these two software engineering activities. Change impact visualization: The SL/SF model of a system typically undergoes frequent changes over time due to design iterations and later on account of system evolution. A change to one of the diagrams of a model not only impacts some elements in the same SL/SF diagram, but also the elements in other SL/SF diagrams. In this context, change impact analysis of the SL/SF model of a system poses considerable challenge. In the absence of an automated method, the impact of a change is often analysed manually through a visual inspection of the SL/SF models that have various types of depencies among them. Also, many depencies are insidious and can easily be missed during visual inspection. Even otherwise, manual analysis is error prone. Therefore, there is an urgent need to develop an automated analysis technique. In this context, we investigate the use of our metamodel for automated impact analysis. Regression test selection: Typically, an SL/SF model undergoes a large number of modifications over its lifetime due to various maintenance activities that are undertaken on it. Regression testing is used to revalidate a modified SL/SF model. This ensures that the unchanged system functionalities have not been adversely affected. Regression testing involves running the relevant test cases from the original test suite on the modified system to revalidate it. Although a naive strategy would be to run all the existing test cases, it usually becomes prohibitively expensive especially if the changes do not affect affect a large part of the system. Regression test selection techniques are used to reduce the cost of regression testing by selecting relevant test cases. Manually selecting test cases that test the elements affected by a change is tedious and error prone. We investigate the use of the SLDG to automate the process of regression test selection. This paper has been organized as follows. We provide a brief overview of SL/SF models in Section 2. In section 3 we introduce the SLDG and we present the approach for its construction in Section 4. In Section 5 we present the approach for slicing the SLDG. In Section 6 and Section 7, we present the methodologies for change impact visualization and regression test selection respectively. We briefly discuss the other applications of the SLDG in Section 8. We then compare our work with related research in Section 9 and finally we conclude in section Simulink / Stateflow (SL/SF) Models SL/SF tool consists of two parts: SL and SF parts. Simulink (SL) provides an interactive graphical environment and a customizable set of block libraries that let one design, simulate, implement, and test a variety of time-varying systems. The Stateflow (SF) component on the other hand, provides the language elements required to describe complex state-depent behavior. It is tightly integrated with Simulink, thereby facilitating design of embedded systems that contain control, supervisory, and mode logic. In the following, we provide a brief overview of SL/SF. The complete specification of SL/SF is available in the SL/SF user guide from Mathworks[1]. Basic Concepts In this section, we briefly review a few basic concepts pertaining to Simulink and Stateflow models that have been used in our work. Simulink A Simulink model is composed of a set of predefined blocks that deal with analog signals. Simulink blocks are organized into block libraries according to their behavior. A few important libraries are the following: The sources library contains blocks that generate signals.

3 SLDG: A Metamodel for Simulink/Stateflow Models and its Applications 3 The sinks library contains blocks that display or write block output. The discrete library contains blocks that represent discrete-time components. The linear library contains blocks that represent linear functional components. The non-linear library contains blocks that represent non-linear functional components. The connections library contains blocks that perform multiplexing and demultiplexing, implement external Input/Output, pass data to other parts of the model, create subsystems, and perform other functions. Stateflow A Stateflow model helps to describe system execution behavior through the use of several graphical and non graphical constructs. The graphical constructs used in a Stateflow include the following types of elements: states, transitions, functions and junctions. Non graphical constructs such as data and event identifiers, conditions and condition actions, function calls, state actions, and temporal logic statements appear textually in the model. Each Stateflow model is represented by a statechart block in the Simulink model. A Stateflow model can have several levels of hierarchy (realised through use of nested states. There exists a default state for each level of hierarchy. The default state is entered by a pseudo transition that is represented by an open ed arrow. The default state is the first state that is activated in the Stateflow model. In Figure 1, the state A is the default state. For a comprehensive description of the use of these constructs, the reader is referred to [1]. A/ Entry: a=5; During: b=a+c; [a>10] Fig. 1 An Example Stateflow Model [b>6] B/ During: a++; Exit: c=2; State States represent the modes of a system. A state can either be a super state, sub state or a plain state. A state is called a plain state, if it does not contain other states. Further it should not be contained in any other state. If a state contains other states, then it is called a super state for all the states that are contained in it. A state is said to be a sub-state of a state, if it is contained in that state. Entry Action: This describes the action that takes place when a state becomes active. For example, in Figure 1 State A has entry action a=5. This means that the value of a is set to 5, whenever State A is entered. During Action: These actions are executed whenever a state is active and an event occurs and the conditional expression of the exit transition evaluates to false. As an example consider Figure 1, State A has a during action in which the value of b is computed. This action is executed whenever State A is active and any event other than one meeting b>6 occurs. Exit Action: The exit action is executed when an exit transition takes place. For example, in Figure 1, State B has the exit action c=2. This exit action takes place when a assumes a value larger than 10. Transition A transition causes the system to change its mode (state). A transition is represented by an arc between two states with an arrowhead pointing to the destination state. A transition is annotated with a label. The label can consist of an event identifier, a condition ( written within square brackets ([]).), a condition action, and/or a transition action. The syntax of a label is: event [condition] condition action/ transition action. Multiple events can be specified using the OR logical operator. The semantics of the different components of the label is as follows. Event: When the event associated with a transition occurs, the transition is taken, provided the condition, if specified, evaluates to true. A transition may not be annotated with any event. Absence of an event indicates that the transition is taken even without the occurrence of any event. Condition: A condition is a Boolean expression. A transition is taken upon the occurrence of the associated event, only if the specified condition evaluates to true. Condition Action: A condition action is enclosed within curly braces ({}). It is executed as soon as the associated condition evaluates to true and before the transition to the destination state is taken. If no condition is specified, then the condition is implied to be true and the condition action is executed by default.

4 4 Shambhu Prasad et al. Transition Action: Specifying a transition action is optional. If the transition is annotated with only transition action and no condition is specified, then the transition action takes place on occurrence of any event. If the transition is annotated with a condition as well as a transition action, then the transition action is executed only if the condition evaluates to true. mdl file Simulink and Stateflow models are stored in the form of an mdl (model description language) file. The syntax of mdl is quite intuitive and is described in [1]. In the following, we specify a mux block using mdl syntax as an example. Block { BlockType Demux Name Demux Ports [1, 3] Position [255, 25, 260, 135] BackgroundColor black ShowName off Outputs 3 } Conditional Execution and Execution Context To speed up the simulation of a model, the simulation engine of the Simulink software avoids unnecessary execution of blocks connected to a switch, multiport switch, or any other conditionally executed blocks. This behavior is called conditional execution (CE). The Simulink software defines an execution context as a set of blocks to be executed as a unit. The simulation of a model is deterministic and sequential. The Simulink simulation environment determines a schedule for the execution of blocks. Normally, the execution order is determined by the direct signal flow between blocks. Simulink uses execution contexts (EC) to store and execute the calculated schedules. An execution context contains a sorted list of blocks and nested execution contexts. Once an execution context is entered, all elements contained in this context have to be executed before the context is exited. When scheduling the blocks, the simulation environment creates one execution context for the whole model and one for each atomic subsystem within the model. The hierarchy of the atomic subsystems within the model determines the nesting of the execution of the blocks. All blocks contained in an atomic subsystem are added to the execution context for the corresponding subsystem. The elements in the ECs are scheduled locally within the context. The flow of execution in Simulink models is controlled using conditional subsystems, loop subsystems, MultiPortSwitch and Switch blocks. Conditional subsystems and loops are executed only if the condition given by the special port or iterator block evaluates to true. Hence the corresponding ECs are called conditional execution contexts(cec). Simulink Design Verifier (SDV) The Simulink Design Verifier [19] tool available in Matlab can help to generate and run test cases. However, at present the SL/SF tool set does not include any tool for regression test selection. Slicing Slicing is a technique using which a subset of the set of all statements in a program that is related to a particular point of interest, known as the slicing criterion, is computed. A forward slice consists of all the program statements that are affected by the slicing criterion, whereas a backward slice consists of the program statements that affect the slicing criterion. A comprehensive review of various slicing techniques can be found in [6]. 3 SLDG Metamodel In this section, we present our SLDG metamodel. An SLDG model can represent various SL/SF elements and their inter-depencies. An SLDG comprises of nodes that represent different SL/SF model elements and edges that capture the depencies among them. A simple system devoid of any modal behaviour can have only Simulink blocks without any subsystem or Stateflow blocks. However, an SL/SF model of a practical system may comprise of one, or more Simulink subsystems, each with zero, or more Stateflows. In the following, we first identify the types of depencies that can exist among the elements in an SL/SF model and subsequently we discuss how these depencies are represented in an SLDG. 3.1 Types of Depencies in an SL/SF model In the following we first identify the types of depences that can arise in an SL model, and also those that can arise in an SF model: Depences in a Simulink (SL) model: Two types of depences can exist in a Simulink model. These are output depence and control depence. Output depence: A Simulink block B2 is said to be output depent on a block B1, if and only if there exists a connection over which B2 receives a signal from B1. The output of the

5 SLDG: A Metamodel for Simulink/Stateflow Models and its Applications 5 Simulink block B2 deps on the input it receives from the block B1. For example, consider a Simulink model in which a clock block is connected to a scope block. The scope block is output depent on the clock block. Control depence: Control depence was originally defined for the control flow graph of a program. It captures the fact that the execution outcome of one node in a control flow graph may affect the execution of another. In SL models, conditional subsystem, loop subsystem MultiPortSwitch and Switch blocks are used to control the flow of execution. Control depence in a Simulink model was defined in [2]. Depences in a Stateflow (SF) model: Two types of depences can exist in a Stateflow model. These are control and data depences. Control depence: Control depence can exist between a transition and a state. A state is said to be control depent on a transition if the transition can determine whether the state is reached. Therefore a state is control depent on all its in-transitions. An out-transition from a state is control depent on the state as the out transition is depent on the actions being executed by the state. For example, consider the Stateflow model in Figure 1, having the state A which has an in-transition having a transition condition (a>5). The State S can only be reached, if the transition is taken. Therefore the state S is said to be control depent on the in-transition. Control depence also exists between the default state and the parent state in case of hierarchical Stateflow models. Data depence: Data depence in a Stateflow model can be defined as follows. An entity(a state or a transition) E2 is data depent on an entity E1, if there exists a variable v such that:(i)e1 assigns a value to v, (ii)e2 uses the value of v and (iii)there exists a path from E1 to E2 along which v is not modified. For example, consider the Stateflow model of Figure 1. In this model, state B assigns a value to the variable c and state A uses c to compute the value of b. The state B is said to be data depent on state A. 3.2 Definition of SLDG Simulink Depency Graph (SLDG) - An SLDG M is a directed multigraph G M = (N M, E M ) where N M is a set of Nodes types source SLDG destination Edges depency Block (B) State (S) Data (D) Predicate (P) Fig. 2 Class diagram for the SLDG metamodel Data Control Output nodes that represent the Simulink blocks, states, variables and transitions of an SL/SF design model, and E M N M N M is the set of edges that represent the various forms of depencies existing among them. A class diagram depicting a few types of SLDG elements has been shown in Figure 2. Simulink Block Clock K Constant Ramp SLDG Node Clock Constant Ramp Fig. 3 Mapping SL/SF model elements to nodes in the SLDG The different types of nodes that may be present in an SLDG are as follows: Block (B) node - A block node is created for every Simulink block in an SL/SF model. A block node is labeled with name of the Simulink block that it represents. A few representative examples of block nodes have been shown in Figure 3. State (S) node - For every state specified in a Stateflow an S node is created. An example of an S node has been shown in Figure 4 where an S node with label S A is created for a state A. Data (D) node - A D node is created for each data item and event in a Stateflow model. Examples of D nodes have been shown in Figure 4 where data nodes D X and D Y have been created for the variables x and y used inside the state A. If the value of x

6 6 Shambhu Prasad et al. is used as the output signal of the statechart, the corresponding data node is labeled by D X. Predicate (P) node - A P node is created for every transition. As an example in Figure 4 of a P node, is the node with the label P AB. Stateflow elements State A/ Entry:x=x+y; [x>y] A/ B/ Dx Dy SLDG Nodes P AB Fig. 4 Example of Stateflow model elements and their corresponding SLDG nodes 3.3 Edges in SLDG The nodes in an SLDG are interconnected using three types of edges to represent various depences that may exist among them. An edge in the SLDG is denoted using the node pair (from node, to node). The from node is said to be depent on the to node, with the depence direction shown towards the to node in the SLDG. In the following, we list the three types of edges that can exist in an SLDG. Output depence: An output depence edge exists between two nodes in an SLDG, if and only if output depence exists between the corresponding blocks in the Simulink model. This depency is represented by an edge from the depent node to the node on which it deps. As an example, consider a Simulink model consisting of two Simulink blocks, a scope that block is output depent on a constant block. The output depence between these two blocks is represented by an edge from the SLDG node corresponding to the scope block to the node corresponding to the constant block. Control depence: A control depence edge exists between two nodes in an SLDG, if and only if there exists a control depence between the corresponding entities in the SL/SF model. In this case, the edge is directed from the depent node to point to the node on which it deps. A control depence edge is also added between the state SA node of the default state and the block node of the corresponding statechart. As an example, consider a state A having an out transition T. Let T be the in transition of another state B. Here, B is control depent on T and T is control depent on A. These entities are represented by the state nodes S A, P AB and S B in the SLDG. The control depencies will be captured by the edges (S B, P AB ) and (P AB, S A ). Data depence: Two types of edges are used to represent data depence in an SLDG. The edges are drawn between:(i)the data node of the variable being assigned or used in a condition and the state or transition in which it is assigned and (ii)the data node of the variable being assigned and the data nodes of the variables being used. Each edge is labelled with one of the letters E, D, X,C,A and T indicating the type of the action, viz, Entry action, During action, Exit action, Condition, Condition action and Transition action respectively. The name of a state or transition is written as a subscript on the transition type symbol. When a state or a transition assigns a value to a variable, a directed edge is drawn from the data node representing the variable, to the state or transition node in which the value is assigned to it. An edge is added between two data nodes when the value of a variable is computed using the value of another variable.the edges are directed from the data node of the variable which is assigned, to the data node of the variable which is used. As an example, consider the Stateflow model in Figure 1. The SLDG will have the nodes S A and S B representing the states and also a data nodes D a, D b and D c representing the variables. The data depence of the node S A on S B is represented by the edges (D b, S A ),(D b, D c ) and (D c, S B ) with the label D A. 4 Construction of an SLDG In this section, we explain our approach for constructing the SLDG model for a given SL/SF model based on an analysis of the mdl file of the given model. A single SLDG represents all the levels of hierarchies that may be present in an SL/SF model. Execution Context Analysis: The SLDG for the Simulink part of a model is constructed as follows. First the algorithm given in [2] is used to compute the execution contexts. It involves recursively traversing the Simulink model and adding blocks to their corresponding execution context based on the conditions

7 SLDG: A Metamodel for Simulink/Stateflow Models and its Applications 7 as given in [1]. We briefly mention these conditions in the following. A block can be added to an execution context, if and only if each of the following hold: Its output is required only by a conditionally executed subsystem or its input changes only as a result of the execution of a conditionally executed subsystem, Its sample time is inherited. The output of the block is not a test point. The block is allowed to inherit its conditional execution context. The block is not a multirate block. Simulink SLDG Construction: The Simulink blocks are extracted from the mdl file and the corresponding nodes are created in the SLDG. If a block is output depent on some other block, then an edge is added between the corresponding nodes in the SLDG to represent this depency. This procedure is repeated for all the subsystems present in the model. Subsequently, we add edges to represent control depency based on the conditional execution context as described in [2]. Stateflow SLDG Construction: The SLDG for the Stateflow part of the model is constructed as follows. The states are extracted from the mdl file of the model. Each state is represented by a state node in the SLDG. A control depence edge is added between the state node representing the default state and the block node representing the statechart. For each state, the in-transitions are determined. These in-transitions are represented using predicate nodes. A data node is created for each variable used in the model. The data depency and control depency edges are added between the nodes representing the elements of the Stateflow model based on the depencies that exist between them. This procedure is repeated for all sub-states. A control depency edge is added between the default substate and its parent. We now present the procedures that are invoked during the construction of an SLDG. Among these, build SLDG procedure calls the procedures construct S- imulink and construct Stateflow. build SLDG: This procedure takes an mdl file representation of a model as input and returns the corresponding SLDG. It analyzes the mdl file and extracts the blocks of an SL/SF model and maintains a list of the blocks. The blocks are then passed to the procedure construct Simulink, which returns the constructed SLDG after adding the control depencies based on the execution contexts. It then invokes the procedure construct Stateflow to extract the Stateflow models present and constructs the SLDG for the Stateflow part. ALGORITHM 1: build SLDG atex@errorlgobbleinput: mdl file Output: SLDG of the SL/SF model begin Read the blocks from the mdl file Compute the execution contexts construct Simulink(list of Simulink blocks) Add control depence edges based on conditional execution contexts construct Stateflow(file path) construct Simulink: This procedure constructs the SLDG of a Simulink model. It takes a list of blocks as input and constructs an SLDG. Blocks present in the list are extracted one by one and for each subsystem block, the corresponding blocks are extracted. For each block present in the SL/SF model, a node is created in the SLDG. For any two blocks connected in the SL/SF model, an output depence edge between the corresponding nodes in SLDG is created. The connected blocks are identified by iterating over the connections of a block and finding the blocks that are adjacent to it in a breadth first manner. If the given subsystem has any nested subsystems, these are iteratively added to the list of subsystem blocks. This process is repeated until all the blocks in the list have been considered. ALGORITHM 2: construct Simulink atex@errorlgobbleinput: list of blocks Output: SLDG of the Simulink part begin for each block in the list do if block is a subsystem block then while blocks in subsystem not empty do read a block from subsystem. insert the block into the list of blocks. else create a block node that represents the block. extract all the blocks that receive input from the current block. insert all the adjacent blocks into adjacent list. while blocks in the adjacent list not empty do add a output depency edge from the adjacent block to the current block.

8 8 Shambhu Prasad et al. construct Stateflow: This procedure initiates the construction of the part of the SLDG that represents the Stateflow model. The input to this procedure is an mdl file. It extracts all the Stateflow charts present in the model. The procedure extract Stateflow is called for each state in a statechart. ALGORITHM 3: construct Stateflow atex@errorlgobbleinput: mdl file Output: SLDG of the Stateflow part of the model begin read the Stateflow charts from the mdl file to a list, say sf list. while sf list not empty do read a statechart sf model from the sf list. for each state S in sf model do if S is the default state then Add control depence edge between S and the block node of the statechart extract Stateflow(S); extract Stateflow: This procedure extracts the actions and the in-transitions of a state. It takes a state from a Stateflow chart as a parameter. A state node is created for each state. Data nodes are created for each variable and event in the Stateflow model. A Predicate node is created for each transition. Data and control depences are captured by creating the edges as explained in the previous section. If a state has nested states, a recursive call to extract Stateflow is made with each nested state as a parameter. A control depence edge is added between the block node of the statechart and the node representing the default state to link the SLDG of the Stateflow part with that of the Simulink part. ALGORITHM 4: extract Stateflow atex@errorlgobbleinput: A State S begin create a State node for S in the SLDG. Parse the state label to get the Actions(Entry, During, OnEvent, Exit) and the variables used in these Actions. create a Data node for each variable. // Capture Data depencies for each variable V assigned in the Actions d do Add data depence edge from the Data node of V to the State node of S Add data depence edge from the Data node of V to the Data node of each variable used to compute its value Insert all the in-transitions of a state into the list transition list for each transition T in transition list do Get source state of T Create a Predicate node Create a Data node for each variable or event used in transition label // Capture Control depencies Add a control depence edge from the Predicate node to the Source node Add an edge from the current State node to the Predicate node Parse the transition label to get event, condition, condition-action and transition-action Create a Data node for each variable and event Add data depence edge from the Data node of event to the Predicate node Add data depence edge from the Predicate node to the Data nodes used in the condition for each variable V assigned in the condition-action and transition-action do Add data depence edge from the Data node of V to the Predicate node Add data depence edge from the Data node of V to the Data node of each variable used to compute its value Get the inner states of S for each inner state In S do extract Stateflow(In S) 4.1 Complexity analysis We now present the time and space complexities of our SLDG construction approach. The complexity of construction of a general form of SL/SF model having m levels of hierarchy and n Stateflow charts is: time complexity is O(β 2 + nα(ɛ+τ)) space complexity is O(β 2 + (α + ε + τ) 2 ) where β is a bound on the total number of Simulink blocks in the model, α is a bound on the number of states in each Stateflow chart, ɛ is a bound on the number of variables used or initialized in each state, τ is a bound on the number of incoming transitions of a state and ε is the total number of variables in the Stateflow model. The detailed steps for analysis can be found in [7]. 4.2 Examples of SLDG In the following we present five example SL/SF models and their corresponding SLDGs. Figures 5,6,7,8 and 9 show examples of SLDG models constructed for six sample Simulink(SL) Stateflow(SF) models. Figure 5 shows the SLDG for a simple SL/SF model that does

9 SLDG: A Metamodel for Simulink/Stateflow Models and its Applications 9 not have any Stateflow block. Figure 6 shows the SLDG Top Level Model Extract Min Indices Subsytem 9/ MinValue + InputVector MinIndex 1 fs 2 lenable 1 InputVector (1:N) u S ldx1 Y 2 MinValue 1 MinIndex Ramp Gain 32 Sum Scope A B Extract Min Indices Selector A B Constant ln Sum Input Vector Selector Min Value fs Ramp Gain Sum Scope Constant Min Index lenable Fig. 8 SLDG for an example hierarchical Simulink model Constant Fig. 5 SLDG for an example Simulink model for a given Stateflow chart. Figure 7 shows the SLDG A B A/ Entry:a=b+c; During: b=a; Exit:a=a+c; Da XA [c==0]{b=0}/a=0 TAB B/ Entry:c=b; has the substates HIGH and NORM. The corresponding SLDG is shown in Figure 9B. Note that once the State On becomes active, the substate HIGH, being the default sub state of On, also becomes active. Hence there exists a control depence edge from the HIGH state to the On state. On/ Entry:turn_boiler=0; During:flash_LED=0; High/ [warm] Norm/ XA EA EA EA XA DA D D A S b A P AB S B EB CAB Dc AAB EB A B D turn_ boiler E On D On S On S High P HighNorm Fig. 6 SLDG for an example Stateflow model D flash_ LED Dwarm C HighNorm SNorm for a model having both Simulink and Stateflow parts. Figure 8 shows the SLDG for an SL/SF model having Fig. 9 SLDG for an example hierarchical Stateflow model Repeating Sequence A B Repating Sequence wave Chart Chart sf Display1 Display2 Display1 Display2 A/ Entry:sf=0; [wave%2==0] Fig. 7 SLDG for an example SL/SF model S A P AB E A P BA [wave%2==1] B/ Entry:sf=1; subsystems. In Figure 8A the model has a subsystem named Extract Min Indices. Figure 8B shows the corresponding SLDG. Figure 9 shows the SLDG for a model having hierarchical states. In Figure 9A, the State On C BA S B D wave D sf * E B C AB 5 Slicing the SLDG 5.1 Slicing criterion A slicing criterion denotes a point of interest in an SL/SF model. A point of interest can be in the Simulink part or the Stateflow part or both. When this point of interest is a block in the Simulink part of the model, the block node representing it in the SLDG is taken as the slicing criterion. When the point of interest is in a Stateflow part, it is represented by a pair (N,D), where N is a state or transition and D is a data variable. Thus the state node or predicate node along with the data node corresponding to the pair (N,D) are taken as the slicing criterion.

10 10 Shambhu Prasad et al. 5.2 Computation of forward slice A forward slice comprises all the nodes in an SLDG that are influenced by the slicing criterion. That is, all the nodes that are affected when a change is made to the SLDG. The forward slice of the SLDG of a pure Simulink model (without Stateflow part) can be computed by traversing the SLDG and visiting all the reachable nodes. In case of presence of a Stateflow model, a simple traversal will not suffice. We consider the following issues while slicing the Stateflow part of the SL/SF model: A state or transition is affected by a change only if it uses an affected variable to compute a value. Here an affected variable refers to a variable that is directly or indirectly affected by a change. When there is a cycle in the Stateflow graph, a state or a transition which was unaffected during the initial pass, may be affected in the next pass as some unaffected variables may now get affected. Termination of the traversal of the SLDG is based on satisfaction of two conditions: (i)all the adjacent nodes have been visited and (ii) there has been no new affected data nodes since the current node was last visited. A variable may be affected in an action in a state or transition and may affect other variables. For example, a variable that is affected in the During action may influence the variables in the Exit action. An affected variable stops affecting other variables as soon as it gets reassigned. To compute the forward slice of the SL/SF model when the slicing criterion is a block node, the following approach is used. The block nodes are traversed, starting from the slicing criterion. Each visited block node is added to the slice. When a block node that represents a statechart is encountered, the handle Stateflow is invoked with the state node of the default state and the data node of the input to the statechart as input parameters. The algorithm handle Stateflow takes the SLDG, affected state or predicate nodes and the affected data nodes as inputs. It finds all the affected state and predicate nodes. The traversal of the SLDG is initiated by invoking the traverse node procedure. The traverse node procedure takes a state or predicate node, SP list and D list as parameters. This procedure recursively visits all the adjacent state or predicate nodes of the current node. The procedure iterates through the data depency edges of a Stateflow or predicate node in order of the actions i.e., entry action followed by during action which in turn is followed by exit action. In each case, a state or predicate node is added to SP list if a data node in the D list corresponds to a variable it uses. A data node is removed from D list, if the corresponding variable has been reinitialized and the node is added to D list, if the variable is initialized using an affected variable. The traversal is continued till all the reachable state and predicate nodes have been traversed and var list is not a proper subset of D list. If var list is a subset of D list, it implies that new data nodes have been added to D list since the previous traversal and the nodes adjacent to the current node have to be visited again. To compute the slice of the remaining SL/SF model, the traversal is continued with the changed block node of the statechart as the slicing criterion. The change in the Stateflow part is propagated to the Simulink part, only if the value of an affected data variable is an output signal of the statechart. ALGORITHM 5: handle Stateflow atex@errorlgobbleinput: SLDG of the SL/SF model Affected state or predicate nodes Affected data nodes and the actions in which they were affected Output: Affected State,Predicate and Data nodes begin Initialize SP list Null Initialize D list affected variables A list label of the depency edge of the affected action Initialize Start node affected S or P node for each S and P node in the part of the SLDG representing the statechart do Initialize var list Null traverse node(start node,sp list,d list,a list) 6 Change impact visualization In this section, we give an overview of our approach to visualize the impact of a change to an SL/SF model based on static analysis of a constructed SLDG. Our approach to the change impact analysis of an SL/SF model involves slicing an SLDG using the corresponding changed nodes as the slicing criteria. We assume that the changes that can be made to an SL/SF model and the corresponding slicing criterion in each case are as follows. All other changes can be expressed in terms of these changes. Types of changes to a Simulink model: We assume that one or more of the following types of

11 SLDG: A Metamodel for Simulink/Stateflow Models and its Applications 11 ALGORITHM 6: traverse node atex@errorlgobbleinput: Current node:current State or Predicate node SP list:list of affected S or P nodes D list:list of affected Data nodes A list:affected actions begin // iterate through the edges in the order of the actions that occur starting from the affected action for each data depency edge incident on Current node do if the edge label is of a condition and the edge exists between a data node in D list and Current node then Add the P node to SP list if the edge exists between a data node in D list and Current node then Remove the node from D list Add current node to SP list if it uses a data node present in D list Add the data node that is initialized using the node in D list to D list and add the corresponding depency edge label to A list. if var list D list then var list var list D list for each incident control depence edge do Get the source-node traverse(source-node,sp list,d list) changes can be made to a Simulink model. For each case we identify the slicing criteria in the corresponding SLDG model. Add block: A block may be added to a Simulink model and its interconnections defined. In this case, the SLDG node corresponding to the new block in the SLDG is constructed and the new nodes are taken as the slicing criterion. Delete block: An existing block along with all its connections may be removed. The nodes and edges corresponding to the elements are marked deleted, but are not actually removed as those are taken as the affected blocks. The SLDG node corresponding to the block being deleted in the SLDG is taken as the slicing criterion in this case. Modify block: The parameters of a block may be modified. For example, the value of a constant block may be changed. The node corresponding to the modified Simulink block in the SLDG is taken as the slicing criterion in this case. Add/Delete Connection: A connection may be added or removed. In this case, the SLDG node in the new SLDG corresponding to the Simulink block that received the signal from the connection is taken as the slicing criteria. Modifying a connection is analogous to performing a delete followed by an add operation. So this is not considered as a basic type of change operation. Types of Changes to a Stateflow model: We assume that one or more of the following types of changes can be effected to a Stateflow model. For each case we identify the slicing criteria in the corresponding SLDG model. The actions(entry/during/exit) of a state may be modified. In this case the SLDG nodes corresponding to the changed data variables and the state are taken as the slicing criteria. The transition label may be modified. In this case the SLDG nodes corresponding to the modified data variables and the transition are taken as the slicing criteria. A new state or a transition may be added or removed: In this case the SLDG nodes corresponding to the data variables that are assigned a value in the actions/transition label and the state/transition are taken as the slicing criteria. For a given change to an SL/SF model, the change impact is computed through the following activities: The slicing criterion for the corresponding change is identified. Based on this slicing criterion, a forward slice on the corresponding SLDG is performed. The approach discussed in Section 5 is used for slicing the SLDG. The ids of the nodes in the slice are written into a text file, for subsequent visualization using Matlab script [8]. 6.1 Implementation We have developed a prototype tool to implement our approach for change impact visualization. We have named this tool IViz to stand for Impact Visualizer. IViz has been developed using Java language. We have used the open source Graphviz [3] package to graphically display the SLDG. We have used the Simulink library provided by [4] to parse an mdl file. The methods available in the library were used to retrieve Simulink blocks, connections, states and transitions. The state and transition labels were then parsed. Figure 10 shows a schematic of the module structure of IViz. The UI collects the name of the mdl file and the specification of the changed block or state, transition and variables from the user. The SLDG for the given SL/SF model is constructed using the algorithms

12 12 Shambhu Prasad et al. UI mdl file Changes to the model Model with the impacted blocks marked SLDG Constructor Matlab Script Fig. 10 Module structure of IViz Affected Blocks SLDG Slicer given in section 4. The slicer component implements the algorithm given in section 5 to determine all the affected blocks in the SLDG. We have used Matlab script to color all the affected blocks in the SL/SF model to help visualize the impact of the change. 6.2 Experimental results Table 1 shows the summary of the results of the experiments carried out by us using the IViz tool. We have performed 20 experiments and a single change to the SL/SF was made each time. The table shows the average number and the maximum number of blocks affected. A changed block may not affect any other block, in which case the number of affected blocks is 1; or it may affect a large number of blocks in the model. The number of blocks affected deps on various factors such as the depth of hierarchy at which block is changed in the SL/SF model, the number of blocks between the changed and the output blocks, presence of conditional subsystems, loops in the model and maximum number of blocks in the model. Exp no Model Name Total Blocks Average Affected Blocks 1 powerwindow rm sldemo engine sf boiler sldemo househeat sf climate ctrl MDVel BehMod sldemo absbrake sldemo suspn sldemo trans Table 1 Summary of results for impact visualization Maximum Affected Blocks 7 Regression test selection In this section we briefly outline our methodology for regression test selection. Our technique involves three main steps: construction of SLDG, identification of affected parts of a modified model and selection of the test cases that execute the affected parts. The SLDG of the SL/SF model is constructed using the algorithms given in section 4. The types of changes that can be made to the SL/SF model have been discussed in Section 7. The nodes corresponding to the SL/SF model elements(blocks, states, transitions) that have been changed are taken as the slicing criterion and the forward slice of the SLDG is computed. The SLDG nodes in the slice correspond to the model elements affected by the changes made to the SL/SF model. Sl no. Type Model Item Description Test Case 1 Decision Abs input > 0 F 1 2 Decision Abs input < 0 T 3 3 Decision Switch trigger >= threshold 2 false (output is from 3rd input port) 4 Decision Switch trigger >= threshold 1 true (output is from 1st input port) Table 2 An extract of the SDV report The test cases for the SL/SF model are generated using the Simulink Design Verifier(SDV). The SDV generates a report in HTML format, that contains test cases along with the blocks that they cover. An extract of the report containing the test cases and the model elements that they execute has been shown in Table 2. The column named Model Item shows the name of the block and the column Test Case shows the serial numbers of the test cases that execute it. The columns Type and Description give the test case type and its description respectively. The algorithm for test case selection (RTselection) has been given in Algorithm 7. In the following we explain the working of the algorithm: RTSelection:The SDV report takes the affected blocks are as its inputs. The test cases and the blocks that they cover are extracted from the report. If a block covered by a test case is present in the list of affected blocks, then the test case is added to the regression test suite. 7.1 Implementation We have developed a prototype tool named RTSel to implement our regression test selection methodology.

13 SLDG: A Metamodel for Simulink/Stateflow Models and its Applications 13 ALGORITHM 7: RTselection atex@errorlgobbleinput: Simulink Design Verifier report Affected blocks from the SL/SF model begin Parse the report and extract the test cases along with the blocks that they cover for each extracted test case T do if a covered block is also an affected block then Add T to the Regression test suite Remove T from the extracted set models collected from automotive companies which are simplified models of their developed models. Experiments were carried out using each model, with different types of changes effected in each experiment. The different types of changes have been described in section 6. The test case generation was performed using SDV. Table 4 shows the average number of test cases selected out of the total number of test cases originally designed for each model. UI mdl file Changes to the model SDV report RT suite SLDG Constructor Test case Selector Affected Blocks SLDG Slicer Model Code Model No. of blocks in the model m1 powerwindow 166 m2 climate controller 48 m3 boiler 38 m4 sinetosquare 28 m5 sldemo cruise control 74 m6 sldemo tank 38 m7 sldemo suspn 44 m8 sldemo clutch 34 m9 sldemo radar 52 Table 3 SL/SF models considered Fig. 11 Block diagram of RTSel The tool has been developed using the Java programming language and graphviz[3]. The test cases are generated using the Simulink design verifier. Figure 11 shows a high level module structure of our tool. The inputs to the tool are the mdl file of an SL/SF model and the corresponding SDV report. The changes made i.e, the changed blocks/states/variables are selected by the user through a GUI. A brief description of the functionalities of the individual modules is as follows. The SLDG constructor constructs the SLDG of the SL/SF model using the algorithms presented in section 4. The Slicer computes the forward slice of the SLDG using the set of changed nodes as the slicing criterion. It uses the algorithms presented in section 5. The Test case selector module selects a subset of the initial test suite using the SDV report and the affected elements of the SL/SF model. Model Total Max. no. Avg. no. Percentage Code No. of of test of test of test test cases generated cases selected cases selected cases selected m m m m m m m m m Table 4 Summary of results of regression test selection The selected test cases in the regression test suite cover all the blocks of the model that are affected by the changes made to it. We tested the models using the regression test suite after seeding bugs in the modified model. All the bugs were by the test cases selected by the tool. 7.2 Experimental Results Tables 3 and 4 show a summary of the results of the experiments that have been carried out using the Regression test selector. The experiments were performed using sample models available in Matlab and a few other 8 A Few Other Applications of the SLDG The SLDG model can have applications in several software engineering tasks. In this Section we outline a few possible applications of the SLDG other than the two that we have investigated.