How to create a situation in Capella relative to modes and states

Hello everyone,

I watched a webinar on YouTube about modes and states, and they talked about configurations and situations (the link below). But they don’t explain how to use a situation in capella. They skipped the step where they define modes and states in a situation.

If you know how to do it, or you have a video or a document with more detailed information about situations, please share it with me.

Modeling states and modes with Arcadia and Capella: method and tool perspectives | Webinar Capella - YouTube

Thank you in advance,

Best regards,

Hajar CHBIKI.

1 Like

Hi
There you have to think about the metamodel you want to run… even if most of the job is already built in.
Let’s have a look at the time split during system life, at least my understanding of it:
First you have life cycle: from unit design and buit until disposal. until Physical Analysis, the only part you care about is Duty: when your system is used. This duty phase may be split in different subphases and when these subphase is short, or even sometime for all, you may call them situation. The period is set by the combination of actors states and reflect the state of the context in which the system is. I use to represent it with a state.
Then you develop the system and you have to design modes for your system that activates functions to support capabilities required during each life phase. Capabilities contribute to mission as well required during life phase.
In OA, no entity is called system yet: so each of the OE may run a state machine reprsenting its intern states.
In SA, we start to build the duty phase by combining OE transfered as actor to desicribe context state, and support phases with system modes (I represent them with modes)
Then in LA, we detect logical reasons to divide the system, including partial activity during phases or modes.
In PA we implement behavior roles in node components, so comes with each selected node its life phase, including process phases, and for our system, we have to think about its process time: build; repair; clean; refuel; and for unique unit or for sample units in serial production engineering and testing (unique unit have these phases before build or during build, serial have them for other units: the samples)
Regards
Thierry

I actually have the same question.
Once I create a state machine, I don’t know any way to use it except for dragging state fragments onto the lifelines of the elements in a Scenario Diagram.

The Arcadia book says promising stuff, like:
" The content of each mode is then specified by one or more unitary configurations
describing the expected functional and non-functional content (in first place,
required capabilities and functions, functional chains or scenarios it should be
possible to play out in this mode, performances and other associated properties, etc.)
or indeed expected structural aspects (components, interfaces, exchanges, physical
links, etc.), when in operational use of the system, in nominal conditions. "

But how can we actually do this in Capella?
I know how to set triggers, set functions as available only in certain states/modes, assign effects to a state transition. But after I do all of this, I don’t know how to “make it all come together”.

Thank you so much to whoever can give me a hint!

If you mean the possibility to actually execute the statechart (and the associated triggers, guards, effects), Capella does not support such feature (yet?).
I’m developing a plugin to do so using an external statechart simulator. The idea is to get semantic elements from the statechart (e.g. functional exchanges inside entry/do/exit fields) and “execute” them (visually for now, but with parametric simulation later on).

IIRC, there are 2 main commercial simulation plugins for statecharts: one from PGM and the other from Glaway. There are webinars showcasing their operation.

Edit: there is also xCapella

1 Like

Hello all,
This question is important to me and I would like to add some:
During operational analysis, we may define for each OE a state machine. Some of these OE will come to be system actors in system analysis, some other will be played by our system, one actor “realizing” several OEs to put distant entities out of the picture. We focus on our system, and we have to define the use cycle (part of the life cycle yet available, as others are pending on system design, and event its manufacturing design). There is very few and painful method to link system use phases and actor states despite each is a set of actor state combination. Each phase will put in force or not requirements, in particular require mission and then exploited capabilities availability. Once we have a use cycle, there is again few method to design the functional modes we want de define for our system, and then require system functions to be active when needed by capabilities required while the relevant use phase. Then we go to logical architecture, one of the reason of splitting our logical system is what is active and inactive while modes.
In addition we have to keep in mind modes and variants may exchange some items: we decide to run same system design with a configuration value, or we decide to offer a system variant to cover some modes which we would not for other variants. Again there is very few link between parent modes and child LC modes. We are there in breakdown way to the parent mode should define the child one. Method I found is setting one region for each child component, and put there a end state named after the appropriate child mode, then copy the machine to the child remove other regions than its own one, merge all with the same child name and then rename the former parent mode name to the child mode. The only link I found is set a trace with the wizard. But this process is incredibly long. As you have a choice to make, I see little chance to put all this in a p4c routine.
About setting modes and states in scenarios, my point is the same as property values, they are not conveyed in transformation nor transition to lower level. Even for scenarios that make the system change mode, I have stopped to mention it. The transition trigger mentions data relating to scenario message contents, that’s all. The main reason is that while tuning scenarios, I have to replace ES and IS all the time. All these decoration have to be redone each time, you can’t put several component states in same horizontal line or the labels are distord…
Thanks to thoses that read my long text until the end :wink:
Thierry Poupon

1 Like