SDL Mailing List Archive: RE: SDL-News: What does this mean?

Subject: RE: SDL-News: What does this mean?
From: VINCENT Daniel FTRD/DTL/LAN (daniel.vincent#rd.francetelecom.com)
Date: Fri Mar 08 2002 - 17:42:42 GMT

In addition to what Laurent Doldi has already answered to this :

First, it seems that this text is an abstract of a research paper, and in
this case it would be good
to see this text in its context, if you give the reference (even if I think
that I have an idea of the paper,
or at least of the authors).

Second, it is always surprising when somebody writes that "time does not
progress". I guess that this
has been written in the context of simulation and/or exhaustive
verification, since it has no sense for
implementation.
What it means here is that verification or simulation tools have to decide
what to do next (for not timed SDL, which next
transition to fire, xor let the time progress). Why ?

                                 + dt
                         (S1) ------------> (S1')
                          | |\
                firing tr1| firing tr1?| \
                          | +dt ? ??
                         (S2) ------------>(S2')
                          |
                firing tr2|
                          |

in this diagram, we see that if in Stare S1 we have the choice t to fire
transition 1 or let the time progress (+ dt),
depending on the order in which we execute both actions we may or not reach
the same state :
    S1 ---tr1----> (S2) ---- dt ----> (S2')
but S1 ----dt----> (S1') ---? in state S1', it is no more sure that tr1 is
still fireable if there are some time dependent
enabling conditions.

Thus the way in which the tools (or the user in interactive mode) choose the
next action or time progress is important for the result.

The default behaviour for this choice can be different in each tool, but
common ones are :

- we give preference to fireable transitions as long as there is one
fireable (in the example : tr1, then tr2, then tr3 ...)
   until you reach a state where no more "normal" transition is fireable.
   Then the simulator is allowed, or to let the time progress, or to take an
external event (if any).
   With untimed models (0 time transitions and 0 delaying channels), the
only way to say then that time
   may progress is if a timer has been set. If no timer is set, time does
no more progress.
   Another drawback of this behaviour is that in some models, there is
always something to fire, and if transitions are
   supposed to take 0 time, time never is allowed to progress which leads to
unrealistic models.

- as said by Laurent Doldi, you can allow time progress or transition firing
to be choosen non deterministically at any point.
  But this has also drawbacks : the state space may become very large, and
the worst is that you will have
  even more unrealistic behaviours, even if the good ones are now probably
there.
  It is here also important to be able to have a clear time progress.

The second puzzling sentence only says that, to deal with some urgent
situations, we need different
mechanisms, even when modelling, as those permitted today with timer signals
handled in the input queue.

Daniel Vincent
& france telecom
BD/FT R&D/DTL/MSV

Technopole Anticipa Tel: +33 2 96 05 39 54
2, Avenue Pierre Marzin Fax: +33 2 96 05 39 45
F 22 307 LANNION CEDEX mailto:daniel.vincent#francetelecom.com
<mailto:daniel.vincent#francetelecom.com>

-----Message d'origine-----
De : Zhang Yongqian [mailto:zhangyq#mail.ustc.edu.cn]
Envoyé : vendredi 8 mars 2002 04:17
: sdlnews#sdl-forum.org
Objet : SDL-news: What does this mean?

Hello, all,

     I am reading a paper about the timing limit of SDL. There is a section
as below. I am not sure
the meaning of it. Would you like to give me a hand? (The paragraph marked
with "~~~" puzzle me )

    " A typical assumption on the progress of time in SDL, as has been
adopted by most tool vendors [13,14] is to assume that time only progresses
when the system is in a stable inactive state, i.e. where no signals can be
sent or consumed. With regard to real-time systems development, this is of
limited use since with this approach when no timers are currently set then
time, in effect, does not
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~
progress. Further, since timer expiry results in an input signal being
placed in the (possibly non-
~~~~~~~~~
empty) input queue of the associated agent, these signals can be in the
queue any arbitrary time

before they are consumed. If the expired timer was to stop delivering
plutonium, then such a delayed

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
treatment is unlikely to be satisfactory. "
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


                      BR,
                      Zhang Yongqian
                      University of Science&Technology of China
                      E-mail: zhangyq#mail.ustc.edu.cn <mailto:zhangyq#mail.
ustc.edu.cn>

In addition to what Laurent Doldi has already answered to this :

First, it seems that this text is an abstract of a research paper, and in this case it would be good

to see this text in its context, if you give the reference (even if I think that I have an idea of the paper,

or at least of the authors).

Second, it is always surprising when somebody writes that "time does not progress". I guess that this

has been written in the context of simulation and/or exhaustive verification, since it has no sense for

implementation.

What it means here is that verification or simulation tools have to decide what to do next (for not timed SDL, which next

transition to fire, xor let the time progress). Why ?

+ dt

(S1) ------------> (S1')

| |\

firing tr1| firing tr1?| \

| +dt ? ??

(S2) ------------>(S2')

firing tr2|

in this diagram, we see that if in Stare S1 we have the choice t to fire transition 1 or let the time progress (+ dt),

depending on the order in which we execute both actions we may or not reach the same state :

S1 ---tr1----> (S2) ---- dt ----> (S2')

but S1 ----dt----> (S1') ---? in state S1', it is no more sure that tr1 is still fireable if there are some time dependent

enabling conditions.

Thus the way in which the tools (or the user in interactive mode) choose the next action or time progress is important for the result.

The default behaviour for this choice can be different in each tool, but common ones are :

- we give preference to fireable transitions as long as there is one fireable (in the example : tr1, then tr2, then tr3 ...)

until you reach a state where no more "normal" transition is fireable.

Then the simulator is allowed, or to let the time progress, or to take an external event (if any).

With untimed models (0 time transitions and 0 delaying channels), the only way to say then that time

may progress is if a timer has been set. If no timer is set, time does no more progress.

Another drawback of this behaviour is that in some models, there is always something to fire, and if transitions are

supposed to take 0 time, time never is allowed to progress which leads to unrealistic models.

- as said by Laurent Doldi, you can allow time progress or transition firing to be choosen non deterministically at any point.

But this has also drawbacks : the state space may become very large, and the worst is that you will have

even more unrealistic behaviours, even if the good ones are now probably there.

It is here also important to be able to have a clear time progress.

The second puzzling sentence only says that, to deal with some urgent situations, we need different

mechanisms, even when modelling, as those permitted today with timer signals handled in the input queue.

Daniel Vincent
& france telecom
BD/FT R&D/DTL/MSV

Technopole Anticipa Tel: +33 2 96 05 39 54
2, Avenue Pierre Marzin Fax: +33 2 96 05 39 45
F 22 307 LANNION CEDEX mailto:daniel.vincent#francetelecom.com

-----Message d'origine-----
De : Zhang Yongqian [mailto:zhangyq#mail.ustc.edu.cn]
Envoyé : vendredi 8 mars 2002 04:17
À : sdlnews#sdl-forum.org
Objet : SDL-News: What does this mean?

Hello, all,

     I am reading a paper about the timing limit of SDL. There is a section as below. I am not sure

the meaning of it. Would you like to give me a hand? (The paragraph marked with "~~~" puzzle me )

    " A typical assumption on the progress of time in SDL, as has been adopted by most tool vendors [13,14] is to assume that time only progresses when the system is in a stable inactive state, i.e. where no signals can be sent or consumed. With regard to real-time systems development, this is of limited use since with this approach when no timers are currently set then time, in effect, does not

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

progress. Further, since timer expiry results in an input signal being placed in the (possibly non-

~~~~~~~~~

empty) input queue of the associated agent, these signals can be in the queue any arbitrary time

before they are consumed. If the expired timer was to stop delivering plutonium, then such a delayed

                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

treatment is unlikely to be satisfactory. "

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


                      BR,
                      Zhang Yongqian
                      University of Science&Technology of China
                      E-mail: zhangyq#mail.ustc.edu.cn