The transformation form SysML to HiLeS consists of two parts: structural and behavior. This division simplifies the transformations and allows to focus on specific aspects of the SysML model and maintain a low coupling between structural and behavior aspects. The structural transformation focuses on the hierarchical composition on blocks and the connections between them. The Behavior transformation focuses on the activities defined for each block and their corresponding activity diagrams.
Structure Transformation
The structural transformation consists of creating the required HiLeS Structural blocks and Payloads that correctly represent the system's hierarchy defined in the SysML bdd and ibd diagrams. Since the bdd contains explicit hierarchical information in the form of containment relationships between blocks, the structural transformation is straight forward and basically consists in creating a HiLeS structural block for each of the SysML blocks that represents a system component. Then for SysML blocks that have children a HiLeS architecture is added to its corresponding Structural block and children corresponding blocks nested inside it. Finally, flow ports and connectors defined in the SysML ibd of each block are used to create the HiLeS Ports, Services and Payloads required to interconnect the blocks.
Block Hierarchy
In SysML block hierarchy is constructed by Association (with Containment) relations between blocks. A parent block has associations to its children blocks as presented in the figure. This hierarchy must be preserved in the HiLeS model. The Structural transformation rules produce the HiLeS hierarchy presented in the next Figure. The SysML System block is transformed in to a HiLeS Structural block. In order to create the hierarchy, an innner Architecture is created for the HiLeS Structural block. The SysML Process and Capture blocks are transformed to a HiLeS Structural block respectively and added to the Architecture's blocks.
Ports and Connectors
The other elements present in the structure model of the system are the ports and connectors created to allow communication between blocks. In the SysML model, these connections are created using FlowPorts and Connectors. In the HiLeS model a FlowPort is represented by a Port in the equivalent FlowPort owner block and a Service in the equivalent owner block inner architecture. The port is the connection point with other blocks and its parent block inner architecture. The service is the connection point with its children.
Details of the Transformation rules can be found here .
Behavior Transformation
The behavior transformation consists in creating the required HiLeS Control Net (HCN), Port, Service and Payload elements to correctly represents the system's behavior expressed in the SysML Activity Diagrams. For each block in the system's bdd there must be an Activity Diagram defined. One of the advantages of using Activity Diagrams is that since they are based on Petri Nets, making the transformation of most of its elements straight forward since the HiLeS Control Net is based on Petri Nets. We present an overview of the transformations of some of the activity diagram elements. A detailed description can be found in the Technical Manual.
The first elements to consider are the CallAction nodes. In our approach we currently support the use of two types of actions: CallBehaviorAction and CallOperationAction. CallBehaviorAction are used to invoke other ActivityDiagrams which is equivalent to the hierarchical construction of the bdd. This means that the ActivityDiagram of a block must have CallBehaviorActions for all of its children's activities. Since the CallBehaviorActions represents an invocation to another block's activity, the transformation creates a structural block and adds the required HCN elements to correctly represent the behavior of the block. For the CallOperationACtion the transformation is similar, but instead of a structural block a functional block is created.
One of the elements that does not have a correspondence to Petri Net elements are decision nodes. For decision nodes we defined a tranformation rule which creates a functional block for each control flow leaving the decision node. Since each control flow represents a comparison value, the function of the functional block is to validate the corresponding guard and allow execution of the following elements. The DataFlow that represents the value of the decision is represented by a Payload that is connected to each of the functional blocks. The next figure presents the case for a decision node with two guards (on/off).