Validation of Communications Systems with SDL phần 5 potx

5.2.1 Simulate with user-defined rules In the Validator, only one user-defined rule can be used at a time.. This means, in our V.76 SDL model, that: • instance 1 of process DLC in block DL

sigA

sigC

inst_dlca DLCa

sigB

Figure 5.4 The observer MSC obs 1

of the MSC to verify: in this case, the Simulator will not explore the states leading to an error (a violation) of the MSC, because the default configuration is error cut (equivalent to

prune in Tau).

5.2 CASE STUDY WITH TAU SDL SUITE

In Chapter 4, we have used the Tau SDL Suite Simulator To benefit from automatic observationfeatures, we will now switch to the Tau SDL Suite Validator Note that the Simulator can also

be used to check the SDL model against an MSC

5.2.1 Simulate with user-defined rules

In the Validator, only one user-defined rule can be used at a time To check several conditions,

you can use the operator or to group them in a single rule.

5.2.1.1 Detect DLC establishment

We want to detect that a DLC is established This means, in our V.76 SDL model, that:

• instance 1 of process DLC in block DLCa is in state connected, and

• instance 1 of process DLC in block DLCb is in state connected.

It seems that the Validator rules do not accept qualifiers such as <<Block DLCa>> As

there are two processes named DLC, one in block DLCa and the other in block DLCb, it is not possible to write a rule to detect that both DLCs are in state connected An observer process

could be used instead

The solution would be to modify the SDL model to have a copy of block V76 DLC on each side: transformation of the block type V76 DLC into a block named V76a, making a copy of it and naming the copy V76b and in each block, renaming the DLC process, respectively, DLC a and DLC b Then, the Validator user-defined rule would be:

state(DLC_a:1)=connected and state(DLC_b:1)=connected

Rather than performing this model modification, you will use rules concerning process AtoB and BtoA, which do not require the use of qualifiers, as they are unique in the system.

5.2.1.2 Detect state of processes AtoB and BtoA

We want to detect that in our V.76 SDL model:

• instance 1 of process AtoB is in state ready and

• instance 1 of process BtoA is in state ready.

This condition, translated into a Validator rule, becomes:

state(AtoB:1)=ready and state(BtoA:1)=ready

Compile the SDL model, start the Validator and test the rule:

A In the Organizer, select the SDL system V76test and do Generate > Make: the window

represented in Figure 5.5 appears Select Microsoft Validation or Borland Validation, and press Full Make.

Figure 5.5 The SDL Make window set for validation

B In the Organizer, press the Validate button to start the Validator The Validator mainwindow appears, as shown in Figure 5.6

C In the Validator command line, enter:

Define-Rule state(AtoB:1)=ready and state(BtoA:1)=ready

D Then, to test if the rule is satisfied or not for the current SDL model state, enter:

Evaluate-Rule state(AtoB:1)=ready and state(BtoA:1)=ready

Figure 5.6 The Validator main window

The Validator answers:

Evaluating rule:

(( state( AtoB:1 ) = ready) and (state( BtoA:1 ) = ready ))Rule not satisfied

This is normal, as the processes are not yet in state ready.

E Select View > Command Window : you see that the processes AtoB:1 and BtoA:1 are in

G In the Validator command line, enter:

Evaluate-Rule state(AtoB:1)=ready and state(BtoA:1)=ready

As expected, the Validator answers:

Evaluating rule:

(( state( AtoB:1 ) = ready) and (state( BtoA:1 ) = ready ))User-defined rule satisfied

You can check in the Command Window that the processes AtoB and BtoA are in state ready.

We have executed the transitions manually using the Navigator; we will see later that thetransitions can also be executed automatically by the Validator, using several algorithms such

as exhaustive simulation: then reports are automatically generated each time the user-definedrule is satisfied

5.2.1.3 More user-defined rules

Here are some more user-defined rules that you can enter in the Validator as indicated previously

To detect that variable foo1 in process AtoB contains 4:

Define-Rule offspring(AtoB:1) = Null

As you can see, several conditions in the SDL model can be detected by user-defined rulesduring the validation However, user-defined rules cannot detect the correct sequencing ofsignals: for that, you must use MSCs

5.2.2 Simulate with a basic MSC

You will simulate the V.76 SDL model, observed by a basic MSC Basic means that the MSCjust contains a single scenario, as opposed to MSCs containing inline operators or to High-Level

MSCs (HMSC) To simplify, we reuse the basic MSC test1.msc, generated by the Simulator

in Chapter 4 Naturally, you could use another MSC drawn from scratch with the Editor orrework an existing MSC

In Tau SDL Suite Validator3, an MSC is not only observing but also driving the simulation

A Select File > Restart in the Validator, and enter the command:

B Select Commands > Toggle MSC Trace.

C Press the Navigator button in the Explore group The Navigator window appears, as

illus-trated in Figure 5.8 By double-clicking in this window, you can execute transitions in theSDL model, going forward (down) but also backward (up)

Figure 5.8 The Navigator window

D In the Navigator window, double-click on the lower rectangle, marked Next 1, to execute

the corresponding SDL transition

E Continue double-clicking; when there are several possibilities, select the left one

F After around 45 transitions, the Navigator window displays: No down node – MSC test1

verified, as shown in Figure 5.9 It means that the signal sequence present in the loaded

MSC has been simulated You can see that the trace MSC is identical to the loaded MSC.Note that if the simulated parameter values did not match the MSC expected values, theMSC property would not have been satisfied

3 The MSCs can also be verified using the Simulator rather than the Validator.

Figure 5.9 The MSC test1 is verified

5.2.3 Simulate with an MSC containing inline operators

The basic MSC test1 used in the previous section represents only a single execution sequence.

To represent several expected behaviors consistent with the V.76 textual specification without

creating too many basic MSCs, we will add inline operators to the MSC test1

5.2.3.1 Create the MSC

With the MSC Editor, you will rework a copy of the basic MSC test1.msc generated by the Simulator in Chapter 4, to obtain the MSC test1inline.msc, shown in Figure 5.10:

A In Windows (or Unix), make a copy of the file test1.msc into test1inline.msc

B In the Organizer, select Tools > Editors > MSC Editor

C In the MSC Editor, select File > Open and choose test1inline.msc

D Enter the MSC name test1inline, and remove the XID part (eight signals from L SetparmReq

G Using the Symbol Menu, insert one loop and two alt inline operators, depicted in

Figure 5.10 Resize them and add two expression separators, to obtain the layout shown inFigure 5.11

2 alt

1

1 loop <0, inf>

1

1 alt

1

2

loop operator alt operator (alternative) expression separator

Figure 5.10 The inline MSC operators used in test1inline.msc

This MSC represents the following behavior expected from the V.76 SDL model:

1 one connection phase,

2 followed any number of times (between 0 and infinite) by the repetition (operator loop

<0, inf>) of data transfers from A to B or (operator alt) from B to A,

3 followed by the disconnection phase initiated by A or (second alt operator) initiated by B.

5.2.3.2 Use the MSC to check the SDL model

A Start the Validator as indicated in Section 5.2.1.2, and enter the command:

load-msc test1inline.msc

B Select Commands > Toggle MSC Trace.

C Press the Navigator button in the Explore group.

D Using the Navigator, execute an SDL scenario matching the loaded MSC (when there aretwo possibilities, select the left one): for example, establish DLC number 0, then transmitdata 86, and then release DLC number 0

E After around 40 transitions, the Navigator window displays: No down node – MSC test1inline

verified, as shown in Figure 5.12 It means that one of the signal sequences present in the

loaded MSC has been simulated The Navigator also indicates which MSC operators have

been followed and which branch has been taken in each alt operator.

You could press the button Top in the Explore group to go back to the initial SDL model

state, and try to verify other paths, for example, no data transfer, or a data transfer from B to

A and so on

F Exit from the Validator

block DLCb DLCa_2

block DLCa

dataLink_1

block dataLink

2

2 alt

1

1 loop <0, inf>

1

1 alt

1 2

MSC test1inline

L_DataInd ( 0, 86)

L_EstabResp L_EstabInd (0)

L_DataReq ( 0, 39 )

L_ReleaseReq (0) V76frame ( DISC : ( 0 ) )

V76frame ( UA : ( 0 ))

V76frame ( UA : ( 0 ))

V76frame ( DISC : ( 0 ))

V76frame ( DISC : ( 0 )) V76frame (DISC : ( 0 ))V76frame

( UA : ( 0 ) )

V76frame ( UA : ( 0 ) )

V76frame ( I : ( 0, 86, 15 )) V76frame

( I : ( 0, 86, 15 ) )

V76frame (UA : ( 0 ) )

V76frame (UA : ( 0 ))

V76frame ( SABME : ( 0 ) )

V76frame ( SABME : ( 0 ) )

L_ReleaseInd (0)

L_ReleaseInd (0) L_ReleaseInd (0)

The idea with HMSC [MSC96] is to combine several MSCs (containing or not inline operators)

to get a good overview of the expected behaviors

Remark : to be used in the Validator, all the MSCs used in an HMSC must contain the same

entities; for example, it is not allowed to have block DLCa in one MSC and <<block DLCa>> process DLC in another MSC.

second operator branch 1 followed

Figure 5.12 The MSC test1inline is verified

5.2.4.1 Create the HMSC

With the MSC Editor, you will rework a copy of the basic MSC test1.msc generated by the Simulator in Chapter 4, to obtain the hierarchical HMSC test1ops.msc shown in Figure 5.13 This HMSC test1ops represents the following behavior expected from the V.76 SDL model4:

1 one connection phase (cnx1h),

2 followed or not by the repetition of data transfers from A to B (data a2b) or from B to A (data b2a),

3 followed by the disconnection phase initiated by A (disc 0 by a) or initiated by B (disc 0 by b).

A In the Organizer, select Edit > Add New, check MSC, choose HMSC, enter the document

name test1ops, as shown in Figure 5.14, and press OK.

B The HMSC Editor appears Draw the HMSC represented in Figure 5.13, and save it into

the file test1ops.mrm.

Now create the five MSCs referenced in the HMSC:

C In Windows (or Unix), make copies of the file test1inline.msc into the files: cnx1h.msc,

data a2b.msc, data b2a.msc, disc 0 by a.msc and disc 0 by b.msc.

D In the Organizer, select Edit > Add Existing and choose cnx1h.msc The MSC is loaded

into the MSC Editor

4 To simplify the example, this HMSC is incomplete: connection initiated by B is missing, DLC number 1 is not tested and so on.

bypass (no data)

Figure 5.13 The HMSC test1ops.msc

Figure 5.14 Adding HMSC test1ops

E In the MSC Editor, remove all signals or operators except the connection part (the first eight

signals), replace (just type directly) MSC test1inline by MSC cnx1h, and save the MSC into

cnx1h.msc The resulting MSC is shown in Figure 5.15.

F Repeat the two previous steps for the following MSCs: data a2b.msc, data b2a.msc,

disc 0 by a.msc and disc 0 by b.msc, respectively, shown in Figures 5.16 to 5.19.

DLCbSU

block DLCb DLCa_2

block DLCa

dataLink_1

block dataLink

MSC cnx1h

L_EstabResp L_EstabInd (0)

L_EstabConf (0)

L_EstabReq

(0)

V76frame (UA : ( 0 ) )

V76frame (UA : ( 0 ))

V76frame ( SABME : ( 0 ) )

V76frame ( SABME : ( 0 ) )

Figure 5.15 The MSC cnx1h.msc

DLCbSU

block DLCb DLCa_2

block DLCa

dataLink_1

block dataLink

MSC data_a2b

L_DataInd ( 0, 86)

block DLCa

dataLink_1

block dataLink

MSC data_b2a

L_DataReq ( 0, 39 ) L_DataInd (0, 39) V76frame

( I : ( 0, 39, 15 ))

V76frame ( I : ( 0, 39, 15 ) )

Figure 5.17 The MSC data b2a.msc

G The Organizer should now look like Figure 5.20 The MSCs have been inserted into the

Organizer because it is used to translate the name of the referenced MSCs such as cnx1h into their actual file name (which could be different from cnx1h.msc).

H Press save in the Organizer to update the sdt file.

block DLCb DLCa_2

block DLCa

dataLink_1

block dataLink

MSC disc_0_by_a

V76frame ( DISC : ( 0 ))

V76frame (DISC : ( 0 ))

V76frame ( UA : ( 0 ) )

V76frame ( UA : ( 0 ) ) L_ReleaseInd (0)

block DLCa

dataLink_1

block dataLink

MSC disc_0_by_b

L_ReleaseReq (0) V76frame ( DISC : ( 0 ) )

V76frame ( UA : ( 0 ))

V76frame ( UA : ( 0 ))

V76frame ( DISC : ( 0 ))

L_ReleaseInd (0)

L_ReleaseInd (0)

Figure 5.19 The MSC disc 0 by b.msc

Figure 5.20 The HMSC test1ops and the five referenced MSCs in the Organizer

5.2.4.2 Use the HMSC to check the SDL model

A Start the Validator as indicated in Section 5.2.1.2, and enter the command5:

load-msc test1ops.mrm

B Select Commands > Toggle MSC Trace.

C Press the Navigator button in the Explore group.

D Using the Navigator, execute an SDL scenario matching the loaded HMSC (when there aretwo possibilities, select the left one): for example, establish DLC number 0, then transmitdata 86, and then release DLC number 0

E After around 37 transitions, the Navigator window displays: No down node – MSC test1inline

verified, as shown in Figure 5.21 It means that one of the signal sequences present in the

loaded HMSC has been simulated The Navigator also indicates which MSCs have beenfollowed in the HMSC These MSCs have been manually shown in bold in the figure

cnx1h

data_b2a

disc_0_by_b disc_0_by_a

data_a2b

the simulated path

Figure 5.21 The MSC test1ops is verified

You could press the buttons Top or Up in the Explore group to go back to the initial or to

the previous SDL model states, and try to verify other paths, for example, no data transfer, or

a data transfer from B to A and so on

5If the load-msc command reports errors, check that inline expression separators (horizontal dashed lines) do not

remain in the faulty MSC.

5.2.5 More details on MSCs

5.2.5.1 How the Validator monitors the MSC events

When verifying an MSC (or HMSC), the Validator checks that the events occurring during thesimulation are identical to the events specified in the MSC For example, in Figure 5.22, after

the output of sA, the output of sB is expected Unfortunately, the output of sZ occurs and the Validator detects a violation of the MSC test seq6

MSC seq_sim

sA sZ

proc1 inst_proc1 MSC test_seq

sA sB

5.2.5.2 The MSC symbols used by the Validator

During MSC or HMSC loading (either using the textual command Load-MSC or the button

Verify MSC ), the Validator checks that all the elements used in the MSC exist in the SDL model.

For example, in Figure 5.23, the following checks are performed during MSC loading:

• The entity named dataLink in the MSC retry1 exists in the SDL model HDLC.

• The signal v76frame in the MSC also exists in the SDL model.

• The environment instance contains either env 0 or an external channel name (such as

SIGNAL v76frame(v76_par);

Figure 5.23 An MSC (b) consistent with the SDL model HDLC (a)

6In ObjectGeode, signal sZ would have been ignored because it is not in the observer MSC To get a violation as in Tau, sZ must be declared as unexpected signal in the MSC simulation properties.

signal input signal parameters

dataLink_1

block dataLink DLC_1_5

Figure 5.24 The MSC symbols checked dynamically

The following MSC symbols, depicted in Figure 5.24, are dynamically checked by the idator during simulation:

Val-• Signal input and output and their parameter values,

• Timer set, reset and timeout,

• Process instance create and stop,

• Global MSC reference (without substitution and gates),

• Condition (if Define-Condition-Check is on, default is off).

The other symbols present in the MSC, shown in Figure 5.25, are ignored

MSC retry1

L_EstabReq (0) L_ReleaseReq (0)

DLC

Figure 5.25 The MSC symbols not checked dynamically

5.2.5.3 The MSC signal parameters

The values of the signal parameters in an MSC to be verified can be omitted: in that case, theyare not checked