[SysML] #18. Understanding Behavior of Block - Auto EE Sys Engineer`s Blog

쉬운 목차

Understanding Behavior of Block

In this blog post, we will take a closer look at Behavior of Block, These are the important elements of SysML (Block Definition Diagram). This component plays a key role in understanding the behavior modeling of complex systems in systems engineering.

In SysML, Block behavior is classified into two types.

Classifier Behavior : This is the default behavior that starts automatically when a block is instantiated. It is responsible for initializing blocks or performing key functions. You can think of it as playing the same role as a class constructor in object-oriented programming.
Behavior Feature : This is an additional behavior defined in the block and called to perform a specific task. These operations are also called Block Methods and include Operations and Receptions.

Classifier Behavior

Default behavior of a block : The classifier operation usually starts execution when the life of the block begins and ends when the life is over. However, execution may be interrupted even before termination.
Classifier action : Depending on the nature of the block, a formal choice for the classifier action is made between state machine and activity.
- State Machine : Used when blocks are primarily event driven.
- Activities : Blocks are primarily used to transform input items into output items.
Hybrid approach : A popular approach that uses state machines to describe the states of a block and specify activities that are executed when the block is in a particular state or transitions between states.
Assignment of actions : Actions may be specified independently of the block, or may be assigned to a block or part of a block.

Operation

Definition of Operations : Operations represents the actions performed by a block when called by a client. These are invoked by invocation events and represent mostly synchronous behavior. That is, the caller waits for the operation to complete before continuing its own execution. However, SysML allows any action to be marked as an operation, even if the caller does not wait for the operation to complete.
Format of BDD Operations : In BDD, operations are displayed as strings in the operation section of the block. The string format includes the operation name, parameter list, return type (if any), and multiplicity constraints.
<operation name> ( <parameter list> ) : <return type> [<multiplicity>]
Parameter list format : Zero or more parameters can be displayed in the parameter list, and each parameter is separated by a comma. Each parameter is displayed with its direction (in, out, or inout), parameter name, type, multiplicity constraint, and default value.
<direction> <parameter name> : <type> [<multiplicity>] = <default value>

Receptions

Definition of Receptions : Receptions represent the actions a block performs when a client sends a signal that triggers the block. That is, it is called by a signaling event when the client calls Receptions . Receptions always represent asynchronous behavior; the client does not wait for the reception to complete. Receptions continues its own execution immediately after sending the signal.
Importance of Signal : A signal is a model element that is used by one part of a system to send matter, energy, or data to another part. Receptions are typically used to trigger a Signal to execute an action.
Format of Receptions in BDD : In BDD, Receptions are displayed as strings in the Receptions section of the block and include the signal name and parameter list. The <<signal>> keyword must always precede the Receptions name.
«signal» <reception name> ( <parameter list> )
Parameter list format : Zero or more parameters can be displayed in the parameter list, and each parameter is separated by a comma. Parameters are displayed by name, type, multiplicity, and default value.
<parameter name> : <type> [<multiplicity>] = <default value>
Return values of Receptions : Unlike Operations, Receptions has no return type and is asynchronous. The client doesn’t wait for a response after sending the signal. Incoming parameters can only be input, not output.

Provided or Required Behavioral Features

Provided Behavioral Feature : If a Block defines a Provided Behavioral Feature, requests for that feature will be processed by the defining Block.
Required Behavioral Feature : If a Block defines a Required Behavioral Feature, it expects some external entity to handle all requests for that feature. In other words, in order for a block to function properly, it ‘requires’ certain services or functions from other system elements.
Display method on BDD : Provided Behavioral Features are indicated with the “prov” keyword in front of the feature signature, and Required Behavioral Features are indicated with the “reqd” keyword. The “provreqd” keyword indicates that the feature is provided and required. If a keyword is not displayed, the feature is assumed to be available.

Block Behavior with EA

Now, let’s look at how to model each of Block’s Classifier Behavior, Operations, and Receptions in EA. The characteristics of Block’s Behavior can be more accurately understood when explained along with State Machine, Activity, and Interaction, which will be discussed later.

In this post, we will practice how to create Classifier Behavior, Operations, and Receptions in Block. Let’s reuse the Battery Input model we created last time. Create a bdd and load the SMPS block onto the bdd.

Classifier Behavior

When an instance of SMPS is created, it creates 5V power from Battery power. In other words, the generated 5V operation is performed as a Classifier Behavior. Click the SMPS block on the bdd with the mouse and go to Properties window → Elements → Classifier Behavior… Clicking the button opens the Classifier Behavior window.

Refer to Types: ‘Activity’,’Interaction’,’StateMachine’,’ProtocolStateMachine’ at the bottom of the window. Classifier Behavior can be specified as Activity, Interaction, or StateMachine.

A brief explanation of these (we will cover them in detail later when we cover the Behavior Diagram) is as follows.

Activity: Models the process of converting input to output. It is used to express complex processing processes and workflows.
State Machine: Models how a system or block reacts to external events. Describes transitions between states and event handling.
Interaction: Describes how each part of the system interacts with each other through message passing. It is used to express the dynamic behavior of the system.

Let’s create an Activity to assign Classifier Behavior to SMPS.

Right-click SMPS, click New Child Diagram → Activity → with Activity Diagram, and enter Generate 5V as the name to create an activity dependent on the SMPS block. (At this time, an Activity Diagram is automatically created.)

Now, in the Properties window of the SMSP block, assign Classifier Behavior to Generate 5V, which is dependent on the SMPS block. You will then see Generate 5V in the section called Owned Behavior.

Then, if you save the diagrams and search for and run Reload Project in the Find Command section of the menu window, you can see that the entire project has been reloaded and Owned Behavior has been changed to Classifier Behavior.

Operations

Operations operates by client calls. SMPS assumes that there is an Operations called Check Current Status.

You can click SMPS Block on bdd and create Operations in Features window → Operation tab. (If you do not see the Features window, click Start → All Windows → Properties → Features.)

Let’s create a Check Current Status Operation using the Operations tab. Set Name to Check Current Status and Return Type to int. (We checked the status of SMPS and assumed output as Normal: 0, Warning: 1, Degradation: 2, Error: 3, etc.)

In the case of Parameters, a separate window to add parameters will pop up as shown below.

Create a parameter called check mode, set Type to int and Direction to in. When checking the status of SMPS, we assumed that there are several modes.

Then, we created a parameter called set error bit, set the Type to byte and the Direction to out. In this case, if an error is found during the Check Current Status Operation operation, it is a function that sets the error in a specific register.

What can be overlooked here is the Direction of the Parameter and the Return Type of the Operations itself. In the case of Return Type, this is the result returned to the call that called Operations when Operations is completed.

Because Operations returns when it completes. However, if the Parameter’s Direction is in, this is data entered when Operations is requested. And in the case of out, this is data output while Operations is running. For example, during Operations operation, the status of various properties owned by Block can be changed and data for these changes can be output.

Lastly, the description of Scope is as follows.

Public:
- Actions defined in public scope can be called directly from external blocks or systems.
- It can be accessed from inside and outside of other blocks.
- Public actions are used to define the interface of the system and handle external requests.
Protected:
- Actions defined with Protected Scope can only be accessed from other blocks belonging to the same package.
- It can also be accessed from inherited blocks.
- Protected behavior is mainly used in inheritance relationships and is used to specify behavior that can be overridden in subclasses.
Private:
- Actions defined as Private Scope can only be accessed within the same block.
- It cannot be accessed from other blocks or from outside.
- Private operations are used to encapsulate the internal implementation of that block and provide a reusable unit of code.
Package:
- Actions defined with Package Scope can only be accessed from other blocks belonging to the same package.
- It cannot be accessed from outside the package.
- The Package action is used to group modularized code and package related functionality.

The SMPS block where Operations is created is as follows.

Receptions

Receptions are called by signaling events sent by the client. Therefore, a Signal Block is required to create Receptions in the Block. Our SMPS is a System Based Chip and has the ability to Hard Reset the system by turning the 5V power Off → On when the MCU fails. In other words, it has a Watch-Dog Timer and periodically receives a hopping signal from the MCU.

Select signal from the bdd toolbox, create it on the bdd canvas, and name it hopping. And create Frequency and Voltage Attribute in the Features window of the hopping signal block → Attribute tab.

Now, in SMPS block, go to Feature → Reception → Name… Click the button to assign <> hopping. Then, Name: hopping (same as signal name) and Parameter: Voltage, Frequency (same as signal attribute) are automatically assigned.

As explained above, Receptions are an asynchronous operation (i.e., the client only sends a Signal and does not care about the output from the block), so there is no Parameter direction and Receptions Return Type.

The SMPS block in which Receptions is created is as follows: