Episode 19.23 – SysML v2 Requirement, Variants, and API

Broadcast date: December 23rd, 2021

You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts.

Welcome to the 23rd door of our MBSE Podcast Advent Calendar. Today, we show you some more aspects of the next-generation modeling language SysML v2.

Yesterday we showed a simplified physical architecture of our Christmas tree in SysML v2. Today we will briefly look at requirements, the modeling of variants, and the SysML v2 API. First, let’s open our Jupyter notebook again.

This a quick reminder of what we already have. It is a simple physical architecture that specifies the parts of our Christmas tree and their connections.

Now we look at the requirements. We import a part of the requirements from the “International Christmas Standard” ICS-242526-12, which is modeled here with only one requirement.

package ICS242526_12 {
    requirement def ReqTreeHeight {
        doc /* The tree shall be at least 150 cm and maximum 200 cm high. */

            attribute treeHeight : ScalarValues::Integer;
       
            require constraint{ 150 <= treeHeight <= 200 }
    }
}

import TMPCT_PhysicalArchitecture::*;

package TMPCT_Requirements {
        
    import ICS242526_12::*;

    requirement <'REQ1'> 'Height of the Tree' : ReqTreeHeight {
        attribute :>> treeHeight = theMBSEPodcastChristmasTree.tree.height;
    }
    
}

The ICS242526 requirement “ReqTreeHeight” is a requirement definition. It specifies the name “ReqTreeHeight”, the requirement text after the “doc” keyword, and an attribute “treeHeight” to formally specify the constraint that the height of the tree must be between 150 and 200.

In the package “TMPCT_Requirements” we use the defined ICS242526 requirement. Our TMPCT requirement “Height of the Tree” is a usage of the requirement definition “ReqTreeHeight”. In addition, we specified a requirement ID “REQ1” and redefine the “treeHeight” attribute by setting it to the value of the appropriate value property of our Christmas tree.

The visualization of the requirements is not very exciting. Among other things, because we have not used relationships. The diagram only shows the relationship “defined by”, which you already know from yesterday.

Next, we have a brief look at how to model variants, because this is a hot topic in MBSE. First, we take our TMPCT physical architecture again. 

The variability is defined in two additional packages. In the TMPCT_Variations package, we define an abstract “christmasTreeVariations” part that contains the variations which constrain the allowed variants. The keyword and concept “variation” in SysML v2 is similar to the concept of a variation point. For example, we specified that our part “christmasTreeStar” can have one of the three variants “ecoStar”, “premiumStar”, or “standardStar”.

package TMPCT_Variations {

    import TMPCT_PhysicalArchitecture::*;
    import TMPCT_Variants::*;
        
    abstract part christmasTreeVariations :> theMBSEPodcastChristmasTree {
        
       variation part redefines christmasTreeStar {
            variant part ecoStar;
            variant part premiumStar;  
            variant part standardStar;  
       }
       variation part redefines christmasTreeStand {
            variant part largeStand;
            variant part standardStand;
       }
      
       abstract constraint { (christmasTreeStar == premiumStar & christmasTreeStand == largeStand) }
   }
}   
    
package TMPCT_Variants {
        
    part ecoStar;
    part premiumStar {
        part ledLight;
    }
    part standardStar;

    part largeStand;
    part standardStand;
}

We also defined another variation for the part “christmasTreeStand”. In addition, we defined a constraint that specifies if the “premiumStar” variant is selected, you must also select the “largeStand” variant.

The variants are defined in another package “TMPCT_Variants”. Very simple, we just defined the parts. Only the “premiumStar” part owns another part “ledLight”.

The visualization of the model depicts some new special SysML v2 notation elements for the variants. It shows the specified variants of a variation by a relationship.

Finally, we defined two products of our MBSE Podcast Christmas Tree: the “ecoTree” subsets the abstract part “christmasTreeVariations” and selects the “ecoStar” and the “standardStar” variants. The “premiumTree” selects the “premiumStar” and the “largeStand” variants.

package TMPCT_Configurations {
    
    import TMPCT_Variations::*;

    part ecoTree :> christmasTreeVariations {
        part redefines christmasTreeStar = ecoStar;
        part redefines christmasTreeStand = standardStand;
    }
    part premiumTree :> christmasTreeVariations {
        part redefines christmasTreeStar = premiumStar;
        part redefines christmasTreeStand = largeStand;
    }
}

We close this episode with a brief look at the SysML v2 API. We can publish our model to a SysML v2 repository server which is provided by the company intercax. To have everything in one model, we put all our previous packages into one package called TMPCT.

The %publish command posts the model to the intercax SysML v2 server. There, we can access our model via the SysML v2 API. Through the Swagger UI, you can use the API in a browser. As an example, we show how to view the list of projects in the SysML v2 repository. With the project number, you could then get the commits via the API and via the project and commit number, then the elements of the model.

So much for the 23rd door of our MBSE Podcast Advent Calendar. We wish you a great 23rd of December.

Der Beitrag Episode 19.23 – SysML v2 Requirement, Variants, and API erschien zuerst auf The MBSE Podcast.