shrms

The behavioral representation forms part of the logical solution formulation of the desired system. It’s describes the system from a dynamic perspective (functionality). In this case the Activity element is used to represent the dynamic part of a block and an Activity Diagram is used to express the details of its behavior. Each block of the BDD has associated an Activity and that Activity has in turn an Activity Diagram that details how the children of that block is behave.

For our example, the behavior of the SHRMSRemote block is defined. First, an Activity is created as its child from Outline view with the name Main. The Activity Diagram is added right clicking on the activity in the outline view. For the same block is possible to add more than one Activity in order to define different versions of behavior.This option allows changing the level of detail, the complexity, the desired flow, and so on.

The figure 1 shows the Activity Diagram for SHRMSRemote block. The diagram is started with an Initial Node, in which four Call Behavior Actions are defined.This allows to do calls to the activities of the child blocks of the parent block and to define their execution sequence across the Control Flow connector. Initially, there is a Decision Node to control the flow of execution, which depends of the validation of energy. If the result of the validation is true, start executed the behavior for Capture block otherwise the execution of the system is finished with an Activity Final Node.

 Figure1. SHRMSRemote Activity Diagram

Call Behavior Actions

Call Behavior Actions are used to include functionality from other blocks in the activity diagram. When a new Call Behavior Action is added, a popup window will be prompted to select the name for the activity and to select the desired behavior which can either be a new activity or an existing one (see Figure 2). For the name is recommend to use the activity's parent block name. For example, in Figure 1 a Call Behavior Action was added to the Behavior activity of the Acquisiton block. As result the Call Behavior Action is labeled as Acquisition:Behavior.

 Figure2. New Call Behavior Activity

Fork and Join Node

A fork node is used to define more of one output flow from one input flow. It allows activate each of the elements connected to the outputs flows. A join node is used for produce an output only when all input flow control indicate that the execution of the connected elements has finished.

The Activity Diagram for Acquisition block, see figure 3, is started with the execution of the sensorAcquisition activity, afterwards is executed in parallel form the VisualizeAcquisition and CommunicationAcquisition activities. When both activities finish  the Activity Final Node is activated across of ControlFlow7 resulting of the join node.

Figure3. Acquisition Activity Diagram

Input Pin, Output Pin and Object Flow

The Input and Output pins are required to exchange data between a block and the enviroment or between blocks. After adding a pin to the activity diagram is specified an appropriate name and is choosed a type. The type shall correspond the block selected how reference in the Flow Port that is defined in the IBD.

In the figure 1, the acc_m pin added to the Acquisition activity has the Acquisition_acc_m block selected as its type. This block was created when the acc_m Flow Port was added on the SHRMSRemote and Acquisition ibds (see Figure 2 in Defining Structural Representation). The Object Flow connector allows the connections between pines. The pins added to the diagram rather than to a Call Behavior element, represent a connection from the parent block to one or more of its childrens.

Decision Node

The Decision Nodes are control elements allow the execution to take a different path according to a decision. To specify the type of conditions SysML uses the Guard concept, which can be of various types, in our approach is supported Literal Boolean and Literal String Guards. It's used the Decision Input Flow attribute to specify the object that will be used to make the path taking decision which must be associated to an Object Flow. In the activity diagram of Figure 1, the Esys object flow connection is used to connect the Esys:SHRMSRem_Enet input pin to the Decision Node and associated to the node's decision input flow attribute. Guards are not associated to Decision Nodes, but to output Control Flows. In our case, a Guard must be defined for the ControlFlow9 and ControlFlow10 connections.

Call Operation Actions and Operations

When is required to express specific block functionality is uses a Call Operation Actions. Call operations are actions that can use to invoke operations in a model. In our approach operations represent a specific behavior that can be described in HDL, usually in the form of an Intellectual Property (IP), and the parameters represent required input and generated output signals. Each parameter has a name, a type and a direction. In our case, the type attribute must be a reference to a block, specifically to the block that is associated with the In or Out Flow Port that represents the signal in the ibd. A parameter can have one of the following two directions: in or out, and it must be coherent with the direction of the Flow Port that it represents.

Before adding a Call Operation Action, must be created the operations as children of the block where they are executed. In the figure 4 is showed the SensorAcquisition activity, which has a Call Operation Action called SignalProcessing. It references the operation SignalProcessing that has as input parameter a signal (acc) which is send from the Capture block and as output parameter the signal resulting of a process in the operation. The process can include clean, averaged, amplified, conversion, etc, of the input data.

 Figure4. SensorAcquisition Activity Diagram