Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Papyrus for Real Time » Understanding of the timer implementation(Timing Protocol)
Understanding of the timer implementation [message #1834954] Sun, 22 November 2020 05:16 Go to next message
Sneha Sahu is currently offline Sneha SahuFriend
Messages: 20
Registered: June 2018
Junior Member
index.php/fa/39383/0/

in the attached figure, -
1. timer resets to 10 as entry action for A.
2. before timeout, triggerA is active and due to t1, now state becomes B.
3. as an entry action of B, timer is again reset to 5.
4. now at B, t3 gets active before timeout and state goes to A.

Now, my question is, what happens to these unprocessed timer signals? since both A and B are using the same timer port, does the new resets overwrite the previous ones, or do they get queued up on top of each other?
Kindly explain the behaviour of the default timing protocol implementation.
Re: Understanding of the timer implementation [message #1835047 is a reply to message #1834954] Mon, 23 November 2020 23:45 Go to previous messageGo to next message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 438
Registered: March 2011
Senior Member
Interesting question.

Well, the exact behaviour will depend on whether the two timers are set on the same Timer port or different ports. I assume you are setting them on the same port.

They key to understand this is that timeout messages are in fact just like ordinary messages, so they are treated (almost) the same way as normal messages.

This implies, for example, that if a timeout is triggered (the timeout message arrives) and you are in a state that does have a transition which handles the timeout (the transition's trigger is on the relevant timer port), then the transition will be taken, and if the state does *not* have a transition to handle that timeout, then the timeout is discarded, but a message will be printed on stdout. What happens exactly can be customized by overriding a method called "unexpectedMessage" (with signature void unexpectedMessage(void)" in the capsule.

Now, I said that the timeout messages are "almost" like ordinary messages, but there is a key difference. A UML-RT model runs in one or more "controllers". Each controller runs in its own OS-thread, and manages one or more capsules. By default, all capsules are allocated to one default controller, but you can allocate them to different controllers, although that's another question.

Now, each controller keeps separate queues for "normal" messages and "timeout" messages. The timer queue is sorted by time (the timers with sooner deadline first). Note that this is unlike other languages and models of computation, such as the Actor model, which keeps one queue per "Actor", or other languages which keep one queue per port. .

The controller has a "main" loop where it processes all messages. At the beginning of each iteration of this loop, it goes through all "expired" timers from the timer queue and adds them to the "incoming queue" (the queue for normal messages). Then, it processes all messages on the incoming queue until there are no more. If there are no more such messages, it will wait (block) until either a new normal message arrives or the first timer in the timer queue is triggered. When this happens, the next iteration of the main loop begins (moving timers to the incoming queue, etc. ...)

So in your example, the timers don't disappear when you jump to a different state (because timers are in fact managed by the controller, not the capsule and certainly not the state). In other words, the timers will trigger regardless of what state they were set up on, and when they trigger, the behaviour will depend on whether the current state has a transition that can handle them or not.
Re: Understanding of the timer implementation [message #1835049 is a reply to message #1834954] Tue, 24 November 2020 00:34 Go to previous messageGo to next message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 438
Registered: March 2011
Senior Member
And aI forgot to add that there is no problem in having two or more timers on the same port with different times. Each gets queued and each gets triggered when the timer goes off.
Re: Understanding of the timer implementation [message #1835050 is a reply to message #1834954] Tue, 24 November 2020 00:49 Go to previous messageGo to next message
Sneha Sahu is currently offline Sneha SahuFriend
Messages: 20
Registered: June 2018
Junior Member
Thank you so much for the explanation.
Also, is this implementation of local timers and controllers specific to Papyrus-RT, or is this how UML-RT models are supposed to work in general?
Re: Understanding of the timer implementation [message #1835052 is a reply to message #1835050] Tue, 24 November 2020 01:16 Go to previous messageGo to next message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 438
Registered: March 2011
Senior Member
While the details of having a separate timer queue is specific to Papyrus-RT, the rest is true for UML-RT in general. The idea of "controllers" is described in the ROOM book (see Real-Time Object Oriented Modelling) which is the one that defined the UML-RT language (before it was called UML-RT). This also includes the idea that timeouts are normal messages, that timeouts will occur independently of the state were they were set up and that it's controllers who have queues rather than capsules or ports.
Re: Understanding of the timer implementation [message #1835057 is a reply to message #1835052] Tue, 24 November 2020 01:59 Go to previous message
Sneha Sahu is currently offline Sneha SahuFriend
Messages: 20
Registered: June 2018
Junior Member
Thank you again for all the explanation and information.
Previous Topic:Multiplicity of a part with a relay port
Next Topic:Unexpected message to capsule Instance Top
Goto Forum:
  


Current Time: Sun Apr 14 02:09:48 GMT 2024

Powered by FUDForum. Page generated in 0.05035 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top