modes and states

Hello,
what is the difference between modes and states or rather mode-diagrams and state-diagrams in capella?
What is the difference/outcome when you use the one or the other?
Kind Regards

Hi,
Below is an extract from a paper that we recently submitted to a conference (it will hopefully be published in a few months).
We are also currently working on an open source add-on to Capella that will allow to better analyse the impacts of modes and states on the system, using configuration element.
In Arcadia, modes and states are defined separately. There is no “inclusion” of modes within states or of states within modes. They are symmetrical (no syntactic difference between them).
Mode. The definition of the expected behavior of the system (or of its actors, or of its components) in situations foreseen at design time is captured in the form of system modes. Each is mode is mainly characterized by the expected functional content of the system in this mode. A mode can reflect various concepts, such as
the phases of a mission or of a flight for example (taxiing, taking-off, cruising, landing, etc.)
the specific required functioning of the system under certain conditions (connected, autonomous, etc.)
the specific conditions in which the system is used: test, training, maintenance, etc.
The transition from one mode to another is in general the result of a decision, such as a change in the way the system operates, in order to adapt to new needs or new contexts. It is therefore conditioned by the choices of the system, of its users, or of external actors. In the model, the trigger of a transition is likely to be related to a functional event.
The set of modes and the transitions between them are described in a “mode machine”, which syntax is based on SysML “state” machines.
State. During its life and its use, the system passes through states that it undergoes. A state often directly reflects as operating condition or status on structural elements of the system: operational, failed, degraded, absent, etc. States are also likely to represent the physical condition of a component (full or empty fuel tank, charged or discharged battery, etc.). State can also be exploited to represent environment constraints (temperature, humidity, etc.). The transition from one state to another is often not the result of a decision but rather corresponds to a change of physical properties.
The formalization of these identified states is captured in a “state machine” that uses the same underlying syntax than the ones for the modes. The transitions carry the triggering change event but are not likely to be associated to functional events.

1 Like

Thank you for your extensive answer!
With the explanation/definition the difference (and different purpose) becomes much more clear.
Kind regards

Hi! The States and Modes stand out in the metamodel of Capella/Arcadia in that there is no allocation of state machine SM (or a region within it) to any model element analogously of e.g. allocation of a function to a component in LA. Why is that? How then should the model express where a SM is implemented? (The natural semantics of “allocation” relation in LA for me is “implemented by”). Is it “parent” relationship, i.e. a SM is contained e.g. in a logical component would mean that logical component implements it? If so, why is this different to other metamodel elements that do provide for allocation. Br, Marek

@JNavas @MBispo or anybody: Any reaction to this?

Hello Marek,

may be I do not fully understand your question but…

…a SM is not implemented. A SM is only one way to descibe behaviour (of a system, a part of a system,…).
Only the functions get implemented. And the functions (whose behaviour are described e.g. by SMs) can be implemented on different components. So a Capella/Arcadia SM has no “allocation” to a component.

And one function can belong to different SMs - this could lead to a confilict if the function and the SM are allocated to different components.

Does this fit to your question…?

kind regards

Hi, yes, functions used in states can (as entry/exit/do…) can be spread across different components and reused in different SMs, correct. But where is done the decision making as to what state transition si to be made is done = what is the next state? In other words, who will check if the event trigger a transition and which one? Who will call the entry/exit/do/effect of a transition functions? All this is the task of and needs to be implemented in a state machine (SM) . If you open any SW code containing a SM you´ll find it being implemented mostly either using the State design pattern or a variant of a matrix/table. So the SM logic needs to be present in the SW code thus the model needs to contain information which LA/PA element implements it.

Copyright © Eclipse Capella, the Eclipse Capella logo, Eclipse and the Eclipse logo are Trademarks of The Eclipse Foundation.