Modes Within States, why NOT?

Good day.

I know that this topic has been explained and discussed many times on the forum and elsewhere in one way or another but, I still don’t quite get it in Capella. Allow me to explain:

Capella does not allow Modes to be created within States because of a philosophical difference in how Modes and States are defined and understood (probably because of an Arcadia rule, but I am not sure). Its seems from the many documentation, videos and discussions abouth this topic that States and Modes within Capella are somewhat interchangeable but not mixable, or as expressed in Pascal Roques’s book: Systems Architecture Modeling with the Arcadia Method:

Unfortunately, there is no normalized definition of these two concepts. We therefore have to choose whichever word is the most relevant for our context and will connect most with the readers of the model”, followed by “The two concepts cannot be mixed together in the same diagram”.

However, in my many years of MBSE training (including PPI), I have always had a clear understanding of the differences between States and Modes. In the simplest terms:

State: a Condition of BEING
Mode: a Condition of DOING (Function)

To me (and many other experienced SEs) Modes have always been subordinate to States, in that certain Modes (and their associated Functions) are, quite simply not accessible (or available) in certain States. For example: ‘Autonomous Mode’ is not accessible when the system is in a ‘Crashed State’ or ‘Unpowered State’. Conversely, ‘Autonomous Mode’ could (for example) only be accessible in the ‘Operational State’ and not in the ‘Standby State’. Moreover, the execution of one Mode (and its unique functions) within one State could transition the system to another Mode within a different State. The key here is the within part which seems to emerge, and I hope you are seeing. In the same way, functions are subordinate to Modes in that they are only available within certain Modes albeit not neccesarily exclusive to some modes, or in other words some functions can be found within (i.e. associated with) one Mode AND another (different) Mode. Because of this ‘hierarchical’, or ‘nested’ relationship, we can now further argue that some functions are indirectly available within certain States ONLY because of the associated Mode within that State, and not directly as expressed by Capella. Furthermore, although theoretically possible, one mode (and its functions) could be associated with multiple States, it is not considered good SE practice, and therefore mutual exclusivity between Modes within States should be attempted at all times, as opposed to the previously mentioned possible allowance of overlapping relationship between Modes and functions.

I know there has been much debate about which things should be considered as States and which as Modes (like the debate around ‘On’ and ‘Off’), but to me it does NOT influence this ‘hierarchical’ relationship between States and Modes at all, and clearly it should be necessary (and simple) for a good MBSE tool to be able to express this! I have performed many State/Mode analyses with diagrams and matrices in my life and they all involve the expression of available Modes within States, but I continue to struggle to find how to express this fact in Capella because get bogged down by the details of the tool operation whilst continuously running into the limitation due to the overarching philosophical differences.

I have tried creating Modes within States from the palette but (off course) without success. I have tried various approaches of creating separate State Mode Machines at various levels, some for Modes and others for States and attempted to find a matrix diagram at the sufficient level that would allow me access to express the interrelationship or associations between these States and Modes, but no success.

Am I simply missing a matrix that exists at some level that could allow me to do this?
Am I not creating the correct State/Mode machines at the right level?

Please help me to understand my misunderstanding.


Hello Estian
Did you checked the preference, there is somewhere there to authorize hierarchical alternance mode/state.
Still you are right, I would like as well improvement in modes and states management:
At SA layer, the system shall support requirements during use phases: life phases are states defined by the combination of states of the actors. The actor states induce the requirements force.
Requirement is made to system to support capabilities (or mission exploiting capabilities) during the use phase. For each capability, one or several scenario or process is attached, which involve functions. Then we design modes for the system that activate the necessary functions to support requirements in force during each use phase.
At LA layer, LC shall have modes defined from system mode activating necessary functions to required scenarios and processes.
At PA layer, PCB shall have modes defined from LC ones in the same manner. Then for each PCB mode or combination of modes of deployed PCBs, each PCN shall have states supporting the modes.
Some constraint capabilities may be added, and the system use cycle turns in life cycle as we may add now manufacturing, repair and retirement phases.
At the end if we do it in the model, we have a use/life cycle (state machine), a mode machine for each component (behavior) and a state machine for each node component, this for the three layers SA; LA, PA. And we have very few chance to connect links: My more advanced try was link requiring to supporting mode/state via manual traces. I have to say that the modeling operation is quite long…
I did the relation between parent and child component by giving a region for each child where I put a finish state named after the child state/mode. I use this to combine actor state to use/life phase.
The reason for doing this way is that we always hope to use same mode for several life phases: the the life phases would be in the modes, which seemed to me upside down, and the transitions controls in the life cycle are based on changes of actor state, mode transitions controls are based on measures of these states, similar but different.
Regards Thierry


Thank you for the reply.

Can you please elaborate on where to find the preference setting to authorize hierarchical alternance mode/state?

I am simply looking for a way, preferrably a matrix of some kind, to express which Modes are available/accessible in which States. Something like I am illustrating in the image below:


This should not be rocket science and, although very simplified, is a perfectly reasonable relationship to have as part of a model.

What are the steps for going about in creating and illustrating this relationship in Capella?


You can find this authorization in following menu:
Then you get a new window with a side tree choice in which you have to open
Then you may assess several choices in which you have this authorization
About your matrix, unfortunately, I don’t really see where to find. Only chance is if your modes and states are in differents layers, then you may look to have realization links… I never really tried. The only one I found is use manual traces… you find it by rightclick menu on the item (state, mode or other) then select wizard/trace manager. The direction of the trace is to be kept for the complete relation between the two concerned machines, but this has to be set between each relevant modes/states.


Thank you very much!

Selecting the tickbox ‘Mode/State mixed hierarchy allowed’ under Window → Preferences → Capella → Model seems to have made the big difference and allows me to continue building this part of my model. I am also now able to use a ‘Modes and States Reference Matrix’ to illustrate the associated realtionship between the States and Modes if I want, although the diagrams illustrate this sufficiently for the moment.

There are, however still some issues:

  • Technical Tool Issue: You can only add mixed Modes and States to a diagram using the Project Explorer, not the Palette. For some reason the Palette still blocks you from dragging a Mode into a diagram that already contains one or More States.
  • Principle Issue: Modes are truly always hierarchically subordinate to States, so when this option is enabled, the follwowing should actually be applied/enforced by Capella:
    • Modes should NOT be allowed inside States, which Capella still allows.
    • Functions should ONLY be allowed to be associated with Modes, not States
    • Capella should have new functionality whereby Modes are associated with States, in the same way Functions are associated with modes using a Transfer Dialog window.

In my opinion (and I am sure many other SEs would agree with me here), if the above is implemented in Capella correctly as explained, it would more closely match what is accepted and agreed on in the SE community as far as State/Mode relationships and associated diagrams/matrixes are concerned. It is clear (and a little dissappointing) that Capella still needs some work in this area. Maybe you could bring this under the developers attention?


I agree, below the tool as I dream it
Life phase is a combinated state of context (complete set of actors, actors being seen as component nodes): target is to achieve a composition link.
Layer OA:
OE have state machines in which states enable operational activites (exception)
Layer SA:
Actors inherit the relevant OE state machine*
System inherit a life cycle where only duty is set, initiated by computation by combination of actor states, transitions inherited from OE state machines (This machine could be complicated at first if too many actors inherit complicated machines)
System shall have mode machine : modes allocate life phases, then transition can be inherited from allocated phases
(*): The computation to raise life phase can be used to compute the state machine if an actor realizes several OEs
System capabilities are available during life phases. When designing SFS, involved functions get activated during modes to support life phase (at least find a way to adjust this relation efficiently)
Layer LA:
When dividing LCs and LF: Find a way to describe the way modes are distributed (machines should get simpler and simpler), Same principle as in SA to set relation to LF, LCr are required during the same phase as realized capability
Layer PA: repeats dividing components and functions
PCN deploy PCB, and then own a state machine where states allocate PCB modes (or composite modes when several of them are deployed by the same PCN).
This can drive to divide more functions to avoid having partial activation of the same function and have the function active during mode. This can make xDFB more complicated, and state change tracking during scenarios could be more important, but to me this is the most precise.

Just making sure that you saw this webinar on mode and states: Modeling states and modes with Arcadia and Capella: method and tool perspectives | Webinar Capella - YouTube
There is an update on the dev on this one: Capella Development Status & Future Work | Thales | Capella Days 2020 - YouTube at 27:15