Eclipse Community Forums: Papyrus for Real Time » Ignoring Unexpected Messages

Help

Home

Home » Eclipse Projects » Papyrus for Real Time » Ignoring Unexpected Messages

Show: Today's Messages :: Show Polls :: Message Navigator

Ignoring Unexpected Messages [message #1754037]

Tue, 14 February 2017 05:21

Ashiqur Rahman

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?

Report message to a moderator

Re: Ignoring Unexpected Messages [message #1754088 is a reply to message #1754037]

Tue, 14 February 2017 13:09

Charles Rivet

Messages: 219
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

Report message to a moderator

Re: Ignoring Unexpected Messages [message #1754095 is a reply to message #1754088]

Tue, 14 February 2017 13:41

Peter Cigehn

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

Report message to a moderator

Re: Ignoring Unexpected Messages [message #1754246 is a reply to message #1754095]

Wed, 15 February 2017 17:20

Ashiqur Rahman

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

Report message to a moderator

Re: Ignoring Unexpected Messages [message #1754306 is a reply to message #1754246]

Thu, 16 February 2017 09:49

Peter Cigehn

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

Attachment: DeferStateMachine.PNG
(Size: 15.69KB, Downloaded 790 times)

Report message to a moderator

Re: Ignoring Unexpected Messages [message #1754357 is a reply to message #1754306]

Thu, 16 February 2017 17:35

Ashiqur Rahman

Messages: 9
Registered: January 2017

Junior Member

Hi Peter,

Thank you very much.

I really appreciate your effort.

Sincerely,
Ashiqur

Report message to a moderator

Re: Ignoring Unexpected Messages [message #1754369 is a reply to message #1754246]

Thu, 16 February 2017 21:49

Ernesto Posse

Messages: 438
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.

Report message to a moderator