Problem with raised events between different regions

[lidy]

Hello,

I am new at using Yakindu, and I would like to ask for the solution of following:

I want to model statechart with four different parallel parts, so I used four regions for that. When I raise an event in for example first region, the rest of them can react, so they detect that event and do the transition, but the problem is that when I raise an event from the let say second region, then the first one does not react on it, which is a big problem. I have the impression that "parallel" does not mean really parallel, instead there is an order.

I am sorry if my question is banal, I am quite sure that the problem is my inexperience. Finally, my question is how to solve this problem, how to make regions to react on events raised in different regions no matter what is their order? Or, if it is not possible, then how to model parallelism at all?

One more thing: I discovered that the same is true for composite state with more then one region. Are this orthogonal states meant to be parallel at all, or not? It is a little confusing to me, that I can make transitions between states in different regions, because the theory about statecharts I learned claimed that parallel states can communicate only by raising events, not directly. Can anyone clarify this to me, please. Thanks in advance,

Best regards

[Axel Terfloth]

Hello,

your observation is right. Perhaps i should tell a little bit about the current execution semantics.

1. Orthogonal regions allow modeling independent spaces of state. Orthogonality is not interpreted in the sense of 'multithreading'. Since many people confuse parallelism with multithreading we use the term of orthogonality.

2. In this sense an execution order must be defined to make the statechart behavior deterministic. For example is you have states in two orthogonal regions that defines a reaction e / a+=1 in one region and e / a *=2 in the second the execution order is relevant. You can define this order in the property sheet for the statechart of by graphically ordering the regions within a state.

3. Events are just visible within a single run-to-completion-step. So it is possible to react on outgoing and local events only in lower order regions.

4. We apply single step execution semantics. This means a run-to-completion-step just performs a transition from one state configuration to the next.

5. An cycle bases approach is implemented what means that it is possible to react to multiple events with in a run-to-completion-step in contrast to a pure event driven approach where one event is processed after another.

This together leads to your observation. We consider this to be a kind of baseline execution semantics that targets towards a minimum resources consumption (memory and processor cycles).

Your questions are not new and of course there are variants of execution semantics that are relevant in different scenarios. We plan to add further features step by step. On of those features are "delayed events" that become visible in the next cycle and thus can be consumed within any region.

So far you can alternatively use variables to 'communicate' between regions. Additionally there is the active() function, that lets you test for active states.

Best regards,
Axel








Orthogonality Regions are ordered. This

> --
>
>

[lidy]

Thank you very much. Then, for now, I will change my direction of thinking about this, and will use the ideas of variables and  active() function to simulate parallel behaviour. Everything is much more clearer now. I am very grateful for your answer.

Best regards

[Julien Deantoni]

Hello,

2. In this sense an execution order must be defined to make the statechart behavior deterministic. For example is you have states in two orthogonal regions that defines a reaction e / a+=1 in one region and e / a *=2 in the second the execution order is relevant. You can define this order in the property sheet for the statechart of by graphically ordering the regions within a state.

this make the semantics of state machines in Yakindu dependent of the serialization order !! :-/

(This is quite different from what is defined in StateCharts semantics or SCXML for instance).

Is it still the case in the last version of Yakindu ?

j

[andreas]

Hi,

we support different domains with different execution semantics. 

We have an SCXML domain that behaves like the SCXML specification. You can read more about this here:

https://blogs.itemis.com/en/taking-scxml-to-the-next-level-with-yakindu-statechart-tools

For the YAKINDU Default domain, this is still the defined execution semantics.

Best,

Andreas

--
You received this message because you are subscribed to the Google Groups "YAKINDU User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to yakindu-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Mit freundlichen Grüßen,

            Andreas Mülder

[Julien DeAntoni]

Hi,

thanks a lot for the pointer. Unfortunately Java integration is in this case costly :-/

thanks again

j

[Julien Deantoni]

BTW,

For the YAKINDU Default domain, this is still the defined execution semantics.

it means a simple ping pong state chart like the following is not supported by Yakindu :-/

[Axel Terfloth]

Hi Julien,

the semantics described above are still valid for the cycle based execution model. For the case of event driven execution things are different. The ping pong statechart will work if you 

1. Declare the statechart to be event driven by specifying @EventDriven in the statechart declaration section.

2. Declare ping and pong events to be internal events by defining them in the internal scope of the statechart

The event declaration should look like:

internal:

    event ping

    event pong

YAKINDU SCT distinguished between three kind of events: in , out, and internal (or local). While input events and output events become visible in the statecharts interface internal events are not. So they are used for event processing within the statechart. to be compliant with event driven execution these events are handled using an internal event queue. So when the statechart is triggered by an input event (time event in your case) then this input event is processed. If a local event is raised it will be put on the event queue. After the input event is processed the events from the internal event queue will be processed until this event queue is empty.

Currently there is an important constraint regarding in and out events - when raised they are not queued on the internal event queue. This constraint is due to legacy and backwards compatibility reasons and we can't break the semantics of existing models. Without this constraints we could enforce (or at least  warn) that no input event is raised and no output event is consumed or preferable queue all events that are raised and consumed.

So this is a topic for the next major release. This release will likely introduce changes that break backwards compatibility . The major feature that we will introduce is multi-statechart modeling. This will have impact on the interfaces of statecharts and this context we will also have the chance to change some semantic defaults.      

Best regards,

Axel