Eclipse Community Forums: Papyrus for Real Time » Using timeout in action code and querying current state in another state machine

Home » Eclipse Projects » Papyrus for Real Time » Using timeout in action code and querying current state in another state machine

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

Using timeout in action code and querying current state in another state machine [message #1769292]

Fri, 28 July 2017 17:00

reza ahmadi

Messages: 47
Registered: September 2016

Member

Hi,

A couple of quick questions..

1. I wonder what would be the best way to use timeout event in action code (rather than as a trigger on transitions), e.g., in an state entry we have:

//setting the timer
timer1.informIn(UMLRTTimespec(1,0));

//Now I want to wait til timer1 timeouts
while(!timer1.timeout()) {} //something like this?

I have another question as well.
2. I wonder if it is possible to query current state in other state-machines. Assume we have two capsule parts connected to each other and one of the parts wants to know in what state the other capsule part currently is? Do we have utilities for these kind of things?

Thanks!

[Updated on: Fri, 28 July 2017 21:52]

Report message to a moderator

Re: Using timeout in action code and getting to know current state in another state machine [message #1769294 is a reply to message #1769292]

Fri, 28 July 2017 17:24

Ernesto Posse

Messages: 438
Registered: March 2011

Senior Member

The short answer to both of your questions is that there is no (simple) way of doing either.

I think you both of your questions suggest a design problem. Your design seems to be contrary to the UML-RT design philosophy or its semantics.

First timeouts: the idea of a timeout is to move a capsule from one state to another. Action code occurs in either a transition or in the entry or exit action of a state. The semantics of UML-RT state machines is a *run-to-completion* semantics. This is, whenever a message arrives, the state machine is an a (stable) state, an enabled transition is selected, and the transition chain is fully followed until it reaches another (stable) state. This entails the execution of exit actions, transition actions and entry actions according to the path of the transition chain. If you where able to stop in an action, for a timeout (or any other reason, like an infinite loop), you would not reach a stable state, and as such you would be blocking the capsule's controller and thus, blocking all capsule instances in the same controller. Hence, actions are intended to be *simple*. They should not do any kind of thing that could be blocking. In particular they should not wait for timeouts from a timing port, and they should not expect messages on ports and they should not engage in non-terminating loops or loops that expect any kind of external input. For this reason, the model library, such as the Timing protocol, do not offer operations to wait for timeouts.

The second issue (querying another capsule's state) is not allowed for a different reason, but it's also the semantics of UML-RT and quite intentional. The state of a capsule is internal. Querying another capsule's state would allow you to observe the internals of another capsule. The whole point of a capsule is to *encapsulate* its state (hence the name "capsule"). The only way in which capsules can interact is by exchanging messages through their ports. The interface of a capsule is its set of ports, and it defines the only points of contact between the capsule and its environment. And this is for a good reason. The theory and practice of concurrent programming has shown that direct access to someone else's internal state leads to a million problems. This is why UML-RT was designed this way.

If you really need to know the state of another capsule, that capsule should allow it (someone will tell you something private only if they want to let you know it). A simple way of doing this is to put all your states in a composite state and have an internal transition in this state that responds to a query message. (A transition from the composite state to itself with kind == Internal). An internal transition like this would be enabled in all states inside the composite state.

You might want to define the query message in a separate protocol which also defined the response. The response message should have a parameter, possibly a String, to encode the state. Then, in the action of that internal transition you can reply with the current state string. For example, something like:

stateQueryPort.currentStateResponseMessage(getCurrentStateString()).send();

where your capsule has a port called "stateQueryPort" typed by a protocol that has a message "currentStateResponseMessage(getCurrentStateString())" and a message "stateQuery" which is used as the trigger for that transition.

[Updated on: Fri, 28 July 2017 17:35]

Report message to a moderator