Confusion about rationale behind orthogonal implementation

[thettasch]

Good day,

I've recently been experimenting with using a SMACC state machine to implement more complex robotic behaviours. It appears to me that the definition of an "Orthogonal" differs between the current SMACC2 implementation and the original paper on Statecharts by David Harel.

I was wondering about the reasoning for this difference. My current understanding of orthogonals is as follows:

Orthogonals in Statecharts as defined by David Harel

Orthogonals are essentially superstates which run in parallel and can contain multiple substates with their own transitions. The intention being to prevent combinatorial state explosion by allowing for concurrent "sub-statemachines".

David Harel (1987). Statecharts: a visual formalism for complex systems. Science of Computer Programming, 8(3), 231-274., https://doi.org/10.1016/0167-6423(87)90035-9

Orthogonals in SMACC2

Orthogonals contain one (or multiple) clients which interact with the outside world and some number of client behaviours. While this allows for concurrently running client behaviours, it does not appear to be possible to add substates into orthogonals.

https://smacc.dev/orthogonals/

I was wondering whether you could perhaps briefly explain the rationale behind the implementation of orthogonals in SMACC and how one would go about implementing a statechart such as the one shown in Figure 19 in SMACC.

┆Issue is synchronized with this Jira Task by Unito

[ghost]

From my understanding of smacc, orthogonals are analogous to callback groups in ros2. I believe it is simmilar to state charts orthogonal in the sense that they are concurrently processing code instructions along with the state machine.

To expand, the way I think orthogonals should be used is, lets say for a particular process which hosts a certain statemachine, you want intra process communication with other process for the state machine to do its work and as well to provide an external interface to allow events coming in to the statemachine outside of process boundary. Now these set of intraprcoess comunication peripherals may have a requirement to be processed concurrently, example reciveing new events while always keeping a check on health of some other depndeency processes...so you would want to seperate these two end points into two orthogonals beacause they can run in parallel and it makes sense because they are logically decoupled and mostly they do not have any shared resources.