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.
2 Likes
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
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.
1 Like
I am new to Capella. I could not find any answer to my problem. Why I can’t drug and drop both states and modes to the diagram area – either state or modes only?
Not enough stressed, IMHO, that a stm is for a system undergoing design, and not for its components. A system can be in one state only at a time. So, a stm diagram illustrates the system behavior but does not allocate functions to the system’s items. In other words, yes, a STM is implemented (e.g. by software), but a state diagram, truth table, mode/function table, or else, that illustrate the stm, does not define allocation and hence implementation. Again, a STM is modelled while understanding the behaviour and functions, just like a use case model or an activity diagram without swim lanes, but not for defining architectures.
Nevertheless, a stm can allocate bahaviour (not functions) to system components if the engineers use regions on the diagram to illustrate a submachine(s) within the stm. I like that Capella has that capability.
You may be interested in this webinar on Mode and States if you have not seen it: https://www.youtube.com/watch?v=74eKWrSs8hI
Hi. This seems to be a misunderstanding : a STM is just one kind of behavior (description). It describes the behavior of a model element. As other behaviors, it cannot exist on its own. If it is a so called executing bahavior then it is owned by some model element (which, in UML, is called behaviored classifier and can be e.g. a UML class). If it is a socalled emergent behavior it still describe a behavior of some composite element. So STM can describe behaviors of elements and STMS need to be implemented. And as any implementation, such implementation also need to be traceable to the model, in this case the STM and vice versa. Otherwise, there is a gap between the actual product, e.g. executable software code and a system model. Which is, btw, the most critical problem in today´s MBSE anyway, imho.
My reaction is: I miss as well a way to make system modes support system life phases (states) built after actor states that enforce requirements/capabilities/missions, then LC and PCB modes designed to support their parent ones, with transition link between levels, and then PCN technical states support PCB modes… Even sometimes decide to convert states to variant (and then not deliver unused functions when not required by functional variant that do not require some capabilities/missions) Today, the only link I see between all this is triggers and guards used in transitions…
Could you provide the paper?
In addition to all that was said above, I did find this video States and Modes quite good to explain the concepts related. It may provide more insights to us about states and modes concepts independently of a tool, language or method.