Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Papyrus for Real Time » Unexpected message to capsule Instance Top(Unexpected message to capsule Instance Top)
Unexpected message to capsule Instance Top [message #1836602] Fri, 08 January 2021 18:56 Go to next message
Subash Kopisetty is currently offline Subash KopisettyFriend
Messages: 1
Registered: January 2021
Junior Member

I am trying to design model where a control unit handles all the other units.
It sends messages so that respective units do some actions to it. If suppose I am sending some message from control unit all the other units are receiving the message but only specific unit should perform the action. But in the output of the code I can see Unexpected message to capsule instance to other capsules along with my intended capsule action.

Is it possible to remove the the unexpected messages to other capsules and only one capsule can receive and handle it.

please give me some suggestions
Re: Unexpected message to capsule Instance Top [message #1837526 is a reply to message #1836602] Mon, 01 February 2021 19:21 Go to previous message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 416
Registered: March 2011
Senior Member
It's not exactly clear what your model actually looks like (you could've attached a screenshot from the tool, or the model itself). It's also unclear whether all "units" are the same type of capsule. And since you don't show the state machine(s) of your capsules, it's unclear what the behaviour is going to be.

Assuming that your "Central control" has exactly one port connected to the "units", when you do a "port.message(data).send()" you are sending the message to *all* capsule instances connected, so if the receiving instances are in a state that is not expecting the message, then you will get that "Unexpected message" in stdout. So the behaviour you are seeing is because of the design of the state machine(s) in your units, and which state each of them is when the "control" sends the message to all.

It sounds like you have a design problem. I assume that all "units" are the same type of capsule. If you send a message to another capsule, by definition (by the semantics of UML-RT) the other capsule is going to react to it somehow, either by taking a transition or showing an "Unexpected message". Therefore, if you send a message to all "unit" capsules, all of them will either take a transition or give you an "Unexpected message". Hence, if you don't want some capsule to do anything, then the "sender" should not send it a message! Now, if all "unit" capsules are connected to the "control" on the same port, the "port.message(data).send()" will send message to all of them. But if you want to send a message to only one of the units, there is an alternative: you set the port's "replication" to some natural number n > 1 (in your case n = 4) so the port becomes an array of n (=4) ports, and in your action code you use the "sendAt" operation: "port.message(data).sendAt(index)" where "index" is the port's index starting from 0. So the logic of the "control" should be the one to decide which "unit" should receive the message.

Alternatively, if you insist on broadcasting the message with "send" instead of "sendAt", you could redesign the state machine(s) of your unit(s) so that they ignore the message from "control" once they are in another state. It is possible for the different "units" to coordinate, once one of them have received the message, but this would involve all of them being able to communicate with one another, perhaps through a shared capsule (maybe the "control" capsule itself), and implement a logic that would be something like this: "I received a message, then I ask the 'control' if no-one else has received the message, and if the 'control' confirms this, I take the message and tell control that I took it". But, while this coordination protocol is a very interesting thing to do *correctly*, it is a tricky one to do *correctly* and likely to end up having race-conditions (for example, two capsules may end up "taking" the message), so, unless you are familiar with this sort of coordination protocols, I would avoid it, and stick to the first option: letting the "control" capsule decide who gets the message and use "sendAt".

[Updated on: Mon, 01 February 2021 19:25]

Report message to a moderator

Previous Topic:Understanding of the timer implementation
Next Topic:CanĀ“t create a diagram for a package
Goto Forum:

Current Time: Thu Dec 01 14:33:31 GMT 2022

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

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

Back to the top