Managing State/Mode Diagrams and Models

Capella
1

Hello! I’m getting deeper into some state/mode diagraming, and I’m looking for some advice on how to manage the diagram and model to keep it clean and readable.

  1. Is there any issue with deleting the “regions” that are part of states/modes? I know they can be used for substates or parallel state diagrams. However, if I have an atomic state/mode (no other states/modes in it), will I run into any problems if I delete the region? The benefits of removing it would be to improve readability and reduce the number of graphical objects I need to manage.

  2. On transitions, is there anyway to list conditions or insert line breaks to make the conditions more readable?

  3. Is there a best practice method for listing conditions with logical operators (“and,” “or,” “not,” etc.)? Currently I’m just typing out the statement. I see that I can list multiple events to trigger a transition. To me this implies an "or " relationship between the events for triggering the transition - is this correct?

  4. On a transition, is there a functional difference between listing a conditions as guard conditions versus a trigger conditions, or is it more personal preference? Here is how I am thinking about it: if I want a transition to happen when speed > 100 kph and a button pressed, I could enter a trigger event for “button pressed” and a guard of “speed < 100 kph.” Alternatively, I could just list a trigger event for “speed > 100 kph AND button pressed.” To me, this seems subjective, but I wonder if I have a misunderstanding. Do I?

  5. When I list activities/functions relevant to a state, is there a difference in the model or tool if I put a function in the Entry, Do, or Exit field compared to the Operational Activities/Functions field? I’ve seen examples where functions are entered in both locations (for example, the 2nd field and the 4th field), and I’ve seen examples where functions are entered in just the 4th field.

image
image900×154 3.71 KB

Thank you in advance for any thoughts or assistance!

2

Hi Nate,
Here’s my thoughts on this:

  1. I don’t believe there are any issues with deleting the default region from a mode or state. As you say, this reduces the mode or state to a simple type, not a complex type.
    After all, you can always add a new region again if needed.
    If you are not too worried about capella resources, then the filter to hide region names may be sufficient to simplify your diagrams
  2. I don’t think there are, except to reshape the text box and insert padding spaces in the Trigger text
  3. The multiple trigger conditions indicate an OR relationship as you say.
    If you want an AND then it becomes a single trigger condition and you add the AND to the trigger
    e.g. In flight AND Manual Control
    You can add brackets () to enclose this too, if you like.
  4. The difference is between a positive action like button pressed or speed achieved versus a gate condition like insufficient speed. This becomes less trivial when multiple triggers or guard conditions are expressed. But as you say boolean logic can resolve most conditions to one or the other.
    Descriptively, it also allows separation of controls e.g. the guard conditions could be monitored and controlled by safety functions which could be developed more stringently. This gives more clarity to the system description.
  5. Entry and Exit functions are understood to be performed adjacent to a transition.
    Do functions are expected to be performed when in the state.
    Operational Activities / Functions are available when in the state (but not necessarily performed all the time)
2 Likes