Automatic Test Case Generation in Model Based Software Design to Achieve Higher Reliability

A. Wakankar, A.K. Bhattacharjee, S.D. Dhodapkar

P.K. Pandya KaviArya Department of Computer Science &

Engineering Reactor Control Division Bhabha Atomic Research Centre

Mumbai, India amolk@barc.gov.in

School of Technology & Computer Science

Tata Institute of Fundamental Research Mumbai, India

pandya@tifr.res.in CSE, lIT Bombay

Indian Institute of Technology Mumbai, India

kavi@cse.iitb.ac.in

Abstract Model based design methodology is increasingly being used in the

development of software for embedded controllers for safety class

applications. SCADE Suite is a set of tools that support model based

design of software for embedded systems. The model validation

activity in SCADE involves model simulation guided by set of test

cases that are based on system requirements (Functional or

blackbox) and structural coverage criteria like MCIDC

(Whitebox). However, systematically devising a test case based on

such criterion is not easy and often the designer is required to

analyze the model to design a test sequence, which will meet the

required criteria. In this paper, we demonstrate the use of a

technique based on model checking to automate the generation of

such test cases for SCADE models. For automatic test case

generation, the tool SAL-ATG was used that can generate the test

cases for the models developed in SAL specification language.

MC/DC coverage criterion was adopted for generating the test

goals to be covered by generated test cases.

Keywords- Model Based Design, Model Checking, Test Case Generation, Structural Coverage

I. INTRODUCTION

The approach used in model based design is to build the abstract

representation (model) of application in a modeling language

and then obtain the implementation in a programming language

automatically using code generator. The advantage of this

approach is that, any change in the requirement can be directly

introduced in the model and the verification of the model can be

done, before code is generated automatically, thereby keeping

the implementation in sync with the verified design. This is a

significant advantage in implementing change request. SCADE

Suite [1] is a set of tools which facilitates the model based

development of control systems. SCADE provides an

IEC61508ID0178B [2, 3] certified code generator which

automatically generates C code for the given SCADE model.

In model based design methodology, the correctness of the

978-1-4244-8343-3/10/$26.00 ©2010 IEEE 493

model is mainly established by simulation. Simulation activity is

guided by set of test cases that are either based on system

requirements (Functional or black-box) or based on structural

coverage criteria like MCIDC (White-box) [3]. In fact, the use of

MCIDC criteria to assess the model coverage achieved during

simulation is mandatory to comply with DO 178B [3] standard.

However systematically generating the test cases manually

based on the chosen criteria requires a large amount of effort

because the designer is required to analyze the model. The effort

can be reduced if the test cases can be generated automatically

for the given model based on a specified test case generation

criteria.

Recently considerable research has happened in the area of

automatic test case generation, that apply techniques of formal

verification like Model Checking [4] to automate the generation

of test cases for the given coverage criteria. Model checking is an

algorithmic technique that accepts an abstract representation of

system design (called model) and a property (called

specification) that the final system is expected to satisfy. The

algorithm outputs 'YES' if the given model satisfies the

specification provided and generates a counter example

otherwise. The counter example details why the model does not

satisfy the specification. This ability of model checking

technique can be used to generate the test cases for the given test

goal.

However SCADE Suite does not provide any automatic test case

generation tool. Our experience shows that it is a nontrivial task

to generate test cases which provide adequate test coverage for

the model. In this paper, we discuss the method of systematic test

case generation using automated approach. We also demonstrate

the method using example models that are built using SCADE

language [5]. We are focused on SCADE for modeling the

systems because it is an industrial tool having a graphical

language based on rigorous semantics which allows simulation

and design verification. The environment also provides a

2010 r'International Conference on Reliability, Safety & Hazard (ICRESH-201O)

IEC81508 certifiedIDO 178B qualified code generator which

automatically generates the C code from the model.

We have used SAL-ATG [7] as the back-end engine for

automatic test case generation. SAL-ATG is an automated test

case generation tool based on SAL [6] modeling language and

uses SMT [8] based techniques. For this purpose, the SCADE

models are translated manually to SAL and the SAL-ATG

generated test scripts are translated back into SCADE simulation

input data file format. Our initial results are encouraging.

The paper is organized as follows: Section II provides the

background containing brief descriptions of Model Checking

technique, SCADE language and SAL specification language.

Section III describes the technique of automatically generating

the test cases using model checking. The use of this technique for

generating the test cases is illustrated in Section IV by taking two

examples developed in SCADE and Section V gives conclusion

based on the experience gained and the work planned in future.

II. BACKGROUND

Automated generation of test cases is an attractive application

for mechanized formal methods because of the importance of

good test cases, and difficulty of generating them manually.

Automated test case generation provides benefit towards this

and it is becoming practical with current trends in formal

verification.

Model checking [4] is one of the formal verification techniques

that are based on models describing the possible system behavior

in a mathematically precise and unambiguous manner. Applying

model checking to a design consist of three steps.

The first step is to convert the design (representing the system

requirements) into a formalism accepted by a model-checking

tool, which is called the model of the system. In more technical

terms, the model of a system is represented in terms of a

transition system [4]. As explained above the SCADE

environment provides such a modeling language.

The second step involves stating the properties (representing

the system specification) that the design must satisfy. The

specification is usually given in some logical formalism like

CTL (Computational Tree Logic), LTL (Linear Temporal Logic)

[4] etc.

The final step involves the application of model checking tools

and analysis of result. This is illustrated in Fig. 1.

An effective approach to automated test case generation is based

on the ability of model checkers to generate counterexamples to

494

invalid property (wrong behavior), so as to generate a test case,

which will exercise that behavior. This behavior is characterized

by a predicate "p", and we model check for the property "always

not p". The counterexample to this property provides the

required test case for exercising the behavior "p". If there is no

counterexample generated for "always not p", then it indicates

that the proposed behavior represented by "p" is infeasible. In

fact this way, one can check whether behaviour is feasible and

can generate test cases. For test case generation, test goal based

on a given criteria is specified as a behavior for model checking.

C_.a ... pleir ....... .-., .. \ •• ofYl9<Ci'-,nlioll

Figure I. Model Checking of a System Model

A. SCADE SpecijicationLanguage

The SCADE [2, 5] modeling notation supports Dataflow

Equations and State Machines for modeling the reactive

behavior of a system. A dataflow equation describes the logical

relationship between the input and output variables. A state

machine describes the control flow in the system in terms of state

transitions. Set of dataflow equations are evaluated in parallel

unless there is a data dependency between them. Internally the

SCADE models are represented in SCADE textual language.

SCADE textual language is based on the dataflow formalism,

which is similar to the Synchronous dataflow language, Lustre [9].

Synchronous languages [10] are based on synchrony hypothesis,

which assumes that the program is able to react to an external

event, before any further event occurs. In dataflow language a

program is described as network of operators transforming flows

of data. SCADE model is graphically represented as network of

operators. For example a basic counter that counts up from 0 can

be expressed in SCADE textual language as

N =O. pre (N) + 1;

In above equation, N is a variable that stores the value of counter

at a given instance of time. The operator is called the followed by

operator and it is used for initialization. Operator pre refers to the

value of variable at previous instant of time. Therefore the above

equation specifies that the initial value of variable N is 0 and

thereafter its value is one more than the previous value.

1 N

'� Le-Figure 2. SCADE Operator Diagram

2010 r'International Conference on Reliability, Safety & Hazard (ICRESH-201O)

SCADE model corresponding to above equation is shown in Fig.

2. A network of operators in SCADE can be encapsulated as a

new reusable operator that is called a node or SCADE operator.

The requirements of the system to be implemented are mapped

in the form of network of SCADE operators, where each

operator provides a specific functionality independently or by

interaction with the other SCADE operators.

SCADE Design Suite is a collection of software tools supporting

an IDE for modeling, simulation, verification and code

generation. The M TC module of SCADE Suite accesses the

coverage achieved during testing (simulation) of the model.

SCADE M TC follows a color code to display the amount of

coverage achieved for the given SCADE operator. The red color

indicates operator is not covered at all, y ellow color signifies

partial coverage and green color means the operator has been

fully covered during testing.

B. SAL Specification Language and SAL-ATG

SAL [6] specification language provides the way to represent the

specification of the system to be analyzed in terms of transition

system. SAL is a framework for combining different tools for

abstraction, program analysis, theorem proving, and model

checking towards the calculation of properties of transition

systems.

SAL-ATG [7] is a tool for automated test case generation for

SAL specification. For a given SAL specification augmented

with the Boolean trap variables representing the test goals, SAL­

ATG generates a set of tests to drive the trap variables to true i.e.

to make the test goal represented by that variable true. The SAL

specification instrumented by the trap variables may typically

represents a structural coverage criterion.

III. SYSTEMATIC TESTING By USING MODEL CHECKING

TECHNIQUE

Although SCADE Suite includes a formal verification tool

(design verifier) the tool does not provide enough

configurability to be useful for generating test cases. Hence, it

was required to use a model checking tool which allows

configurability to generate test cases. For this purpose, SAL­

ATG tool [6] that generates test cases for SAL specification [7]

was chosen. For a given SAL specification augmented with

Boolean trap variables representing test goals, SAL-ATG

generates a test sequence, if the given test goal is feasible.

As explained in previous sections, the underlying SAL model

checker in SAL-ATG takes system requirements (called model)

and the property (called specification) as input and generates

counter example showing the trace leading to the state where the

given specification is not satisfied. To generate the test case for

495

given test goal it is required to provide the negation of that test

goal as the property to be satisfied. If the test goal is feasible then

model checker generates a counter example which shows the

execution trace through which the negation of test goal is not

satisfied i.e. we will get the execution trace which satisfies our

test goal.

Criteria for

Test Case Generation

SCADEMTCModuie �I--------'

Figure 3. Test Case Generation for SCADE models

In order to generate test cases for SCADE models, the SCADE

model is first translated into SAL. Presently this translation is

being done manually. We have chosen MC/DC structural

coverage criteria for test case generation. The MC/DC criteria

[3] ensures that every point of entry and exit in the program has

been invoked at least once, every condition in a decision in the

program has taken once and each condition has been shown to

affect that decision outcome independently . Appropriate trap

variables are defined for the translated model in SAL language

based on MC/DC criteria. SAL-ATG is then used to generate the

test cases for the defined Boolean trap variables. These test cases

are then translated back to SCADE "model simulation input data

file format" using a TCL [11] script and SCADE model is

simulated with the generated input file. SCADE M TC module is

then used to access the model coverage. The workflow for test

case generation is described in Fig. 3.

In the next section, this technique is demonstrated using two

example models developed in SCADE. The first model is of a

token-based bus arbiter logic that has several "request" (input)

lines and grants "acknowledge" to at most one request. The

second model is a part of a Steam Generator Pressure Controller

(SGPC) used in NPPs. MC/DC structural coverage criterion was

taken as test case generation criteria for both of these models.

IV. CASE STUDIES AND RESULTS

A. Case Study J The first case study is an example of a synchronous bus arbiter. A

synchronous bus arbiter with n cells has n request lines req!,.,

req. and n acknowledgment lines ack!, ...... , ack". At any clock

cycle a subset of request lines is high. It is the task of the arbiter to

set at most one of the corresponding acknowledgment lines high.

Preferably, the arbiter should be fair to all the requests. We have

2010 r'International Conference on Reliability, Safety & Hazard (ICRESH-201O)

used the arbitration logic proposed by McMillan [12]. For this

case study, we have used 5 cell arbiter (i.e. n=5). Fig. 4, shows

the SCADE model of 5 cell Synchronous Arbiter and Fig. 5,

shows the implementation of a single cell.

The trap variables for this example were defined based on

MCIDC criterion. For example, trap variables for a logical AND

operator (Filled with crossed lines in Fig. 5) could be written as

follows.

The inputs to this AND operator are G rantIn and NOT(Reqln).

According to MCIDC criteria there are three input conditions to

be executed for the coverage of an AND operator having two

inputs 11 and 12. These conditions are (IJ and 12), (not IJ and 12)

and (IJ and not /2). Hence three trap variables will be generated

as follows:

TrapVarl = Grantln and NOT(Reqln)

Trap Var2 = (NOT Grantln) and (NOT(Reqln))

TrapVar3 = (Grantln) and (NOT(NOT(Reqln)))

Similar trap variables are defined for all the operators and given

as an input to the SAL-ATG along with the SAL model obtained

by manually translating SCADE model of Arbiter. The

generated test cases are then used to simulate the model.

TddU2 )(1 <0 ."

� i ... ... ... hi ..

r '" . �

6 � S .a TokOi ... ... TokO.t4

I I - .R

go " i .a ... ...

-----r--

I I TokOJl3

� .S> go " i .a ... ...

1

n I I - .�

TddU

.:l � .I! ... ... ---1

I 0 --0(}-

Figure 4. SCADE model of Arbiter which instantiates ArbiterLogic node

496

Owerridlln Gr.tO.rt

I

R.�n }---------++----+-�>+_-----t

Td<ln

U l

o,.rrIdtOJt Orrin

_>AdcOlA

Figure 5. SCADE model of ArbiterLogic node called inside Arbiter node

Result: For this case study the only one test sequence was

generated which was 28 step long. A snapshot of the test case

generated by SAL-ATG and the corresponding SCADE scenario

file (i.e. model simulation input data file format in SCADE) are

shown in Fig. 6 and Fig. 7 respectively.

1 tests qanerated; tota1 1enqth 27

1 undisCharged test qo&1s: (OverridaOut __ 2[S])

Path

St .. p 0: --- Input Variab1es (assignments)

1I.eq(�) true

1I.aq (Z) ra�se

1I.eq(3) = ra�se

1I. .. q(4) - r .. �s ..

1I.eq(S) - £ .. � ....

Step �:

--- Input Variah�.s (assiqnaents)

Req[1J := true

1I. .. q(Z) - tru ..

1I.eq(3) - £a�se

1I.eq(4) = ra�se

1I.eq(S) ra�se

Step Z:

--- Input Variab1es (assignments)

1I.eq(�) - true

1I.eq(Z) true

1I. .. q(3) tru ..

1I. .. q(4) - r .. �se

1I.eq(S) - £ .. �s ..

Step 3:

--- Input Variab1es (assignments)

Re:q(1) == true

1I.eq(Z) - true

Figure 6. Snapshot of the Test case generated by SAL-ATG for Arbiter

2010 2"" International Conference on Reliability, Safety & Hazard (ICRESH-201O)

55!:: ��t T�xtuaISynclrbit�r _ Scell�/R�q Itrue, fal�e, false, fal�e, fal��)

55!:: cycle

55!:: set Textual5ynclrb1ter _ Scells/Req Itrue, true, false, false, false)

55!:: cycle

55!:: ��t T�xtuaI5yncArbit�r _ Sc�lls/R�q Itru�, tru�, tru�, fals�, fals�)

55!:: cycle

55!:: set Textual5ynclrbiter _ Scells/Req Itrue, true, true, true, false)

55!:: cycle

55!:: set Textual5ynclrbiter _ Scells/Req Itrue, true, true, true, true)

55!:: cycl�

55!:: set Textual5ynclrbiter )cells/Req Itrue, true, true, true, true) 55!:: cycl�

55!:: set Textual5ynclrbiter _ Scells/Req Itrue, true, true, true, true)

55!:: cycle

55!:: ��t T�xtuaISynclrbit�r _ Sc�lls/R�q Itru�, tru�, tru�, tru�, tru�)

55!:: cycl�

55!:: set Textual5ynclrb1ter _ Scells/Req Itrue, true, true, true, true)

Figure 7. Snapshot of the SCADE scenario file obtained from test cases generated by SAL-ATG for Arbiter

We could achieve the full coverage with respect to MCIDC

criterion on simulating the SCADE model with generated test

cases. As shown in Fig. 8, all the SCADE operators with green

color (represented as black color in Fig. 8 on gray scale) are fully

covered and one operator is partially covered (OR 2 instantiated

inside ArbiterLogic 2), which is shown in yellow color

(represented as white color in Fig. 8 on gray scale). On analyzing

it, we found that operator OR 2 has two inputs and its flrst input is

always set to false, whereas according to MCIDC criterion the

combinations required to cover the two input logical OR

operator having inputs 11 and 12 are (not 11 and 12), (11 and not I2)

and (not 11 and not 12). As the flrst input was always set to false

the condition (11 and not 12) could never be generated. Hence

this test case is not feasible.

�IMTC ·115 C!!IMTC ·1\JIElel�Q ! Ii< .:1.111

MCOC_ArbiIer_MTC.efp eo... ... PoIh 80_ MTC2:::,6,UO 313 Atbier/Ml�erI..ogic WTC2:::AND 21

5Arbi1erLoOc'I25125J MTC2::ANO 313 Mier/AIb�erlogic 4/MTC2::AtlO 11 � 0 AtbiterLoOc 2 [241251 MTC2::OR 313 M:itw/Alb�erL. WTC2::0R 3J

5MTC2::AN01(3I3J MTC2::OR 313 Atbler/Alb�t.rl..3/Iro4TC2::0R21 hHC2;-.AN02(3I3J MTC2::OR 313 Arbler/AlbjerL.WTC2:::0Rll

&MTC2::At1D3(3I3J MTC2::OR 313 Arbler/AIb�erL.4Ih4TC2::0Rll So MTC2::AtlO4(3I3J MTC2::OR 313 Arl:ier/Alb�erL. WTC2:::0R 2J 5 Io4TC2::fBY) 1 (111) t.4TC2:::OfI 313 Atbler/AMerl.ogic WTC2:::0R 3J S MTC2::FBYJ 2(111) MTC2::AlIO 313 Art:irw/Alb�tJlogic 3Ih4TC2::ANO 4/ & MTC20,NOT1 1212J MTC2::AtIO 313 ArtU/AIb�erLogic lIMTC2:::N1O 3J & MTC20,ORII3131 MTC2:::ANO 313 MU/Albilerl.ogic3IMTC2::At1O 2J ° MTC20,OR212J31 MTC2::ANO 313 Atbier/�erl.oOc 3/MTC2::AtIO 11 o MTC�,OR 313131 MTC2::OR 313 Art:ier/Albilerl.ogic2Jh4TC2::0R3J

& MiloloOo 31251251 MTC2::ANO 313 Atbler/Albilerl.ogic5/h4TC2::ANO 11 & MiloloOo'l25I25l MTC2::OR 313 Mier/�erlogic 2MTC2::0R 11

& MiloloOo 51251251 j,1TC2::ANO 313 ArtU/AIb�erL.ogic 5IMTC2::ANO '21 So j,1TC2::NOT 1 (2/2) j,1TC2::ANO 313 ArtU/AIb�eri.ogic 5IMTC2::ANO 31

WCOC,JubioUIITC_INST . .tll j,1TC2::ANO 313 ArtU/AIb�eri.ogic 5IMTC2::ANO ., j,1TC2::ANO 313 ArtU/Mileri.ogic 2IMTC2::ANO ./ j,1TC2::ANO 313 ArtU/Ml�eri.ogic 2IMTC2::ANO 31 j,1TC2::ANO 313 ArtU/Ml�eri.ogic 2IMTC2::ANO '21 j,4TC2::ANO 313 MiIII/Ml�erLogic 2IMTC2::ANO 11 j,4TC2::OA 313 MiIII/Ml�erLcge 1MTC2::0A 31 j,4TC2:.OA 313 AttierIAlb�alogic: 1MTC2::0A 21 j,4TC2:.OA 313 Art:ier1Alb�erl.ogic 1IMTC2::0R 11 j,4TC2:.OR 313 Art:ier1Alb�erl.ogic5/MTC2::0R 11 j,4TC2:.OA 313 Art:ier1Alb •• Logic 5IMTC2:;OR 21

( � j,4TC2:.CJA 313 Art:ier1Alb •• Logic 5/MTC2::0R 31 j,4TC2:.ANO 313 Artier/Ml •• Logic 1IMTC2::ANO./ ..,

[iiFi. QlF ... :!:J�. )

Figure 8. MTC of 5 cell Arbiter

497

B. Case Study 2

This example is a part of controller for Steam Generator Pressure

Control (SGPC). The control logic in SGPC is divided into

m o d u l e s : C a l c_N LS P, C a l c_ C o n t r o l_S i g n a l a n d

Calc_ASDV_ControCSignal which are used to generate "No

Load Set Point (NLSP)", "Actual Control Signal" and "Control

signal for ASDVs" respectively. The complete speciflcation and

model based design of this controller has been discussed in [1 3].

We have only considered the flrst module called Calc _ NLSP.

This module has several fleld inputs and based on these inputs

application logic generates the present value for NLSP and Set

point rate (SPR) that is the rate at which the set point is to be

raised or lowered. The SCADE model for this example is given

in Fig. 9. This model has been translated to the SAL and the trap

variables are deflned in order to achieve the MCIDC based

model coverage as described in the previous case study. The

generated test cases using SAL-ATG are used to simulate the

SCADE model and model coverage has been measured.

.:::� I

... ,..

... -� ..

.JIf!�""'-".",-" •• _""-----,,

Figure 9. Model of Calc_NLSP node in SCADE

Result: For this case study, two test sequences were generated

one of length 1 3 and other of length 1. A snapshot of the test cases

generated by SAL-ATG and the corresponding SCADE scenario

me (i.e. model simulation input data me format in SCADE) are

shown in Fig. 1 0 and Fig. 11 respectively.

201O:r International Conference on Reliability, Safety & Hazard (ICRESH-201O)

2 tests generated; eotal length 13 �� test goa�s discharg8d_

Path

Step 0: --- Input Variab�as (assignments)

NLSP_fine_lower - false

NLSP_�ina_raisa = �a�sa NL SP_lower - false

NLSP_rai •• - ralse S PRl. - fa�5e

SPItZ = �a�s.

ST_tank_�eve�_�ow - fa�5e

auto_crash_cool = ralse

devia.tion - 0 jackup_.�f.ctiv. = �als . manua,l

_crash

_cool - fa.lse

aoderator_�eve�_�ow = fa�se

Path

Step 0: --- Input Variables (assignments)

NLSP_fine_lower = true

NLSP_

£ina_

raise - false

NLSP_lower = ralse

NLSP_

raisa = false

S PRl "" true

SPRZ = tru.e

ST_tank_level_1 ow "" ralse

auto_crash_cool = false

Figure 10. Snapshot of test case generated by SAL-ATG for Calc _ NLSP

SSM::��t Calc NLSP/NLSP fin� low�r fal�� SSM::�et CalC

-NLSP/NLSP

-fin�

-ra1�� fal��

SSM::set Calc-

NLSP/NLSP-

loue� false SSM::��t Calc-NLSP/NLSP-rai�e fal�e SSM::��t Calc-NLSP/SPR1-fal�� SSM::��t Calc

-NLSP/SPR2 fal��

SSM::��t Calc-

NLSP/ST tank level low fal�e SSM::set Calc=NLSP/auto_cr;sh_co�l false SSM::�et Calc NLSP/deviation 0 SSM::set Calc

-NLSP/jackup effective false

SSM::��t Calc-

NLSP/manual-

cra�h cool fal�e SSM::��t Calc=NLSP/mod�rator_l�;�l_IOW fal�� SSM: :cycl�

SSM::set Calc NLSP/NLSP fine lower true SSM::set Calc-NLSP/NLSP-fine-raise false SSM::��t Ca lc

-NLSP/NLSP- Iow�� fals�

SSM::set Calc-

NLSP/NLSP-

raise false SSM::set calc=NLSP/SPR1

-true

SSM::s�t Calc_NLSP/SPR2 true SSM::set Calc_NLSP/ST_tank_level_low false SSM::s�t Calc NLSP/auto crash cool false SSM::set Calc

-NLSP/devi;tion 3

SSM::s�t Calc=NLSP/jaCkUp_effectiv� false SSM::s�t Calc_NLSP/manual_crash_cool false SSM::set Calc_NLSP/moderator_level_low false SSM: : cycl�

Figure II. Snapshot of SCADE scenario file obtained from test cases generated by SAL-ATG for Ca1c_NLSP

The result of coverage achieved using SCADE MTC module,

on applying the generated test cases is shown in Fig. 12. We

could achieve 94.6 percent coverage. The full coverage could

not be achieved, because in SAL model obtained from the

corresponding SCADE model of Calc_NLSP all the real

variables were represented using integer variables and hence

some of the model behavior could not captured.

498

'8IMlt ,v 18 !!lIMIt v. C\ Q !l< J!l

.. �.JITUOTUOST .... A """"" r-.. p"" I'

Ii D C<IVI5I' 11IVI� /1/ C<IVI5I'MTQfTlf[lf[LI{J 101 "&_I� .TWFTIf[ff(U(J /1/ C<IVI5I'MTC2:fTlf(lf(LI{J IJ

&MTC2:IIIJIMI MlWFTIf[ff(U(J /1/ C<IVI5I'MTC2:fTIf[lf(LI{J II &NTC2:IIOTIIIJlI MlWFTIf[ff(U(J /1/ C<IVI5I'MTC2:fTlf[lf[LI{J II

D MlCh4IIDIIIJ3I MlWFTIf[H!U(J /II C<IVI5I'MTC2:fTIf(If[UlJ 51 & MlCh4IIDIIIJ3I MlWFTIf[ff(U(J /II totJUPM C2:fTHtNIUlJ 1/ & MlCh4IIDIIIJ3I MlWFTIf[ff(U(J /II totJUPMlC2:fTIf[HtLI{J 71 & MlCh4IID'1IJ3I MlWFTIf[H!U(J /II totJUPM C2:fTHtIf[UlJ 1/ &MlCh4IIDIIIJ3I MlWFTIf[ff(U(J /II totJUPMTC2:fTHtIf[LI{J 51 & MlC2:GIIIIJlI MlCHlT) III totJUPMTC2:NT)11 & MlWFTIf[If[LI{J 1 l/1li MlCHlT) 1/1 totJUPMTCHlTJIJ

MlWFTIf[NIUIJ 101/11 Mlail[ /II totJUPMTC2:LTlII MlWFTIf[NIUIJ 1l/1li MlC2:HCi1 In totJUPMTC2:HCiT 11 MlWFTIf[H!U(J 1l/1li MlC2:HCi1 /II totJUPMTC2:NOT v MlWFTHlIf[LI{J'1/III MlC2:HCi1 /II totJUPMTC2:NOT 1/

& MlWFTIf[H!U(JII/III MlC2:HCi1 /II totJUPMTC2:NOT" MlWFTIf[H!U(J 1l/1li MlC2:HCiT /II totJUPMTC2:NOT 51

& MlC2:fTHlIf[LI{J 7l/1li • C2:.OII 1/1 totJUPMTC2:OIIII MlC2:fTIf[NIUIJ I (Inl MlC2:.OII 1/1 totJf.srMTC2:OII v

& MlCUTIf[If[UlJ I (Inl MlrutII 1/1 t.k.IUPMIQ.OII !I • MlQ.NTJ1MI MlrutII III t.kJUPMTrutlllI • MlQ.NTJ2""1 MlQ.NTJ III t.k.II.SI'�"'M'C2.NTJlI DMlCUI[IQJ21 MlCUOT /II t.k.II.SI'�"'M1CUOT5I

MlC2.&1[ /II ������� . -,,,.nn.GTE I." IllIlo.. (i'jr.... iMl �.T . --. --- . . .

Figure 12. MTC of Calc _ NLSP node

V. CONCLUSION AND FUTURE WORK

. .. _-_._;

The results presented in the paper are based on experimental

work, where the translation from SCADE to SAL was done

manually. The test goals to be specified as trap variables are also

defmed manually. Initial results are quite encouraging, as the

technique could generate test cases meeting the coverage

criterion.

In future, we want to develop an automatic translation scheme

for translating SCAD E models to SAL specification. This is not a

trivial job as the translator must preserve the semantics of

SCADE language. We are working towards this. The

effectiveness of the scheme can be studied after such a translator

is built which will enable us to treat large SCADE models

involving arithmetic and complex state machines.

ACKNOWLEDGMEN TS

We are thankful to Shri B.B. Biswas, Head Reactor Control

Division, Shri R.K. Pati!, Associate Director (E&I Group) and

Shri G.P. Srivastava, Director (E&I Group), for supporting this

work. We also would like to thank Board of Research in Nuclear

Sciences (BRNS) to support this work through a research grant

to CFDVS, lI T Bombay.

REFERENCES

[I] SCADE Tool http://www.esterel-technologies.coml.

[2] SCADE User Manual, Ver 6. 1, Esterel Technologies Ltd., France

[3] DO- 178B "Software Considerations in Airborne Systems and Equipment Ceritification", RTCAIEUROCAE, 1992.

[4] Edmund M. Clarke et aI., Model Checking , The MI T Press, 1999

[5] SCADE Language Reference Manual, Ver 6.1, Esterel Technologies Ltd., France

[6] Leonardo de Moura, Sam Owre, N.shankar, The SAL Language Manual,

20l0:r International Conference on Reliability, Safety & Hazard (ICRESH-201O)

CSL Technical Report SRI-CSL-OI-02, August, 2003

[7] Gregoire Hamon, Leonardo de Moura and John Rushby, Automated Test Generation with SAL, CSL Technical Note, January 2005

[8] A. Biere et aI., Bounded Model Checking Vol. 58, Advances in Computers, 2003 (Academic Press)

[9] N. Halbwachs, P. Caspi, P. Raymond and D. Pilaud, The synchronous dataflow programming language Lustre. Proceedings of the IEEE, vol. 79(9). September 1991.

[10] N. Halbwachs, Synchronous programming of reactive systems. Kluwer

499

Academic Pub, 1993.

[11] Brent Welch, Practical Programming in Tcl and Tk, January, 1995

[12] McMillan K., Symbolic Model Checking, Kluwer Academic Publisher, 1993

[13] A. Wakankar, R. Mitra, A.K. Bhattacharjee, S.Y. Shrikhande, S.D. Dhodapkar, R.K. Patil, Formal Model Based Methodology for Developing Controllers for Nuclear Applications, ISSRE-2009