Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Papyrus for Real Time » Ignoring Unexpected Messages
Ignoring Unexpected Messages [message #1754037] Tue, 14 February 2017 05:21 Go to next message
Ashiqur Rahman is currently offline Ashiqur RahmanFriend
Messages: 9
Registered: January 2017
Junior Member
Hi,
When a capsule receives a message but the statemachine is not in a state to utilize that particular message it shows "Unexpected message to capsule instance....". How can I handle such situations so those messages will not appear in the output?
Re: Ignoring Unexpected Messages [message #1754088 is a reply to message #1754037] Tue, 14 February 2017 13:09 Go to previous messageGo to next message
Charles Rivet is currently offline Charles RivetFriend
Messages: 211
Registered: May 2014
Location: Canada
Senior Member

The algorithm to handle transitions will alway start at the current state and then move up the state containment.

As such, the easiest way to handle these unexpected messages is to create an internal transition to history in the container state. that internal transition's trigger can be set to "*" to catch all messages and then process these messages according to your particular needs or even suppress the error message entirely by doing nothing.


/Charles Rivet
Re: Ignoring Unexpected Messages [message #1754095 is a reply to message #1754088] Tue, 14 February 2017 13:41 Go to previous messageGo to next message
Peter Cigehn is currently offline Peter CigehnFriend
Messages: 49
Registered: September 2014
Member
Hi,

You should probably also look into the use of defer/recall, i.e. if you are in a state where you cannot handle a set of protocol messages, then receive them using a group transition with return to history as Charles proposes, and then defer the received protocol message and put it n the defer queue. When you then are able to handle the protocol messages, then you simply recall (one or all) protocol message and the state-machine can continue processing them at a later point in time. It of course depends on what your state-machine are supposed to do, but simply ignoring protocol messages is not a proper solution for certain problem domains.

/Peter Cigéhn
Re: Ignoring Unexpected Messages [message #1754246 is a reply to message #1754095] Wed, 15 February 2017 17:20 Go to previous messageGo to next message
Ashiqur Rahman is currently offline Ashiqur RahmanFriend
Messages: 9
Registered: January 2017
Junior Member
Hi Charles and Peter,
Thank you very much for your reply.

Is there any document that explains how to use the History in Papyrus? How can I defer/recall the protocol messages and move to the next state based on a particular message? I tried but could not use that properly.

Sincerely,
Ashiqur
Re: Ignoring Unexpected Messages [message #1754306 is a reply to message #1754246] Thu, 16 February 2017 09:49 Go to previous messageGo to next message
Peter Cigehn is currently offline Peter CigehnFriend
Messages: 49
Registered: September 2014
Member
Hi,

Charles maybe can provide information regarding documentation.

But I made a small example model to show how how defer/recall can be used:

index.php/fa/28486/0/

In this state-machine you are not able to handle 'anotherRequest' when you are in state 'Processing' until you have received 'finalRequest'. So the effect code on the self transition when receiving 'anotherRequest' you do like this

msg->defer();


to put the received protocol message into the defer queue.

Then when you received 'finalRequest' you can recall the deferred 'anotherRequest' protocol message using:

port.anotherRequest().recall();


There are a few more ways of recalling also depending on if you only want to recall one or all deferred protocol messages, and whether you want to recall on a specific port instance in case you have a replicated port. See Ernesto's response regarding documentation of the RTS header files here. You find more information about this in the umlrtinsignal.hh.

Unfortunately I discovered a bug in the code-generator when creating this example model. See bug 512272 for more information, and also the attached example model.

Hope this helps.

/Peter Cigéhn
Re: Ignoring Unexpected Messages [message #1754357 is a reply to message #1754306] Thu, 16 February 2017 17:35 Go to previous messageGo to next message
Ashiqur Rahman is currently offline Ashiqur RahmanFriend
Messages: 9
Registered: January 2017
Junior Member
Hi Peter,

Thank you very much.

I really appreciate your effort.

Sincerely,
Ashiqur
Re: Ignoring Unexpected Messages [message #1754369 is a reply to message #1754246] Thu, 16 February 2017 21:49 Go to previous messageGo to next message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 361
Registered: March 2011
Senior Member
I assume that your question is about Papyrus-RT, not Papyrus per-se. Base Papyrus implements UML. Papyrus-RT implements UML-RT. UML and UML-RT have a slightly different semantics for history.

The official story is available in the OMG UML 2.5 spec at http://www.omg.org/spec/UML/2.5/.

You'll find the description of history in page 323.

The short version is this: when a transition ends in the history pseudo-state of a composite state CS1, then the last active substate SS1 of CS1 is entered. This is the case regardless of whether the transition comes from the inside or the outside of CS1. There are two kinds of history: shallow and deep. With shallow history, the entered substate SS1 follows its initial transition. With deep history, it goes to SS1's history point (if it has one), and therefore it recursively enters all the last active substates.

History is useful to remember where you where when you were doing something in a composite state and go back there. The typical use is when you exit a composite state via a group transition, and then enter again.

This of course is the UML semantics. For UML-RT, the idea is that only deep history is supported, and that a transition that ends in a composite state is deemed to be as if it ended in the composite state's history pseudo-state.

So the solution that Charles was suggesting was to put the states that you are interested in into a composite state (say CS1) with an internal transition whose source and target are both CS1, and with a trigger set to "any event" (i.e. '*'). Because the source is the composite state, it is as if the transition's source is any of its contained states. Because its target is CS1 itself, it is as if it went to deep history, so when triggered, it will return to whichever state it was last in. And because the event triggers are considered "inside-out" (i.e. from the innermost states to the outermost), then this transition will have the lowest priority and will not override other transitions inside this CS1.

Re: Ignoring Unexpected Messages [message #1754373 is a reply to message #1754369] Fri, 17 February 2017 04:31 Go to previous messageGo to next message
Ashiqur Rahman is currently offline Ashiqur RahmanFriend
Messages: 9
Registered: January 2017
Junior Member
Hi Ernesto!

Thank you very much. You are so helpful.

-Ashiqur
icon14.gif  Re: Ignoring Unexpected Messages [message #1754922 is a reply to message #1754037] Fri, 24 February 2017 04:47 Go to previous message
Kireet Bhat is currently offline Kireet BhatFriend
Messages: 1
Registered: February 2017
Junior Member
Really helpful.
Thank you everyone.
Previous Topic:Building Workspace has encountered a Problem
Next Topic:How to access port index of an incoming message
Goto Forum:
  


Current Time: Mon Nov 19 04:43:02 GMT 2018

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

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

Back to the top