SysML State Machine Diagram + Examples (Cameo Tutorial)

This video explains the state machine diagram (stm) in SysML, the elements/relationships which are typically represented on the stm, and how the stm fits into other SysML diagrams.
Topics Discussed:
-States & Psudostates
-Triggers, Guards, & Effects
-Deep History & Shallow History
-Entry/Do/Exit Behaviors
-Diagram Refinement
0:00 Introduction
0:19 Definitions & Naming Elements
1:43 Simulation Example (State Changes, Triggers, Guards, Shallow & Deep History)
5:05 Adding Activities to State Machines (Entry, Do, & Exit Behaviors)
9:37 Oscillating Fan Example Intro
10:39 Oscillating Fan 1st Pass
14:45 Oscillating Fan 2nd Pass (Adding RPM Property)
19:54 Opaque Behavior
22:09 Orthogonal States
22:43 Replacing Opaque Behavior with Activity
25:35 Refining Oscillating Fan 2nd Pass Error
30:10 Deep History Question
32:51 Final Thoughts
This example will provide information regarding Digital Engineering (DE), Model Based Systems Engineering (MBSE), and Systems Modeling Language (SysML).
Video compatible with the following versions of SysML Tools
-Cameo Systems Modeler 19.0
-Cameo Systems Modeler 2021x
-Cameo Systems Modeler 2022x
-Cameo Enterprise Architecture 19.0
-Cameo Enterprise Architecture 2021x (used in this demo)
-Cameo Enterprise Architecture 2022x
-MagicDraw 19.0
-MagicDraw 2021x
-MagicDraw 2022x
Video relevant or similar to the following Tools
-IBM Rational Rhapsody
-Oracle Sparx Systems Enterprise Architect
-Genesys by Vitech
-Microsoft Vizio
#SysML #DigitalEngineering #MBSE #engineering #CameoSystemsModeler #MagicDraw #simulation #ModelBasedSystemsEngineering #UML #SystemsEngineering #SystemDesign #SystemArchitecture #design #methodology #digitaltransformation
SysML Diagrams:
SysML Structural Diagrams:
Block Definition Diagram: #bdd #blockdefinitiondiagram
-Block, Interface Block, Constraint Block, Value Type, Enumeration, Signal, Instance, Proxy Port, Full Port, Directed Aggregation, Directed Association, Directed Composition, Generalization, Usage,
Internal Block Diagram: #ibd #internalblockdiagram
-Part Property, Value Property, Reference Property, Constraint Property, Flow Property, Constraint Parameter, Binding Connector, Item Flow, Proxy Port, Full Port, Interface Block
Package Diagram: #pkg #packagediagram
-Package, Package Import, Element Import, Navigation, Start Here Page
Parametric Diagram: #par #parametricdiagram
-Rollup, Constraint Block, Part Property, Value Property, Reference Property, Constraint Property, Flow Property, Constraint Parameter,
SysML Requirement Diagram:
Requirement Diagram: #req #requirementdiagram
-Extended Requirement, Satisfy, Verify, Relationships, ID, Test Case Activity, Trace, Derive, Copy,
SysML Behavioral Diagrams:
Activity Diagram: #act #activitydiagram
-Allocation, Swim Lanes, Swimlanes, Activity Partitions, Actions, Activities, Call Behavior Action, Opaque Action, Control Flow, Object Flow, Send Signal Action, Accept Event Action, Time Event, Initial Node, Activity Final, Flow Final, Decision, Merge, Fork Horizontal, Join Horizontal, Input Pin, Output Pin
State Machine Diagram: #stm #statemachinediagram
Initial, Final State, Composite State, Orthogonal State, Submachine State, Deep History, Transition to Self, Entry Point, Exit Point, Junction, Choice
Sequence Diagram: #seq #sequencediagram
Lifeline, Alternatives, Loop, Option, Call Message, Send Message, Reply Message, Create Message, Delete Message, Diagonal Message, Message to Self, Recursive Message, Lost Message, State Invariant, Duration Constraint
Use Case Diagram: #uc #usecasediagram
-Actor, Use Case, Include, Extend, Association, Generalization, Block,
Visit our website for more available free resources at www.CameoMagic.com

[@nivethavijayasekaran3930]

Awesome video, thanks for sharing 😊 keep posting regularly

[@CameoMagic]

Thanks for the awesome feedback, we intend to keep releasing videos!

[@BruceDouglass]

To answer your question at the end, in each orthogonal region, have the initial pseudostate transition to a history pseudostate, and from the history pseudostate in each region to the initial state you want to activate. You need a history pseudostate in each region and it should transition to the initial state you want to activate "before there is history". I'd throw in an image if I could ;-)

[@CameoMagic]

Awesome thanks for the answer. We may have to create a follow on video to explain these topics.

[@hwang-dj1pb]

@@CameoMagic pls make a video, I just cant understand🥲

[@jonathanhladchuk2785]

Do you have any suggestions for recording the runtime duration of a simulated State Machine & State as a value property or any property that can be used in parametrics??? I have never been able to find a solution that works with States and State Machines, as they do with Activities...I primarily use Cameo and creating or applying duration constraints is simple but actually recoring that duration from the simulated State Machine does not seem to be possible, despite it being very easy with activities.

[@CameoMagic]

I'd recommend manipulating the variable "simtime". You can put a constraint like "simtime > 20,000" as a guard for a transition. This means that the transition cannot occur until 20 sec has passed.

[@robs2291]

What would be the best way to model that if the fan is “off” (i.e. zero speed), it automatically shouldn’t oscillate. It should only be able to oscillate on the low, medium or high speed states i.e. there is a dependency between the orthogonal states.

[@CameoMagic]

Good point, I hadn't thought of stimulating the oscilate in more detail. While there are multiple ways to model, one way would be to add another value property under fan block, which is boolean called "rotating". When the fan is in the "off" & "oscilating" states, "rotating" = false. You could add logic to the other states (with opaque behaviors) to act appropriately similar to the way we did the RPM situation.
Remember the "oscilate" state is currently modeled as when the knob is pushed in, and the "static" state is when the knob is pulled out. It may have been more helpful/less confusing to have named the states "pushed in" and "pulled out" to parallel the speed states naming convention: "3", "2", "1" instead of "High", "Medium", "Low".

[@markhancock8045]

Would it make sense to model the switch states, which can be changed when the fan is on or off, ie, like a real 4 way switch. Then use those switch states to control the fan and oscillation states?