[SysML] #27. Understanding Stm Diagram Event Pseudostate Region

쉬운 목차

Understanding Stm Diagram Event Pseudostate Region

In SysML, events are one of the key elements of a state machine diagram. Events cause changes in the state of the system and are therefore essential for understanding the dynamic behavior of the system. SysML defines four main types of events: signal events, call events, timed events, and change events. Each event type has its own unique way of triggering specific actions within the system.

1. Signal Event

Signal events are triggered by signals that occur externally or internally to the system. These signals indicate that a certain condition has been met or a certain task has been completed and are passed to the associated state machine. Signal events usually cause changes in the state of a system and are one of the important transition mechanisms in a state machine diagram.

Definition of signal events : A signal event represents the receipt of a specific signal instance. This signal is accepted by a structure that runs the state machine, that is, by a specific part or component of the system. If there is a transition triggered by a signal event, this transition must be associated with a function that receives a signal of the same name defined in the state machine.

Signal events and reception functions :
- Receive function: Receive is an action function that a block can possess, a function that is called when it receives a signal instance. This function defines the action that should be performed in response to a specific signal.
- Association with Block Definition Diagram (BDD): Signal events used in the state machine diagram are associated with the receive functions owned by that block in the block definition diagram. This clearly indicates the communication mechanism between the state machine and the blocks.

Parameters and arguments of signal events :
- Parameters and Arguments: If a listen owns a parameter, the corresponding signal event in the state machine can specify arguments for this parameter. This argument can be used to evaluate guard conditions or invoke actions within the state machine.

2. Call Event

Invocation events are triggered by a function or operation call from another component inside or outside the system. This type of event primarily occurs when certain functions inside the system are called, allowing the state machine to transition from one state to another.

Definition of call event : An invocation event indicates the receipt of a request to invoke an Operation on the target structure. This request can be sent from another structure, where the target structure is the structure that executes the state machine operation. When there is a transition in a state machine that is triggered by a call event, the structure executing the state machine must own the Operation that must be performed by that call.

How call events work :
- Operation Ownership: The structure (e.g. block) that executes the state machine contains Operations that must be performed in response to the invocation event. This Operation is typically executed by a synchronous call, where the caller waits for the operation to complete.
- Parameter Passing: An invocation event can contain parameters, which are passed along with the corresponding invocation event in the state machine. This provides the data needed when the called operation runs.

Notation of calling events : Invocation events are notated in the same way as signal events in state machine diagrams. Therefore, the reader cannot distinguish between these two types of events without additional model information. To make this distinction clear, we need to examine the operations and reception of blocks owning state machines within the model.

3. Time Event

Time events occur when a specified amount of time has elapsed or a certain point in time has been reached. This type of event is primarily used when the system needs to wait a certain time interval or take action when a certain point is reached. Temporal events allow state machines to model time-dependent behavior.

Types of time events :
1. Relative time event: Occurs after a certain period of time has elapsed. This period is calculated from the moment the state is entered and is expressed as, for example, “after 2 minutes”. Relative time events cause a state machine to enter a certain state and then take a certain action or change the state a set amount of time has passed.
2. Absolute-Time Event: Occurs at a specific point in time. This point is an absolute time based on a clock or calendar, for example, “at 10:30 AM on March 15, 2024.” Absolute time events cause the system to perform an action or change state when a scheduled time is reached.

Notation of time events :
- Relative time event triggers start with the “after” keyword, and absolute time event triggers start with the “at” keyword. This keyword is followed by a time expression in parentheses.
- This notation allows time event triggers to be clearly identified.

Use of time events :
- Time events are especially useful when the state machine needs to respond in a time-sensitive manner. For example, you can set the system to go into safe mode after a certain period of time when communication is interrupted.
- Relative time events can be used to ensure that a state machine moves to the next state only after remaining in a certain state for a certain amount of time. This can cause the system to maintain certain conditions for a sufficient period of time.
- Absolute time events are used when the system must perform an action or change state at a specific point in time. This is useful for setting up your system to react to scheduled tasks or events.

4. Change Event

A change event occurs when the state of the system or the value of a variable changes. This indicates that a specific condition or state in the system has changed, which can cause a change in state when this change satisfies the guard conditions of a specific transition. Change events are used to trigger state changes in response to dynamic changes within the system.

Definition of change event : A change event occurs when the result of a specific Boolean expression changes from false to true. This indicates that certain conditions within the system are met, and changes in these conditions cause a transition in the state machine.

Notation for change events :
- A change event begins with the keyword “when”, followed by a boolean expression in parentheses indicating its condition.
- This expression can contain properties owned by the state machine, properties owned by the block executing the state machine, or arguments passed to the state machine through other events.

Use of change events :
- Change events allow the state machine to react to changes in variables or states within the system. This allows the system to respond flexibly to dynamic environments and perform appropriate actions when certain conditions are met.
- For example, you can use change events to automatically trigger actions to clean up old data files when the available memory on your system falls below a certain threshold.

Role of events

Events are the main mechanism that triggers transitions between states in a state machine diagram. Each event type represents a unique situation that triggers a state change and plays an important role in accurately modeling the dynamic behavior of the system. By understanding and appropriately utilizing these event types, systems engineers can design the behavior of their systems more accurately and effectively. Events are an important consideration during the design and analysis of state machine diagrams and contribute to making the system more predictable and responsive.

Pseudo states: Control logic in state machine diagrams

Pseudostates are used to construct the control logic of a state machine diagram and represent important decisions and branches in the flow of operation of the state machine. Although pseudostates cannot be represented as being “in” a particular state during the execution of a state machine, they play an important role in controlling transitions between states. SysML defines several types of pseudostates, but initial pseudostates and joint pseudostates are the most commonly used.

Initial Pseudo state

Definition : Specifies the state to first enter when starting execution of a state machine or complex state.
Notation : Represented as a small, filled circle, there are no incoming transitions and no triggers or guards on outgoing transitions.
Purpose : When a state machine or complex state is activated, it clearly specifies which state it should immediately enter.

Junction Pseudo state

Definition : Allows combining multiple transitions between states into a single composite transition, providing transitions from multiple source states to one target state, or from one source state to one of multiple target states.
Notation : Represented as a small, filled circle, it can have multiple incoming and outgoing transitions.
Purpose : Used to simplify complex transition logic and clearly define the branching points of transition decisions.

Use of pseudo states

Control Logic Implementation : Pseudostates are essential for controlling the flow of a state machine, serving as starting points, decision points, or branching points for transitions between states.
Management of complex transitions : Helps to structure and clearly express the complex transition logic of a state machine.
Provides flexibility and clarity: Defines the state machine’s response to various situations, making the behavior of the system more flexible and easier to understand.

Regions: Parallel state representation in state machine diagrams

Regions of a state machine are essential for modeling the various simultaneous behaviors of complex systems. By using regions, we can represent multiple processes or activities that can proceed independently within a system or component (block), indicating that each action can occur simultaneously without affecting each other. This is especially useful for systems that must handle multiple tasks simultaneously.

Behavior of regions and state machines

Definition of a region: Each region consists of states and pseudostates (vertices) and transitions between them. Within a state machine, each region operates independently and can be in multiple states at the same time (one state per region).
Independence of regions: Regions operate independently within the state machine, and events or state changes that occur within a specific region do not directly affect other regions.
Initialization and completion of a region: A region begins with an initial pseudostate and is completed when the region’s activities reach the final state. Areas that have reached their final state are no longer active.

Local notation

Initial pseudostate: Represents the point at which a state machine or region within a state begins, represented by a filled circle.
Final State: Represents the point at which an area is complete, represented by a filled circle (bull’s-eye) surrounded by a hollow circle.

Precautions for using regions

Transition Restrictions: Drawing direct transitions between different regions is not allowed. State transitions within each region must occur only within that region. Modeling state transitions between different regions requires the use of higher-level or external coordination mechanisms.
Maintaining active states: Each region of the state machine must have exactly one active state at all times. This means that the system must always have a clear state for each function.

Local Advantages

The use of regions offers great advantages in effectively modeling the complex dynamic behavior of a system through state machine diagrams. Regions allow you to express various functions of the system in parallel and manage the state of each function independently. This makes the design of the system more flexible and easier to understand and allows different parts of the system to operate simultaneously without affecting each other.

If you are interested in other articles about the basic Knowledge of SysML with EA, please refer to the links below!

[SysML] #1. Understanding SysML Diagrams

[SysML] #2. Understanding SysML Package Diagram

[SysML] #3. Understanding Dependencies of Pkg Diagram

[SysML] #4. How to draw a Pkg Diagram with EA

[SysML] #5. Understanding SysML Requirement Diagram

[SysML] #6. Understanding Relations In Req Diagram

[SysML] #7. How to draw a Req Diagram with EA

[SysML] #8. Understanding SysML UseCase Diagram

[SysML] #9. How to draw a UseCase Diagram with EA

[SysML] #10. Understanding SysML bdd Diagram

[SysML] #11. Understanding SysML ibd Diagram