Hello,

I will give the following practical situation we faced:

alt
{

[] controllerPort.receive(CreateListByName_ErrorAck
(ErrorInfo))
{
f_LogMessage ("Proper message
received");
}

[] controllerPort.receive(MostFBMsg:{omit, omit, ?, ?,
*})
{
f_LogMessage("alt_FBlock_Raw_Any", " Received an
unexpected message from the same function block");
repeat;
}

[] TGuard.timeout
{
f_LogMessage("alt_Timeout", "Timeout - testcase
not ended in proper time");
setverdict(fail);
mtc.stop;
}
}

Fort the altstep above the MostFBMsg is a template that defines any
message that can be traced by our test system for the currently tested
module.

In the case the expected message is never coming what we observed is that
if we have a high load of messages on the bus used by our test system for
communication TGuard.TimeOut is not treated at all because lots of "any"
messages arrive and trigger the repeat. TGuard.timeout is never reached.

Is this the normal behavior of TTCN-3?

How is the timeout handled? Is it normal to still catch messages that
appeared after the timeout event of a timer? Doesn't the order of events
in time count for treating sequentially the messages and timeout events?

Thanks in advance,

Maria

..........................................................
Mit den besten Gruessen / Best regards
Maria Teodorescu
Project Manager
I MM IAS SW TA


Siemens VDO Automotive SRL
Bld. Poitiers no. 10
700671 Iasi, Romania

A Continental Corporation company

Tel.: +40 232 30 -7318
Fax: +40 232 22 -0335
E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
www.continental-corporation.com
Proprietary and confidential. Distribution only by express authority of
Continental AG or its subsidiaries.

Hi Maria,

It´s the order of the alt what matters. You will never evaluate the
option of the timeout until you stop receiving unexpected messages.
Before you enter the alt a snapshot of the system is taken and the
alternatives are evaluated in order. If one is true then it doesn't
evaluate the rest

One option to solve the problem could be not to repeat the alt when an
unexpected message comes, set the verdict to fail and stop (like in the
timeout statement), but only if you want to cancel the execution (if not
you should read all the messages coming)

Another option that might fit to your purpose is to set a timer for the
testcase itself (i.e. MyVerdict := execute(MyTestCase(),3)). This will
limit the execution of the testcase to 3 seconds, giving an error if the
timeout is reached

Best regards,
Jesús

Teodorescu Maria escribió:
>
> Hello,
>
> I will give the following practical situation we faced:
>
> alt
> {
>
> [] controllerPort.receive(CreateListByName_ErrorAck
> (ErrorInfo))
> {
> f_LogMessage ("Proper message
> received");
> }
>
> [] controllerPort.receive(MostFBMsg:{omit, omit, ?,
> ?, *})
> {
> f_LogMessage("alt_FBlock_Raw_Any", " Received
> an unexpected message from the same function block");
> repeat;
> }
>
> [] TGuard.timeout
> {
> f_LogMessage("alt_Timeout", "Timeout -
> testcase not ended in proper time");
> setverdict(fail);
> mtc.stop;
> }
> }
>
> Fort the altstep above the MostFBMsg is a template that defines any
> message that can be traced by our test system for the currently tested
> module.
>
> In the case the expected message is never coming what we observed is
> that if we have a high load of messages on the bus used by our test
> system for communication TGuard.TimeOut is not treated at all because
> lots of "any" messages arrive and trigger the repeat. TGuard.timeout
> is never reached.
>
> Is this the normal behavior of TTCN-3?
>
> How is the timeout handled? Is it normal to still catch messages that
> appeared after the timeout event of a timer? Doesn't the order of
> events in time count for treating sequentially the messages and
> timeout events?
>
> Thanks in advance,
>
> Maria
>
> ..........................................................
> Mit den besten Gruessen / Best regards
> Maria Teodorescu
> Project Manager
> I MM IAS SW TA
>
>
> Siemens VDO Automotive SRL
> Bld. Poitiers no. 10
> 700671 Iasi, Romania
>
> A Continental Corporation company
>
> Tel.: +40 232 30 -7318
> Fax: +40 232 22 -0335
> E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> www.continental-corporation.com
> Proprietary and confidential. Distribution only by express authority
> of Continental AG or its subsidiaries.


--





*Jesús Domínguez Colino*

Consultor Senior





Pº de la Castellana, 182 - 10ª planta

28046 - Madrid

Tel.: +34 913531564

Fax: +34 913596179

*www.mtp.es* <www.mtp.es>

Hello Maria,

an easy solution would be to guard the first 2 branches of the
alternative with 'TGuard.running', so that they are not checked anymore
after the timer timouts.

Then the code will look like this:

alt
{

Hi Maria,

in addition to Jesús proposals, I see another option. In order to
observe the timeout event, even if the "any" port queue is fully
blocked, you should change the order of TGuard.timeout with
controllerPort.receive(MostFBMsg:{omit, omit, ?, ?, *}).

Best regards,
Stephan

Am 21.05.2008 um 09:49 schrieb Jesús Domínguez Colino:

> Hi Maria,
>
> It´s the order of the alt what matters. You will never evaluate the
> option of the timeout until you stop receiving unexpected messages.
> Before you enter the alt a snapshot of the system is taken and the
> alternatives are evaluated in order. If one is true then it doesn't
> evaluate the rest
>
> One option to solve the problem could be not to repeat the alt when
> an unexpected message comes, set the verdict to fail and stop (like
> in the timeout statement), but only if you want to cancel the
> execution (if not you should read all the messages coming)
>
> Another option that might fit to your purpose is to set a timer for
> the testcase itself (i.e. MyVerdict := execute(MyTestCase(),3)).
> This will limit the execution of the testcase to 3 seconds, giving
> an error if the timeout is reached
>
> Best regards,
> Jesús
>
> Teodorescu Maria escribió:
>>
>>
>> Hello,
>>
>> I will give the following practical situation we faced:
>>
>> alt
>> {
>>
>> [] controllerPort.receive(CreateListByName_ErrorAck
>> (ErrorInfo))
>> {
>> f_LogMessage ("Proper
>> message received");
>> }
>>
>> [] controllerPort.receive(MostFBMsg:{omit,
>> omit, ?, ?, *})
>> {
>> f_LogMessage("alt_FBlock_Raw_Any", "
>> Received an unexpected message from the same function block");
>> repeat;
>> }
>>
>> [] TGuard.timeout
>> {
>> f_LogMessage("alt_Timeout", "Timeout -
>> testcase not ended in proper time");
>> setverdict(fail);
>> mtc.stop;
>> }
>> }
>>
>> Fort the altstep above the MostFBMsg is a template that defines any
>> message that can be traced by our test system for the currently
>> tested module.
>>
>> In the case the expected message is never coming what we observed
>> is that if we have a high load of messages on the bus used by our
>> test system for communication TGuard.TimeOut is not treated at all
>> because lots of "any" messages arrive and trigger the repeat.
>> TGuard.timeout is never reached.
>>
>> Is this the normal behavior of TTCN-3?
>>
>> How is the timeout handled? Is it normal to still catch messages
>> that appeared after the timeout event of a timer? Doesn't the order
>> of events in time count for treating sequentially the messages and
>> timeout events?
>>
>> Thanks in advance,
>>
>> Maria
>>
>> ..........................................................
>> Mit den besten Gruessen / Best regards
>> Maria Teodorescu
>> Project Manager
>> I MM IAS SW TA
>>
>>
>> Siemens VDO Automotive SRL
>> Bld. Poitiers no. 10
>> 700671 Iasi, Romania
>>
>> A Continental Corporation company
>>
>> Tel.: +40 232 30 -7318
>> Fax: +40 232 22 -0335
>> E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> www.continental-corporation.com
>> Proprietary and confidential. Distribution only by express
>> authority of Continental AG or its subsidiaries.
>
>
> --
>
> <bajoemailfirmaT3UC.jpg>
>
> Jesús Domínguez Colino
> Consultor Senior
>
> <Logo_Mtp_firmaweb.gif>
>
> Pº de la Castellana, 182 - 10ª planta
> 28046 - Madrid
> Tel.: +34 913531564
> Fax: +34 913596179
> www.mtp.es

Hello Maria,

you might consider to reorder the second and third alternative. At first check for a timeout and at second check for unexpected messages. Still, unexpected messages received before the occurrence of the timeout will trigger the alternative.
The solution proposed by Valentin is not possible as the 'running' operation cannot be used in the boolean guard of an alternative, see clause 16.1.4.

Best regards

Thomas

---

| Thomas Deiß |
| Nokia Siemens Networks Deutschland GmbH |
| Heltorferstrasse 21 |
| D-40472 Düsseldorf |
| Mobile: +49 1639842217 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext Valentin Zaharescu
Sent: Wednesday, 21. May 2008 10:10
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Timers handling in TTCN-3


Hello Maria,

an easy solution would be to guard the first 2 branches of the alternative with 'TGuard.running', so that they are not checked anymore after the timer timouts.

Then the code will look like this:

alt
{

[TGuard.running] controllerPort.receive(CreateListByName_ErrorAck (ErrorInfo))
{
f_LogMessage ("Proper message received");
}

[TGuard.running] controllerPort.receive(MostFBMsg:{omit, omit, ?, ?, *})
{
f_LogMessage("alt_FBlock_Raw_Any", " Received an unexpected message from the same function block");
repeat;
}

[] TGuard.timeout
{
f_LogMessage("alt_Timeout", "Timeout - testcase not ended in proper time");
setverdict(fail);
mtc.stop;
}
}


Best regards,
Valentin

Teodorescu Maria schrieb:


Hello,

I will give the following practical situation we faced:

alt
{

[] controllerPort.receive(CreateListByName_ErrorAck (ErrorInfo))
{
f_LogMessage ("Proper
message received");
}

[] controllerPort.receive(MostFBMsg:{omit, omit,
?, ?, *})
{
f_LogMessage("alt_FBlock_Raw_Any", "
Received an unexpected message from the same function block");
repeat;
}

[] TGuard.timeout
{
f_LogMessage("alt_Timeout", "Timeout - testcase not ended in proper time");
setverdict(fail);
mtc.stop;
}
}

Fort the altstep above the MostFBMsg is a template that defines any
message that can be traced by our test system for the currently tested module.

In the case the expected message is never coming what we observed is
that if we have a high load of messages on the bus used by our test system for communication TGuard.TimeOut is not treated at all because lots of "any" messages arrive and trigger the repeat. TGuard.timeout is never reached.

Is this the normal behavior of TTCN-3?

How is the timeout handled? Is it normal to still catch messages
that appeared after the timeout event of a timer? Doesn't the order of events in time count for treating sequentially the messages and timeout events?

Thanks in advance,

Maria

..........................................................
Mit den besten Gruessen / Best regards
Maria Teodorescu
Project Manager
I MM IAS SW TA


Siemens VDO Automotive SRL
Bld. Poitiers no. 10
700671 Iasi, Romania

A Continental Corporation company

Tel.: +40 232 30 -7318
Fax: +40 232 22 -0335
E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
www.continental-corporation.com
Proprietary and confidential. Distribution only by express authority
of Continental AG or its subsidiaries.



--

---

Valentin Zaharescu
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 17 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS

May 26-28, Tutorial "Theory & Practice of TTCN-3", Berlin (Germany)
www.testingtech.com/services/ttcn3_tutorial.php

June 3-6, TTCN-3 User Conference (T3UC), Madrid (Spain), Booth #T1
www.mtp.es/TTCN3UC2008/home.html

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805 B, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hi Maria,

Yes, this is the normal semantics of TTCN-3, your tool behaves according to the standard. Once a branch of your alt is selected, execution continues along the selected branch (i.e. conditions in the alt branches following the selected one are not checked). You are Simply "sending back" your code to take a new snapshot with the repeat statement and there always exist a message at the top of the queue of controllerPort, which is matching MostFBMsg:{omit, omit, ?, ?, *} .

If this is a problem for you, you also have to check the timer expiry after receiving each message, e.g.:

altstep as_CheckTGuard () runs onMyCT { // I suppose here that TGuard is a component timer, if not, pass in as parameter
[] TGuard.timeout
{
f_LogMessage("alt_Timeout", "Timeout - testcase not ended in proper time");
setverdict(fail);
mtc.stop;
}
[else] {}
}

alt
{
[] controllerPort.receive(CreateListByName_ErrorAck (ErrorInfo))
{
f_LogMessage ("Proper message received");
as_CheckTGuard ()
}

[] controllerPort.receive(MostFBMsg:{omit, omit, ?, ?, *})
{
f_LogMessage("alt_FBlock_Raw_Any", " Received an unexpected message from the same function block");
as_CheckTGuard ()
repeat;
}

[] as_CheckTGuard () {repeat}
}


Note: an interleave will not help here, as this also most probably expanded to an alt, where message receipt preceeds the timeout checking.

BR, Gyorgy


________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Teodorescu Maria
Sent: Wednesday, 21 May, 2008 9:18 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Timers handling in TTCN-3



Hello,

I will give the following practical situation we faced:

alt
{

[] controllerPort.receive(CreateListByName_ErrorAck (ErrorInfo))
{
f_LogMessage ("Proper message received");
}

[] controllerPort.receive(MostFBMsg:{omit, omit, ?, ?, *})
{
f_LogMessage("alt_FBlock_Raw_Any", " Received an unexpected message from the same function block");
repeat;
}

[] TGuard.timeout
{
f_LogMessage("alt_Timeout", "Timeout - testcase not ended in proper time");
setverdict(fail);
mtc.stop;
}
}

Fort the altstep above the MostFBMsg is a template that defines any message that can be traced by our test system for the currently tested module.

In the case the expected message is never coming what we observed is that if we have a high load of messages on the bus used by our test system for communication TGuard.TimeOut is not treated at all because lots of "any" messages arrive and trigger the repeat. TGuard.timeout is never reached.

Is this the normal behavior of TTCN-3?

How is the timeout handled? Is it normal to still catch messages that appeared after the timeout event of a timer? Doesn't the order of events in time count for treating sequentially the messages and timeout events?

Thanks in advance,

Maria

..........................................................
Mit den besten Gruessen / Best regards
Maria Teodorescu
Project Manager
I MM IAS SW TA


Siemens VDO Automotive SRL
Bld. Poitiers no. 10
700671 Iasi, Romania

A Continental Corporation company

Tel.: +40 232 30 -7318
Fax: +40 232 22 -0335
E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
www.continental-corporation.com
Proprietary and confidential. Distribution only by express authority of Continental AG or its subsidiaries.

Hi,

to add another solution to the problem:

Thomas is right, pointing out that some boolean operators can not be
used in guards.

Howeer, with a slight modification the solution proposed by Valentin can
still be used, while Maria's goal can be achieved.

var boolean tgRunning := false;
alt
{
[tgRunning]
controllerPort.receive(CreateListByName_ErrorAck (ErrorInfo))
{
f_LogMessage ("Proper message received");
gRunning := TGuard.running;
}
[tgRunning] controllerPort.receive(MostFBMsg:{omit,
omit, ?, ?, *})
{
f_LogMessage("alt_FBlock_Raw_Any", " Received
an unexpected message from the same function block");
gRunning := TGuard.running;
repeat;
}

[] TGuard.timeout
{
f_LogMessage("alt_Timeout", "Timeout - testcase
not ended in proper time");
setverdict(fail);
mtc.stop;
}
}

This would preserve the atomicity of the snapshot-semantic and solve
Marias problem. (Of course I am aware that it solves the problem only
partially as at least one "superfluous" message will be "captured". ;-)

Best regards,
Theo

---

Von: Thomas Deiss [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Gesendet: Mittwoch, 21. Mai 2008 10:23
An: This email address is being protected from spambots. You need JavaScript enabled to view it.
Betreff: Re: Timers handling in TTCN-3



Hello Maria,

you might consider to reorder the second and third alternative. At first
check for a timeout and at second check for unexpected messages. Still,
unexpected messages received before the occurrence of the timeout will
trigger the alternative.
The solution proposed by Valentin is not possible as the 'running'
operation cannot be used in the boolean guard of an alternative, see
clause 16.1.4.

Best regards

Thomas

---

| Thomas Deiß |
| Nokia Siemens Networks Deutschland GmbH |
| Heltorferstrasse 21 |
| D-40472 Düsseldorf |
| Mobile: +49 1639842217 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

---

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext Valentin Zaharescu
Sent: Wednesday, 21. May 2008 10:10
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Timers handling in TTCN-3


Hello Maria,

an easy solution would be to guard the first 2 branches of the
alternative with 'TGuard.running', so that they are not checked anymore
after the timer timouts.

Then the code will look like this:

alt
{

[TGuard.running]
controllerPort.receive(CreateListByName_ErrorAck (ErrorInfo))
{
f_LogMessage ("Proper message
received");
}

[TGuard.running]
controllerPort.receive(MostFBMsg:{omit, omit, ?, ?, *})
{
f_LogMessage("alt_FBlock_Raw_Any", " Received
an unexpected message from the same function block");
repeat;
}

[] TGuard.timeout
{
f_LogMessage("alt_Timeout", "Timeout - testcase
not ended in proper time");
setverdict(fail);
mtc.stop;
}
}


Best regards,
Valentin

Teodorescu Maria schrieb:

Hello,

I will give the following practical situation we faced:

alt
{

[] controllerPort.receive(CreateListByName_ErrorAck
(ErrorInfo))
{
f_LogMessage ("Proper message
received");
}

[] controllerPort.receive(MostFBMsg:{omit, omit, ?,
?, *})
{
f_LogMessage("alt_FBlock_Raw_Any", " Received
an unexpected message from the same function block");
repeat;
}

[] TGuard.timeout
{
f_LogMessage("alt_Timeout", "Timeout - testcase
not ended in proper time");
setverdict(fail);
mtc.stop;
}
}

Fort the altstep above the MostFBMsg is a template that defines any
message that can be traced by our test system for the currently tested
module.

In the case the expected message is never coming what we observed is
that if we have a high load of messages on the bus used by our test
system for communication TGuard.TimeOut is not treated at all because
lots of "any" messages arrive and trigger the repeat. TGuard.timeout is
never reached.

Is this the normal behavior of TTCN-3?

How is the timeout handled? Is it normal to still catch messages that
appeared after the timeout event of a timer? Doesn't the order of events
in time count for treating sequentially the messages and timeout events?

Thanks in advance,

Maria

..........................................................
Mit den besten Gruessen / Best regards
Maria Teodorescu
Project Manager
I MM IAS SW TA


Siemens VDO Automotive SRL
Bld. Poitiers no. 10
700671 Iasi, Romania

A Continental Corporation company

Tel.: +40 232 30 -7318
Fax: +40 232 22 -0335
E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
www.continental-corporation.com
Proprietary and confidential. Distribution only by express authority of
Continental AG or its subsidiaries.



--

---

Valentin Zaharescu
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 17 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS

May 26-28, Tutorial "Theory & Practice of TTCN-3", Berlin (Germany)
www.testingtech.com/services/ttcn3_tutorial.php

June 3-6, TTCN-3 User Conference (T3UC), Madrid (Spain), Booth #T1
www.mtp.es/TTCN3UC2008/home.html

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805 B, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.