8.1 State Machine Basics: States, Regions & Orthogonality

8.1 State Machine Basics: States, Regions & Orthogonality

Quick Reference: In SysML v1.2, State Machine Diagrams (stm) model the discrete, reactive states and event-driven transitions of a classifier (typically a Block). The diagram frame header follows stm [StateMachine] StateMachineName [diagramName]. States represent stable lifecycle conditions, whereas pseudostates are transient control vertices that cannot dwell. Composite states contain nested sub-states, and orthogonal regions (separated by dashed lines) execute concurrently, maintaining an active state in every region simultaneously.

---

Purpose and Role of State Machine Diagrams

SysML provides four behavioral diagram kinds: Activity Diagrams (act), State Machine Diagrams (stm), Sequence Diagrams (sd), and Use Case Diagrams (uc). While Activity Diagrams emphasize procedural execution flows, token routing, and transformation of inputs into outputs, State Machine Diagrams (stm) focus on the modal behavior of system entities.

A state machine specifies how an individual classifier—most commonly a structural Block—reacts to events over its operational lifetime. State machine modeling is indispensable for systems exhibiting distinct operational modes, such as:

• Aerospace flight modes (e.g., PreLaunch, Ascent, OrbitInsertion, DeOrbit)
• Automotive powertrain states (e.g., Park, Reverse, Neutral, Drive, Sport)
• Medical device control states (e.g., SelfTest, Calibrating, Infusing, AlarmSuspended)
• Power management states (e.g., PoweredOff, Standby, NormalOperation, LowPowerMode)

Diagram Frame Header Syntax

Like all SysML diagrams, a State Machine Diagram is enclosed within a rectangular frame border featuring a standardized header in the upper-left corner:

stm [StateMachine] StateMachineName [diagramName]

• stm: The mandatory canonical three-letter lowercase mnemonic for State Machine Diagrams.
• [StateMachine]: The metaclass type of the enclosing model element owning the diagram.
• StateMachineName: The name of the state machine the frame designates; SysML 1.2 Annex A lists only "state machine" for this diagram kind. The block whose behavior the state machine describes is its context, but the block's name is not the frame's element name.
• [diagramName]: An optional, user-assigned descriptive title providing engineering context (e.g., [Thermal Control Operational Modes]).

---

Defining States in SysML

In SysML, a State models a condition or situation in the lifecycle of an entity during which it satisfies some invariant condition, executes an ongoing behavior, or waits for one or more external events to occur.

Visual Notation

A state is rendered graphically as a rectangle with rounded corners:

• Sharp rectangular corners represent blocks, classes, and requirements.
• Rounded corners represent states on a state machine diagram.
• UML 2 also draws actions as round-cornered rectangles, so the diagram kind (stm vs. act) and the surrounding notation, not the corner shape alone, tell a state from an action.

State Compartments

A state icon can be divided horizontally into three distinct compartments:

1. Name Compartment: Contains the state identifier (e.g., Operational, Standby, DegradedMode). Optional stereotype labels (such as «mode») may also appear here.
2. Internal Behaviors Compartment: Lists state-dependent behaviors categorized by three standardized reserved prefixes:
   • entry / <behavior>: Executed immediately upon entering the state.
   • exit / <behavior>: Executed immediately prior to leaving the state.
   • do / <ongoing-behavior>: An interruptible ongoing activity executed while residing in the state.
3. Internal Transitions Compartment: Lists transitions that handle events entirely within the state without triggering state exit or entry behaviors, formatted as trigger [guard] / effect.

+-----------------------------------+
|            Operational            |
+-----------------------------------+
| entry / initializeSensors()       |
| do / executeClosedLoopControl()   |
| exit / parkActuators()            |
+-----------------------------------+
| StatusQuery / reportTelemetry()   |
+-----------------------------------+

---

True States versus Pseudostates

A fundamental distinction tested extensively on the OCSMP Model User exam is the difference between a True State and a Pseudostate.

The Dwell Time Invariant

• True State: A stable behavioral vertex in which a system can dwell, wait, or rest across measurable time. While dwelling in a true state, the system may execute continuous do activities or wait indefinitely for external events.
• Pseudostate: A transient graphical vertex used to chain, route, or initialize transition paths. A state machine cannot dwell or wait in a pseudostate. Execution must pass through a pseudostate instantaneously within a single Run-to-Completion (RTC) step.

Pseudostate and State Classification

Exam Trap: Modeler candidates frequently mistake the Final State for a pseudostate. A Final State is a true State, not a pseudostate! Consequently, a state machine can dwell in a final state until its enclosing composite state or owning execution context is terminated. Conversely, the Initial Pseudostate is strictly a pseudostate; it can never wait for events and cannot have an incoming transition.

Rules for Initial Pseudostates

1. An initial pseudostate must have at most one outgoing transition.
2. An initial pseudostate can have no incoming transitions.
3. The outgoing transition from an initial pseudostate cannot have a trigger event or guard condition; it fires unconditionally and immediately upon region activation.
4. Every region in a composite state or top-level state machine should define an initial pseudostate to designate its default entry target.

---

Composite States and Hierarchical Decomposition

In complex industrial engineering, modeling every operating condition as a flat network of simple states produces an exponential explosion of states and transitions (known as the state explosion problem). SysML resolves this through Composite States.

A Composite State is a state that contains one or more nested Regions. Each region contains its own sub-states, pseudostates, and transitions.

Sequential (Non-Orthogonal) Composite States

A sequential composite state contains a single region. When the composite state is active, exactly one of its nested sub-states is active at any given moment.

Modes of Entry into a Composite State

There are three distinct mechanisms for entering a composite state:

1. Default Entry (Boundary Entry): An incoming transition terminates directly on the outer border of the composite state. The state machine activates the composite state, executes its entry behavior, and then immediately follows the internal initial pseudostate to activate the default nested sub-state.
2. Explicit (Direct) Entry: An incoming transition crosses the outer border of the composite state and terminates directly on a specific nested sub-state. The composite state's entry behavior executes first, followed immediately by the entry behavior of the targeted nested sub-state (bypassing the initial pseudostate).
3. History Entry: An incoming transition terminates on a history pseudostate ([H] or [H*]), restoring previously active states.

---

Orthogonal Regions and Concurrency

An Orthogonal Composite State is a composite state divided into two or more independent, concurrent sub-state machines called Regions. Graphically, orthogonal regions are partitioned by dashed horizontal or vertical lines (- - -).

+-------------------------------------------------------------+
|                     NormalOperation                         |
+-------------------------------------------------------------+
| [PowerRegion]                                               |
|  (●) ---> [ BatteryPower ] ---> [ SolarArrayPower ]         |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| [ThermalRegion]                                             |
|  (●) ---> [ RadiatorActive ] ---> [ HeatersEngaged ]        |
+-------------------------------------------------------------+

Active State Configuration Invariant

Concurrency in SysML state machines is governed by the Active State Configuration rule:

When an orthogonal composite state is active, every region within that state must concurrently possess exactly one active sub-state.

In the spacecraft example above, while NormalOperation is active, the system does not alternate between power and thermal management. Instead, it simultaneously resides in both regions. An active state configuration might be represented as the tuple:

$$\text{Active Configuration} = \{\text{NormalOperation},\ \text{SolarArrayPower},\ \text{RadiatorActive}\}$$

Exiting an Orthogonal Composite State

An orthogonal composite state can be exited in two distinct ways:

1. Group Exit (Preemptive Boundary Exit): A high-priority external transition originates from the outer border of the composite state (e.g., triggered by EmergencyShutdown or FaultDetected). The instant this transition fires, all active sub-states across all regions are immediately aborted, executing their respective exit behaviors from the inside out.
2. Completion Exit (Synchronized Join): Each orthogonal region progresses until it reaches its local Final State. Once every region has reached its final state, the composite state generates an implicit completion event, which triggers an anonymous (triggerless) transition departing the composite state border.

---

History Pseudostates: Shallow [H] versus Deep [H*]

When a system temporarily leaves a complex operating state to service an interruption—such as an alarm, battery recharge cycle, or operator pause—it often must resume exactly where it left off rather than restarting from default initial states. SysML provides History Pseudostates for this purpose.

Shallow History ([H])

• Visualized as a small circle enclosing the capital letter H.
• Semantics: Restores the most recently active sub-state residing at the immediate, top level of the containing composite state.
• Limitation: If that restored sub-state is itself a composite state containing deeper levels of nesting, the deeper levels do not restore their previous history. Instead, the nested child composite state initializes via its normal initial pseudostate.

Deep History ([H*])

• Visualized as a small circle enclosing H*.
• Semantics: Recursively restores the entire active state configuration down through all levels of nested composite sub-states to the lowest active leaf state.

The Fallback Default Transition

What happens if a transition enters a history pseudostate, but the composite state has never been entered before (meaning no prior history exists)?

To prevent an undefined execution state, every history pseudostate can define an outgoing transition pointing to a default fallback state. If history exists, the history pseudostate directs execution to the remembered state; if no history exists, execution follows the default fallback transition.

---

Comparison: Shallow History versus Deep History

Consider an avionics mission computer with the hierarchy MissionMode -> InFlight -> LowAltitudeNavigation:

---

Exam Pitfalls & Misconceptions