Notebook

SysML v2 JupyterBook¶

This Jupyter Notebook is an exploration of SysML v2 from the user perspective. It shows some SysML v2 basics, but mainly focuses on the special features compared to SysML v1 and how they can be used. For a detailed introduction to the textual syntax of SysML v2, I recommend the following PDF: Introduction to the SysML v2 Language Textual Notation.

Please note: This is work in progress. You will see sketchy stuff. If you have any comments, contact me: tim@mbse4u.com.

Modeling with SysML v2 ¶

Introduction ¶

This section provides

a brief introduction of the modeling with SysML v2,
with a special focus on what is different compared to SysML v1.

It is not (yet) a complete SysML v2 tutorial. It uses the SysML v2 pilot implementation which is not intended as full modeling tool for industrial application.

Example and first steps ¶

The simple example system is the following electrical vehicle:

Electrical HSUV

Let's start with a logical architecture of the vehicle. A first major difference compared to SysML is that there is a textual syntax for SysML v2. The following cell shows the textual SysML v2 syntax of the logical architecture. The package statement defines the namespace of our architecture. The architecture itself is a simple hierarchical set of parts.

In [6]:

package eVehicle_LogicalArchitecture {
    part eVehicle {    
        part body;
        part battery;
        part engine;
        part frontAxis;
        part rearAxis;
        part frontWheel[2];
        part rearWheel[2];
    }
}

Out[6]:

Package eVehicle_LogicalArchitecture (5c3623ba-2bbf-43e1-b0e5-fbb7126d7d9b)

Run the cell above to create the real model. The text above is only the textual syntax of SysML v2. The show command provides a deep insight into the model structure:

In [85]:

%show eVehicle_LogicalArchitecture

Out[85]:

Package eVehicle_LogicalArchitecture (76692bb7-ae0c-4f26-9ff0-45cb083e7474)
  [Import] Package eVehicle_Definitions (13ab3067-79ba-4b36-b0ec-9a2455c43fb1)
  [Membership] PartUsage eVehicle (4b1f0203-ed9b-46e1-93a7-5c1d18f634b4)
    [Subsetting] PartUsage parts (210455cc-0a23-429e-9e49-95acce6c7873)
    [FeatureMembership] PartUsage body (024078d4-0770-4463-aae2-8e719418e84b)
      [Subsetting] PartUsage parts (210455cc-0a23-429e-9e49-95acce6c7873)
    [FeatureMembership] PartUsage battery (424c8834-3081-41bc-9c7b-50d742c262a1)
      [Subsetting] PartUsage parts (210455cc-0a23-429e-9e49-95acce6c7873)
    [FeatureMembership] PartUsage engine (d532d210-ecd4-42da-ae40-68efe9b00196)
      [Subsetting] PartUsage parts (210455cc-0a23-429e-9e49-95acce6c7873)
    [FeatureMembership] PartUsage frontAxis (88292f1b-8e8f-4257-91be-c5cc1bcc7f26)
      [Subsetting] PartUsage parts (210455cc-0a23-429e-9e49-95acce6c7873)
    [FeatureMembership] PartUsage rearAxis (0f8be90b-1c95-45e1-9c7d-fd696f36dc55)
      [Subsetting] PartUsage parts (210455cc-0a23-429e-9e49-95acce6c7873)
    [FeatureMembership] PartUsage frontWheel (544633d7-17af-4945-a964-e689e999e4e0)
      [FeatureTyping] PartDefinition Wheel (38f9638f-d02a-4839-a2e3-d75d1482c48d)
      [Subsetting] PartUsage parts (210455cc-0a23-429e-9e49-95acce6c7873)
      [FeatureMembership] MultiplicityRange (c2685a7f-07d6-42a4-b25b-f718a5b9bead)
        [Redefinition] MultiplicityRange (9492ec5c-54a6-476e-89ee-d6797ce5f96c)
        [FeatureMembership] LiteralInteger (daf6910f-4c14-4e74-b13b-6b99a89a6da1)
          [ReturnParameterMembership] Feature $result (5081c478-3632-4bdf-b1d7-1b16248e6ef6)
    [FeatureMembership] PartUsage rearWheel (28b858ea-f602-4d63-8614-696634c85db4)
      [FeatureTyping] PartDefinition Wheel (38f9638f-d02a-4839-a2e3-d75d1482c48d)
      [Subsetting] PartUsage parts (210455cc-0a23-429e-9e49-95acce6c7873)
      [FeatureMembership] MultiplicityRange (5a450f99-45cd-42f3-8592-8eb15558df96)
        [Redefinition] MultiplicityRange (9492ec5c-54a6-476e-89ee-d6797ce5f96c)
        [FeatureMembership] LiteralInteger (2180d5b9-d6dd-4a48-a2db-b7963c83e8d9)
          [ReturnParameterMembership] Feature $result (6edf8788-b982-4e0c-b827-d128bec28c3b)

More convenient for the common model user, of course, is the graphical notation presented after the execution of the following cell:

In [2]:

%viz --view=tree eVehicle_LogicalArchitecture

Out[2]:

The diagram is only a view, and not an editor. A graphical editor is not provided in the pilot implementation. Future SysML v2 modeling tools will certainly offer graphical editors.

Changes to SysML v1¶

SysML v2 is a complete new language with a different foundation than SysML v1. Therefore, there are plenty of differences. Here, I highlight only the changes that are most relevant to the modeler.

If I had modeled the eHSUV in SysML v1, I would have had to first define blocks and then part properties whose types are the blocks.

eVehicle in SysML v1

The following SysML v2 model describes the mapping of SysML v1 concepts to SysML v2 concepts. The formal transformation specification from SysML v1 to v2 is, of course, much more detailed. The following mapping is human-readable, but somewhat less precise. The current implementation of SysML v2 does not provide the allocate relationship yet, which I would like to use for the mapping. Instead, I use the dependency relationship. The mapping only describes the model elements I used so far. A complete mapping of all elements covered in this book are described in chapter Mapping from SysML v1 to SysML v2.

In [98]:

package SysMLv1ToSysMLv2MappingLibrary {
    part def SysMLModelElement;
}

package SysMLv1ToSysMLv2Mapping {
    
    import SysMLv1ToSysMLv2MappingLibrary::*;
    
    part SysMLv1 {
        part Block:SysMLModelElement;
        part Dependency:SysMLModelElement;
        part Package:SysMLModelElement;
        part PartProperty:SysMLModelElement;
    }
    
    part SysMLv2 {
        part Dependency:SysMLModelElement;
        part Package:SysMLModelElement;
        part Part:SysMLModelElement;
        part PartDefinition:SysMLModelElement;
    }
    
    // Mapping SysML v1 to SysML v2
    dependency from SysMLv1::Block to SysMLv2::PartDefinition;
    dependency from SysMLv1::Dependency to SysMLv2::Dependency;
    dependency from SysMLv1::Package to SysMLv2::Package;
    dependency from SysMLv1::PartProperty to SysMLv2::Part;
}

Out[98]:

Package SysMLv1ToSysMLv2MappingLibrary (4a1e975c-3fad-4ec6-888e-4f41f75f09a9)
Package SysMLv1ToSysMLv2Mapping (c82d16f0-73a9-48cc-94ff-89533503a62c)

In [68]:

%viz SysMLv1ToSysMLv2Mapping

Out[68]:

Parts and PartDefinitions ¶

In SysML v2, you can define parts without types. However, you could define types if you like. A type can be used to reuse definitions. I extend our example and add a property to the wheel to specify the size. The type of the attribute is Integer. I skip units for now. The textual syntax allows the keyword attribute or value. I prefer value.

In [49]:

package eVehicle_LogicalArchitecture {
    
    import ScalarValues::Integer;
    
    part eVehicle {    
        part body;
        part battery;
        part engine;
        part frontAxis;
        part rearAxis;
        part frontWheel[2] {
            value size : Integer;
        }
        part rearWheel[2] {
            value size : Integer;
        }
    }
}

Out[49]:

Package eVehicle_LogicalArchitecture (0a92252a-e270-4d19-aab7-b017bdfaf8a9)

Run the cell with the SysML v2 model, and visualize the model. If you also would like to see the model structure, execute the %show command.

In [14]:

%viz --view=tree eVehicle_LogicalArchitecture

Out[14]:

Although it is still very simple, the model already smells of reuse. The size attribute is currently defined twice. Now, we define a type respectively PartDefinition Wheel and specify that as the type of Parts.

In [1]:

package eVehicleDefinitions {

    import ScalarValues::Integer;   
    
    part def Wheel {
        value size : Integer;
    }
}

package eVehicle_LogicalArchitecture {

    import eVehicleDefinitions::*;
    
    part eVehicle {    
        part body;
        part battery;
        part engine;
        part frontAxis;
        part rearAxis;
        part frontWheel : Wheel[2];
        part rearWheel : Wheel[2];
    }
}

Out[1]:

Package eVehicleDefinitions (bf5b8d43-4f6c-47d1-8c41-b80b7978518a)
Package eVehicle_LogicalArchitecture (85567e94-df2b-4967-b589-11e10e914c50)

In [7]:

%viz --view=tree eVehicle_Definitions

Out[7]:

In [16]:

%viz --view=tree eVehicle_LogicalArchitecture

Out[16]:

The attribute size itself can also be defined and reused for several attribute usages. It is a common concept in SysML v2 to separate definition of elements and usage of elements. SysML v1 also follows this concept, but not as consequent as SysML v2. For example, SysML v1 does not provide a separate attribute definition.

The attribute definition is not mandatory and only partly useful in this example, because the size is only used at one place. But I added it anyhow as an example for attribute definitions. The keyword attribute can be omitted as for example in the definition of the size attribute. Alternatively, the keyword value can be used instead of attribute.

In [16]:

package eVehicle_Definitions {
   
    attribute def WheelSize {
        import ScalarValues::Integer;
        size : Integer;
    }
    
    part def Wheel {
        attribute sizeOfWheel : WheelSize;
    }
}

package eVehicle_LogicalArchitecture {   
    
    import eVehicle_Definitions::*;
    
    part eVehicle {    
        part body;
        part battery;
        part engine;
        part frontAxis;
        part rearAxis;
        part frontWheel : Wheel[2];
        part rearWheel : Wheel[2];
    }
}

Out[16]:

Package eVehicle_Definitions (d70a8a62-b9ee-48e4-ad83-0ddfbf74cd92)
Package eVehicle_LogicalArchitecture (dd4b3fad-565a-4770-9998-0c0a66335376)

In [19]:

%viz --view=tree eVehicle_Definitions

Out[19]:

In [18]:

%viz --view=tree eVehicle_LogicalArchitecture

Out[18]:

Putting the parts together ¶

By now the model only defines the breakdown structure of the vehicle. There is no definition yet of how the parts are connected. The next example model eVehicle_LogicalArchitecture connects the parts in a meaningful way.

In [18]:

package eVehicle_LogicalArchitecture {
       
    import eVehicleDefinitions::*;
    
    part eVehicle {    
        part body;
        part battery;
        part engine;
        part frontAxis;
        part rearAxis;
        part frontWheel : Wheel[2];
        part rearWheel : Wheel[2];
        
        connect battery to engine;
        connect engine to frontAxis;
        connect frontAxis to frontWheel;
        connect rearAxis to rearWheel;
        connect body to battery;
        connect body to engine;
        connect body to frontAxis;
        connect body to rearAxis;
    }
}

Out[18]:

Package eVehicle_LogicalArchitecture (d9e0e944-5b16-4067-9987-b819e369c4a7)

In [23]:

%viz --view=interconnection eVehicle_LogicalArchitecture::eVehicle

Out[23]:

Modeling interfaces ¶

The interaction points are defined by ports in SysML v2, similar to SysML v1. The following extended example defines the interaction points between the engine and the battery. The connection is changed to connect the ports instead of the parts.

In [19]:

package eVehicle_LogicalArchitecture {
       
    import eVehicleDefinitions::*;
    
    part eVehicle {    
        part body;
        part battery {
            port powerOut;
        }
        part engine {
            port powerIn;
        }
        part frontAxis;
        part rearAxis;
        part frontWheel : Wheel[2];
        part rearWheel : Wheel[2];
        
        connect battery::powerOut to engine::powerIn;
        connect engine to frontAxis;
        connect frontAxis to frontWheel;
        connect rearAxis to rearWheel;
        connect body to battery;
        connect body to engine;
        connect body to frontAxis;
        connect body to rearAxis;
    }
}

Out[19]:

Package eVehicle_LogicalArchitecture (ff608f69-3f82-4b20-bf6f-e92cbc7dea68)

In [28]:

%viz --view=interconnection eVehicle_LogicalArchitecture::eVehicle

Out[28]:

The ports powerIn and powerOut have no types respectively the SysML v2 library element Port as default type. The consistent usage/definition pattern applies here as well. The port is a usage. With a PortDef the interaction point can be defined. In this example it is a good candidate for a model library.

The port only specifies the interaction point. The interface defines the connection between interaction points. The PowerOutPort is conjugated for the consumerPort port.

In [11]:

package eVehicleLibrary {
    
    import ScalarValues::Integer;
    
    attribute def ElectricEnergy;
    
    port def PowerOutPort {
        out energy : ElectricEnergy;
    }
    
    interface def PowerInterface {
        end supplierPort : PowerOutPort;
        end consumerPort : ~PowerOutPort;
    }
}

Out[11]:

Package eVehicleLibrary (51306574-6576-4a15-b56c-b00db80676de)

In [3]:

%viz --view=tree eVehicleLibrary

Out[3]:

Next, the definitions of the port and the interface are applied to the model. Do not forget to run the eVehicle_Definitions and eVehicleLibrary in section Libraries for the eVehicle example.

In [20]:

package eVehicle_LogicalArchitecture {
       
    import eVehicleDefinitions::*;
    import eVehicleLibrary::*;
    
    part eVehicle {    
        part body;
        part battery {
            attribute capacity : BatteryCapacity;
            port powerOut : PowerOutPort;
        }
        part engine {
            port powerIn : ~PowerOutPort;
        }
        part frontAxis;
        part rearAxis;
        part frontWheel : Wheel[2];
        part rearWheel : Wheel[2];
        
        interface : PowerInterface connect 
            supplierPort => battery::powerOut to 
            consumerPort => engine::powerIn;
        connect engine to frontAxis;
        connect frontAxis to frontWheel;
        connect rearAxis to rearWheel;
        connect body to battery;
        connect body to engine;
        connect body to frontAxis;
        connect body to rearAxis;
    }
}

Out[20]:

Package eVehicle_LogicalArchitecture (9c26478f-36cf-409c-ba7d-05d3c264c6e5)

In [94]:

%viz --view=interconnection eVehicle_LogicalArchitecture::eVehicle

Out[94]:

Modeling variants ¶

SysML v2 provides model elements for variants. This is a new feature compared to SysML v2. Following the typical approach of SysML, these are only generic concepts, but they form the foundation for tools to provide functions for them and for language extensions to be defined.

The electrical vehicle model is extended with different types of batteries and engines. First, we extend the eVehicleDefinitions and eVehicleLibrary, and define a part definition for the battery. The complete library can be found in section Libraries for the eVehicle example.

In [1]:

package eVehicleLibrary {
    
    import ScalarValues::Integer;
    
    attribute def ElectricEnergy;
    attribute def BatteryCapacity :> ScalarValues::Integer;
    
    port def PowerOutPort {
        out energy : ElectricEnergy;
    }
    
    interface def PowerInterface {
        end supplierPort : PowerOutPort;
        end consumerPort : ~PowerOutPort;
    }
}

package eVehicleDefinitions {

    import eVehicleLibrary::*;   
    
    part def Wheel {
        value size : Integer;
    }
    
    part def Battery {
        value capacity : BatteryCapacity;
    }
    
    part def Engine;
}

Out[1]:

Package eVehicleLibrary (8756a65a-a48f-4b80-91a6-43a04906f4fb)
Package eVehicleDefinitions (1dcfeb37-79d5-4fc7-8992-8c27890cd5a2)

The new part definition of the Battery is now used in the eVehicle architecture.

In [68]:

package eVehicle_LogicalArchitecture {
    
    import eVehicleDefinitions::*;
    import eVehicleLibrary::*;
    
    part eVehicle {    
        value maxSpeed :Speed = 142;
        part body;
        part battery : Battery {
            value redefines capacity = 42;
            port powerOut : PowerOutPort;
        }
        part engine : Engine {
            port powerIn : ~PowerOutPort;
        }
        part frontAxis;
        part rearAxis;
        part frontWheel : Wheel[2];
        part rearWheel : Wheel[2];
        
        interface : PowerInterface connect 
            supplierPort => battery::powerOut to 
            consumerPort => engine::powerIn;
        connect engine to frontAxis;
        connect frontAxis to frontWheel;
        connect rearAxis to rearWheel;
        connect body to battery;
        connect body to engine;
        connect body to frontAxis;
        connect body to rearAxis;
    }
}

Out[68]:

Package eVehicle_LogicalArchitecture (018276f1-ac3b-4f10-8e86-ee4ca277ed3e)

In [71]:

%viz eVehicle_LogicalArchitecture

Out[71]:

Now, the model is prepared to add variability. We define two battery kinds with different capacities, and two engine kinds.

In [53]:

package eVehicle_VariantModel {
    
    import eVehicle_LogicalArchitecture::*;
    
    
    package eVehicle_Configurations {

        import eVehicle_Variations::*;
        
        part eVehicleStandard :> eVehicleVariations {
            part redefines engine :> standardEngine;
            part redefines battery :> batteryLow;
        }
        part eVehiclePremium :> eVehicleVariations {
            part redefines engine :> powerEngine;
            part redefines battery :> batteryHigh;
        }
        part INVALIDeVehicle :> eVehicleVariations {
            part redefines engine :> powerEngine;
            part redefines battery :> batteryLow;
        }
    }
    
    package eVehicle_Variations {
        
        import eVehicle_Variants::*;
        
        abstract part eVehicleVariations :> eVehicle {
        
            variation part redefines battery : Battery {
                variant part batterLow;
                variant part batteryHigh;  
            }
            variation part redefines engine : Engine {
                variant part standardEngine;
                variant part powerEngine;
            }
        
            abstract constraint { (battery == batteryLow & engine == standardEngine) ^ (battery == batteryHigh) }
        }
    }   
    
    package eVehicle_Variants {
        
        part batteryLow : Battery {
            value redefines capacity = 40;
        }
        part batteryHigh : Battery {
            value redefines capacity = 40;
        }
    
        part powerEngine : Engine;
        part standardEngine : Engine;
    }
}

Out[53]:

Package eVehicle_VariantModel (676ce442-82a2-4473-ac7f-d50fe825fd71)

In [91]:

%viz --view=tree eVehicle_VariantModel::eVehicle_Variations::eVehicleVariations

Out[91]:

In [84]:

%viz --view=tree eVehicle_VariantModel::eVehicle_Configurations

Out[84]:

Avoiding the "variability model explosion"¶

When modeling variability with SysML v1, the model can easily explode, i.e., a small variability can lead to the need to model many model elements. I change a bit the structure of the vehicle, for example, I define the wheels as parts of the axis. I also remove the part definition Wheel and define a some lug bolts of the wheels. Finally, we have a deep nested structure: eVehicle owns axis owns wheel owns lug bolt.

In [30]:

package eVehicle_LogicalArchitecture_ExplosionExample {
    
    import eVehicleDefinitions::*;
    import eVehicleLibrary::*;
    
    part eVehicle {    
        part engine : Engine;

        part frontAxis {
            part frontWheel[2] {
                part lugBolt[6];
                part boltCircle;
                connect boltCircle to lugBolt;
            }
            part housing;            
            connect housing to frontWheel;
        }
        
        part rearAxis {
            part rearWheel[2] {
                part lugBolt[6];
                part boltCircle;
                connect boltCircle to lugBolt;
            }
            part housing;            
            connect housing to rearWheel;
        }       
        connect engine to frontAxis;
    }
}

Out[30]:

Package eVehicle_LogicalArchitecture_ExplosionExample (6e11aba2-e881-4e07-a6c9-e206039f7ace)

In [35]:

%viz --view=interconnection eVehicle_LogicalArchitecture

Out[35]:

The structure eVehicle/axis/wheel/lugBolt can easily be modeled with SysML v1. It is slightly different in that in SysML v1 we have to use types, i.e. blocks, and cannot model parts directly.

SysML v1 eVehicle Model

Now, if we introduce variants of lug bolts, this variance ripples up through the entire structure:

SysML v1 eVehicle Model - Variability explosion

In SysML v2 it looks like this:

In [31]:

package eVehicleVariants_ExplosionExample {
    part lugBolt42;
    part lugBolt23;
}

package eVehicle_LogicalArchitecture_ExplosionExample {
    
    import eVehicleDefinitions::*;
    import eVehicleLibrary::*;
    import eVehicleVariants_ExplosionExample::*;
        
    part eVehicle {    
        part engine : Engine;

        part frontAxis {
            part frontWheel[2] {
                /*-----------------------------
                 * Definition of the variation
                 * ----------------------------*/
                variation part lugBolt[6] {
                    variant part lugBolt23;
                    variant part lugBolt42;  
                }
                part boltCircle;
                connect boltCircle to lugBolt;
            }
            part housing;            
            connect housing to frontWheel;
        }
        
        part rearAxis {
            part rearWheel[2] {
                part lugBolt[6];
                part boltCircle;
                connect boltCircle to lugBolt;
            }
            part housing;    
            connect housing to rearWheel;
        }        
        connect engine to frontAxis;
    }
}

Out[31]:

Package eVehicleVariants_ExplosionExample (17bc5747-f80e-4aa2-ae99-0b3ed8af6e25)
Package eVehicle_LogicalArchitecture_ExplosionExample (f334f542-ef0d-4c12-bf94-6775c86799d5)

In [41]:

%viz --view=tree eVehicle_LogicalArchitecture

Out[41]:

A concrete variant configuration of the eVehicle with lug bolts 42 can be simply created by specialization:

In [32]:

package eVehicle_Edition42 {
    
    import eVehicle_LogicalArchitecture_ExplosionExample::*;
           
    part eVehicle42 :> eVehicle {
       part redefines lugBolt42 :> frontAxis::frontWheel::lugBolt;
    }
}

Out[32]:

Package eVehicle_Edition42 (32530ac1-177d-4b73-a122-921ed3bf232c)

Modeling requirements ¶

A requirement definition is a special kind of a constraint definition including parameters and required constraints.

Do not forget to run the eVehicle_Definitions and eVehicleLibrary in section Libraries for the eVehicle example.

In [11]:

package eVehicleRequirementDefinitions {
    
    import eVehicleDefinitions::*;
    
    requirement def BatteryCapacityReqDef {
        doc /* The actual battery capacity shall be greater than or equal
             * to the required capacity. */

            attribute capacityActual : BatteryCapacity;
            attribute capacityRequired : BatteryCapacity;
        
            require constraint{ capacityActual <= capacityRequired }
    }
    
    requirement def MaxSpeedReqDef {
        doc /* The maximum speed of the vehicle shall be 
             * not greater than the required maximum speed. */
            
            attribute maxSpeedVehicle : Speed;
            attribute maxSpeedRequired : Speed;
        
            require constraint{ maxSpeedVehicle <= maxSpeedRequired }
    }
    
}

Out[11]:

Package eVehicleRequirementDefinitions (8be10a06-3d86-4205-9079-d9ddd7d04e4e)

In [12]:

%viz eVehicleRequirementDefinitions

Out[12]:

The definition of a requirement provides a reusable structure. Next, the requirement definition BatteryCapacityRequirementDef is used to specify a concrete requirement for the eVehicle. The requirement REQ.B.1 redefines the requirement attribute capacityRequired with a concrete value.

It is possible to define requirement groups to manage a large set of requirements by defining that a requirement requires other requirements.

Do not forget to run the eVehicle_VariantModel above before you run this model.

In [40]:

%viz eVehicle_LogicalArchitecture::eVehicle

Out[40]:

In [71]:

package eVehicleRequirements {
    
    import eVehicleRequirementDefinitions::*;
    import eVehicle_LogicalArchitecture::*;
    
    requirement eVehicleSpecification {
        doc /* Requirement Specification of the eVehicle  */
        subject eVehicle :>> eVehicle;
        require eVehicleBatteryCapacity;
        require eVehicleMaxSpeed;
    }
    
    requirement id 'REQ.B.1' eVehicleBatteryCapacity : BatteryCapacityReqDef {
        subject eVehicle :>> eVehicle;
        attribute :>> capacityRequired = 50;
        attribute :>> capacityActual = eVehicle::battery::capacity;
    }
    
    requirement id 'REQ.V.1' eVehicleMaxSpeed : MaxSpeedReqDef {
        subject eVehicle :>> eVehicle;
        attribute :>> maxSpeedRequired = 140;
        attribute :>> maxSpeedVehicle = eVehicle::maxSpeed;
    }
}

Out[71]:

Package eVehicleRequirements (b8416c8b-39cc-4136-a156-ff81f4d31e3c)

In [72]:

%viz eVehicleRequirements

Out[72]:

Finally, we model that the eVehicle satisfies the requirement.

In [83]:

package eVehicle_LogicalArchitecture {
    
    import eVehicleDefinitions::*;
    import eVehicleLibrary::*;
    import eVehicleRequirements::*;
    
    part eVehicleContext {
    
       part eVehicle {    
          value maxSpeed :Speed = 142;
          part body;
          part battery : Battery {
              value redefines capacity = 42;
              port powerOut : PowerOutPort;
          }
          part engine : Engine {
              port powerIn : ~PowerOutPort;
          }
          part frontAxis;
          part rearAxis;
          part frontWheel : Wheel[2];
          part rearWheel : Wheel[2];
        
          interface : PowerInterface connect 
            supplierPort => battery::powerOut to 
            consumerPort => engine::powerIn;
          connect engine to frontAxis;
          connect frontAxis to frontWheel;
          connect rearAxis to rearWheel;
          connect body to battery;
          connect body to engine;
          connect body to frontAxis;
          connect body to rearAxis;
      }
      satisfy eVehicleSpecification by eVehicle;
    }
}

Out[83]:

Package eVehicle_LogicalArchitecture (dff6e5c3-b1ce-4dec-b6d1-7dfe983a7684)

Mapping from SysML v1 to SysML v2 ¶

The following SysML v2 model describes the mapping of SysML v1 concepts to SysML v2 concepts. The formal transformation specification from SysML v1 to SysML v2 is, of course, much more detailed. The following mapping is human-readable, but somewhat less precise. The current implementation of SysML v2 does not provide the allocate relationship yet, which I would like to use for the mapping. Instead, I use the dependency relationship. The mapping only describes the model elements used in this book.

In [57]:

package SysMLv1ToSysMLv2MappingLibrary {
    part def SysMLModelElement;
}

package SysMLv1ToSysMLv2Mapping {
    doc /* Mapping of SysML v1 model elements to SysML v2 */
    
    import SysMLv1ToSysMLv2MappingLibrary::*;
    
    part SysMLv1 {
        part AssociationBlock:SysMLModelElement;
        part Block:SysMLModelElement;
        part Connector:SysMLModelElement;
        part Dependency:SysMLModelElement;
        part 'Import':SysMLModelElement;
        part Package:SysMLModelElement;
        part PartProperty:SysMLModelElement;
        part Port:SysMLModelElement;
        part Requirement:SysMLModelElement;
        part ValueProperty:SysMLModelElement;
    }
    
    part SysMLv2 {
        part Attribute:SysMLModelElement;
        part Connection:SysMLModelElement;
        part Dependency:SysMLModelElement;
        part 'Import':SysMLModelElement;
        part InterfaceDefinition:SysMLModelElement;
        part Package:SysMLModelElement;
        part Part:SysMLModelElement;
        part PartDefinition:SysMLModelElement;
        part Port:SysMLModelElement;
        part RequirementDefinition:SysMLModelElement;
        part 'Variant':SysMLModelElement;
        part 'Variation':SysMLModelElement;
    }
    
    // Mapping SysML v1 to SysML v2
    dependency from SysMLv1::AssociationBlock to SysMLv2::InterfaceDefinition;
    dependency from SysMLv1::Block to SysMLv2::PartDefinition;
    dependency from SysMLv1::Connector to SysMLv2::Connection;
    dependency from SysMLv1::Dependency to SysMLv2::Dependency;
    dependency from SysMLv1::'Import' to SysMLv2::'Import';
    dependency from SysMLv1::Package to SysMLv2::Package;
    dependency from SysMLv1::PartProperty to SysMLv2::Part;
    dependency from SysMLv1::Port to SysMLv2::Port;
    dependency from SysMLv1::Requirement to SysMLv2::RequirementDefinition;
    dependency from SysMLv1::ValueProperty to SysMLv2::Attribute;
}

Out[57]:

Package SysMLv1ToSysMLv2MappingLibrary (ddf8e43f-fb4f-4710-ba94-a488341f4700)
Package SysMLv1ToSysMLv2Mapping (f42acfd8-8b54-44e2-96ff-901d083374c3)

In [58]:

%viz --view=interconnection SysMLv1ToSysMLv2Mapping

Out[58]:

Libraries for the eVehicle example ¶

This section contains the complete libraries used in the examples of this chapter. You must run them to execute the examples.

In [10]:

package eVehicleLibrary {
        
    attribute def ElectricEnergy;
    attribute def BatteryCapacity :> ScalarValues::Integer;
    attribute def Speed :> ScalarValues::Integer;
    
    port def PowerOutPort {
        out energy : ElectricEnergy;
    }
    
    interface def PowerInterface {
        end supplierPort : PowerOutPort;
        end consumerPort : ~PowerOutPort;
    }
}

package eVehicleDefinitions {

    import eVehicleLibrary::*;   
    
    part def Wheel {
        value size : ScalarValues::Integer;
    }
    
    part def Battery {
        value capacity : BatteryCapacity;
    }
    
    part def Engine;
}

Out[10]:

Package eVehicleLibrary (d19e9f8e-6380-44ea-be6d-8a4e489f7449)
Package eVehicleDefinitions (611d2dfe-6a2b-4e7f-9fad-8e6d89f859dc)

In [5]:

%viz eVehicleLibrary

Out[5]:

In [4]:

%viz eVehicleDefinitions

Out[4]:

SysML v2 MBSE Methodologies JupyterBook ¶

This chapter covers the impact of SysML v2 on MBSE methodologies.

Which methods continue to work well and which would need to be adapted? Theoretically, the methodologies have been developed independently of the SysML language, but definitely with a focus on SysML v1.

New features of SysML v2 can also lead to new methods in the methodologies.

SYSMOD with SysML v2 ¶

The example is taken from the book SYSMOD - The Systems Modeling Toolbox. It is a Forest Fire Detection System (FFDS).

System Idea and System Objectives ¶

The language extension of SysML v2 is still under development. Until it is available, I use a simplified approach to introduce SYSMOD concepts into the language.

The following SysML v2 code defines the SYSMOD concepts of a system and an objective. They are applied to define the forest fire detection system element including the problem statement and the system idea, and the three system objectives. The complete definition of SYSMOD is described in chapter SYSMOD Language Library.

In [5]:

package SYSMOD {

    doc /* SYSMOD - The Systems Modeling Toolbox, Version 5.0beta */
        
    requirement def Objective {
        doc /* A objective is an objective of the system. It is a special kind of a requirement that is typically not satisfied but amplified by the system. */
    }
    
    part def System {
        doc /* Marks the system under development. Typically there is only one block in the model with that stereotype. However in a System of Systems (SoS) model there could be more. */
        import ScalarValues::String;
        value problemStatement : String;
        value systemIdea : String;
    }
}

Out[5]:

Package SYSMOD (05ab296a-3725-4287-99a8-99cde1755d83)

In [3]:

%viz SYSMOD

Out[3]:

In [6]:

package ForestFireDetectionSystemModel {
    
    import SYSMOD::*;
    
    package FFDS_Core {
    
        part FFDS : System {
            value redefines problemStatement = "How can we provide a forest fire detection system for forest authorities that can be scaled to any forest size, is affordable, highly reliable and accurate in detecting forest fires.";
            value redefines systemIdea = "The FFDS is a satellite-based system to detect forest fires in very large areas. The system is also equipped with stationary sensors and animal sensors. Using different sources for the fire detection increases the reliability of the system and enables different system configurations for different environmental contexts and price segments. Main features of the FFDS are Detecting and reporting forest fires on time Monitoring forest and fires Uses the behavior of forest animals to detect fires";
        }
        
        package FFDS_Requirements {
            package FFDS_Objectives {
                requirement id 'OBJ-B1' 'Market Leader' : Objective {
                    doc /* The system will make the vendor the market leader for forest fire detection systems. */
                }
                requirement id 'OBJ-S1' 'Reliable Detection' : Objective {
                    doc /* Any forest fire is detected by the system on time to start effective counteractions. */
                }
                requirement id 'OBJ-S2' 'Affordability' : Objective {
                    doc /* The system is affordable for any forest authority. */
                }                               
            }
        }
    }
}

Out[6]:

Package ForestFireDetectionSystemModel (0f6b62b1-0ccc-46be-96be-9e2db42c5e00)

In [7]:

%viz ForestFireDetectionSystemModel

Out[7]:

System Context ¶

The concepts of use cases and actors are not yet defined in SysML v2. Therefore, the external entities of the system are defined as parts of the context. You must execute the SYSMOD library in chapter SYSMOD Language Library before executing the following cell.

In [11]:

package ForestFireDetectionSystemModel {
    
    import SYSMOD::*;
    
    package FFDS_Core {
    
       part 'FFDS System Context' : SystemContext {
          part FFDS : System :> systemOfInterest {            
            value redefines problemStatement = "How can we provide a forest fire detection system for forest authorities that can be scaled to any forest size, is affordable, highly reliable and accurate in detecting forest fires.";
            value redefines systemIdea = "The FFDS is a satellite-based system to detect forest fires in very large areas. The system is also equipped with stationary sensors and animal sensors. Using different sources for the fire detection increases the reliability of the system and enables different system configurations for different environmental contexts and price segments. Main features of the FFDS are Detecting and reporting forest fires on time Monitoring forest and fires Uses the behavior of forest animals to detect fires";
          }
          part Operator : User subsets actors;
          part Administrator : User subsets actors;
          part 'Forest Ranger' : User subsets actors;
          part Maintenance : User subsets actors;
          part 'Fire Department' : ExternalSystem subsets actors;
          part 'Meteorology data system' : ExternalSystem subsets actors;
          part 'Research analysis system' : ExternalSystem subsets actors;
          part 'Weather' : EnvironmentalEffect subsets actors;
          part 'Fire' : EnvironmentalEffect subsets actors;
          part 'Planet Environment' : EnvironmentalImpact subsets actors;          
       }                
    
       package FFDS_Requirements {
          package FFDS_Objectives {
             requirement id 'OBJ-B1' 'Market Leader' : Objective {
                  doc /* The system will make the vendor the market leader for forest fire detection systems. */
             }
             requirement id 'OBJ-S1' 'Reliable Detection' : Objective {
                  doc /* Any forest fire is detected by the system on time to start effective counteractions. */
             }
             requirement id 'OBJ-S2' 'Affordability' : Objective {
                  doc /* The system is affordable for any forest authority. */
             }                               
         }
      }
   }
}

Out[11]:

Package ForestFireDetectionSystemModel (bf2420d2-8028-4da6-bd97-00469c680382)

In [10]:

%viz ForestFireDetectionSystemModel

Out[10]:

System Use Cases¶

Use Case Activities¶

Domain Model¶

Quality Requirements¶

Logical Architecture¶

Product Architecture¶

System States¶

Verify Architecture with Scenarios¶

Test Cases¶

SYSMOD Language Library ¶

In [1]:

package SYSMOD {

    doc /* SYSMOD - The Systems Modeling Toolbox, Version 5.0beta */
        
    requirement def Objective {
        doc /* A objective is an objective of the system. It is a special kind of a requirement that is typically not satisfied but amplified by the system. */
    }
    
    part def System {
        doc /* Marks the system under development. Typically there is only one block in the model with that stereotype. However in a System of Systems (SoS) model there could be more. */
        import ScalarValues::String;
        value problemStatement : String;
        value systemIdea : String;
    }
    
    part def SystemContext {
        doc /* A system context is a wrapper around the system and it's actors to allow a detailed system context modeling. The system context references the appropriate system. This is important in a SoS model. */
            
        part systemOfInterest : System;
        part actors[0..*];        
    }
    
    part def User;
    part def ExternalSystem;
    part def EnvironmentalEffect;
    part def EnvironmentalImpact;
}

Out[1]:

Package SYSMOD (66d2be83-519e-496c-b6f8-cabb4d6228ca)

In [10]:

%viz SYSMOD

Out[10]:

FAS with SysML v2 ¶

The example is taken from the tutorial of the FAS plugin for MagicDraw: http://sourceforge.net/projects/fas4md/files/FAS_plugin_tutorial.pdf/download.

In [2]:

package TheFASJukeBox {
    
    package FASLanguage {
        part def FunctionalBlock;
    }
    
    package UseCases {
        activity '(Un)install and Move Jukebox';
        activity 'Ask for Track to Play';
        activity 'Assemble Music Collection';
        activity 'Connect Jukebox with Electrical Supply';
        activity 'Disconnect from Electrical Supply';
        activity 'Distribute Energy';
        activity 'Get Energy';
        activity 'Get Mechanical Energy';
        activity 'Get Money';
        activity 'Insert Cash';
        activity 'Install Jukebox';
        activity 'Listen to Music';
        activity 'Make Music Available';
        activity 'Monitor Payment';
        activity 'Play Music Track';
        activity 'Produce Sound';
        activity 'Provide Music Track';
        activity 'Retrieve Identification of Music Track';
        activity 'Retrieve Money';
        activity 'Supply Jukebox with Energy';
        activity 'Transform Mechanical Engery into Something Harmless';
        activity 'Uninstall Jukebox';
        activity 'Use Means of Music Transfer to Retrieve Music';
    }
    
    package DomainKnowledge {
        item def AudioSignal;
        item def ClearanceToPlayMusic;
        item def ElectricalEnergy;
        item def IdentificationOfMusicTrack;
        item def MechanicalEnergy;
        item def Money;
        item def MusicTrack;
    }

    package FunctionalArchitecture {
        
        import UseCases::*;
        import DomainKnowledge::*;
        import FASLanguage::*;
        import SYSMOD::*;
        
        package FunctionalInterfaces {

            port def AudioSignalPort {
                out item a : AudioSignal;
            }
            port def ClearanceToPlayMusicPort {
                out item m : ClearanceToPlayMusic;
            }
            port def ElectricalEnergyPort {
                out item e : ElectricalEnergy;
            }
            port def IdentificationOfMusicTrackPort {
                out item m : IdentificationOfMusicTrack;
            }
            port def MechanicalEnergyPort {
                out item m : MechanicalEnergy;
            }
            port def MoneyPort {
                out item m : Money;
            }
            port def MusicTrackPort {
                out item m : MusicTrack;
            }
        }

        part TheFASJukeBoxFunctionalContext {
            
            import FunctionalInterfaces::*;
            
            part TheFASJukeBoxFunctionalArchitecture {

                dependency from TheFASJukeBoxFunctionalArchitecture to '(Un)install and Move Jukebox';
                dependency from TheFASJukeBoxFunctionalArchitecture to 'Assemble Music Collection';
                dependency from TheFASJukeBoxFunctionalArchitecture to 'Listen to Music';
                dependency from TheFASJukeBoxFunctionalArchitecture to 'Supply Jukebox with Energy';

                part 'I/O Customer' : FunctionalBlock {
                    dependency from 'I/O Customer' to 'Ask for Track to Play';
                    dependency from 'I/O Customer' to 'Get Money';
                    dependency from 'I/O Customer' to 'Produce Sound';
                    
                    port p1 : MoneyPort;
                    port p2 : ~AudioSignalPort;
                    port p3 : IdentificationOfMusicTrackPort;
                }
                part 'I/O Electrical Supply' : FunctionalBlock {
                    dependency from 'I/O Electrical Supply' to 'Get Energy';
                    
                    port p1 : ElectricalEnergyPort;
                }
                part 'I/O Music Supplier' : FunctionalBlock {
                    dependency from 'I/O Music Supplier' to 'Use Means of Music Transfer to Retrieve Music';
                    
                    port p1 : MusicTrackPort;
                }
                part 'I/O Pub Interior' : FunctionalBlock {
                    dependency from 'I/O Pub Interior' to 'Get Mechanical Energy';
                    
                    port p1 : MechanicalEnergyPort;
                }
                part 'I/O Pub Manager' : FunctionalBlock {
                    dependency from 'I/O Pub Manager' to 'Connect Jukebox with Electrical Supply';
                    dependency from 'I/O Pub Manager' to 'Disconnect from Electrical Supply';
                    dependency from 'I/O Pub Manager' to 'Insert Cash';
                    dependency from 'I/O Pub Manager' to 'Retrieve Identification of Music Track';

                    port p1 : IdentificationOfMusicTrackPort;
                }
                part Accounting : FunctionalBlock {
                    dependency from Accounting to 'Monitor Payment';
                    
                    port p1 : ClearanceToPlayMusicPort;
                    port p2 : ~MoneyPort;
                }
                part 'Energy Distribution' : FunctionalBlock {
                    dependency from 'Energy Distribution' to 'Distribute Energy';
                    
                    port p1 : ~ElectricalEnergyPort;
                }
                part 'Music Player' : FunctionalBlock {
                    dependency from 'Music Player' to 'Play Music Track';
                    
                    port p1 : AudioSignalPort;
                }
                part 'Music Storage' : FunctionalBlock {
                    dependency from 'Music Storage' to 'Make Music Available';
                    dependency from 'Music Storage' to 'Provide Music Track';

                    port p1 : ~IdentificationOfMusicTrackPort;
                    port p2 : ~MusicTrackPort;
                    port p3 : ClearanceToPlayMusicPort;
                }
                part Suspension : FunctionalBlock {
                    dependency from Suspension to 'Uninstall Jukebox';
                    
                    port p1 : ~MechanicalEnergyPort;
                }

                connect 'I/O Pub Manager'::p1 to 'Music Storage'::p1;
                connect 'I/O Pub Manager' to 'Accounting';
                connect 'I/O Music Supplier'::p1 to 'Music Storage'::p2;
                connect 'Accounting'::p1 to 'Music Storage'::p3;
                connect 'I/O Customer'::p1 to Accounting::p2;
                connect 'Music Player'::p1 to 'I/O Customer'::p2;
                connect 'I/O Customer'::p3 to 'Music Storage'::p1;
                connect 'I/O Electrical Supply'::p1 to 'Energy Distribution'::p1;
                connect 'I/O Pub Interior'::p1 to Suspension::p1;
            }

            part Customer : User;
            part 'Pub Manager' : User;
            part 'Music Supplier' : ExternalSystem;
            part 'Electrical Supply' : ExternalSystem;
            part 'Pub Interior' : ExternalSystem;
            
            connect 'Pub Manager' to TheFASJukeBoxFunctionalArchitecture::'I/O Pub Manager';
            connect 'Music Supplier' to TheFASJukeBoxFunctionalArchitecture::'I/O Music Supplier';
            connect Customer to TheFASJukeBoxFunctionalArchitecture::'I/O Customer';
            connect 'Electrical Supply' to TheFASJukeBoxFunctionalArchitecture::'I/O Electrical Supply';
            connect 'Pub Interior' to TheFASJukeBoxFunctionalArchitecture::'I/O Pub Interior';
        }
    }   
}

Out[2]:

Package TheFASJukeBox (c7fafbbd-172c-407c-9fb0-82b40b0b5342)

In [3]:

%viz --view=tree TheFASJukeBox

Out[3]:

In [4]:

%viz --view=interconnection TheFASJukeBox::FunctionalArchitecture::TheFASJukeBoxFunctionalContext

Out[4]:

VAMOS (Variant Modeling with SysML)¶

SysML v2 JupyterBook¶

Table of Contents¶

Modeling with SysML v2¶

Introduction¶

Example and first steps¶

Changes to SysML v1¶

Parts and PartDefinitions¶

Putting the parts together¶

Modeling interfaces¶

Modeling variants¶

Avoiding the "variability model explosion"¶

Modeling requirements¶

Mapping from SysML v1 to SysML v2¶

Libraries for the eVehicle example¶

SysML v2 MBSE Methodologies JupyterBook¶

SYSMOD with SysML v2¶

System Idea and System Objectives¶

System Context¶

System Use Cases¶

Use Case Activities¶

Domain Model¶

Quality Requirements¶

Logical Architecture¶

Product Architecture¶

System States¶

Verify Architecture with Scenarios¶

Test Cases¶

SYSMOD Language Library¶

FAS with SysML v2¶

VAMOS (Variant Modeling with SysML)¶

Modeling with SysML v2 ¶

Introduction ¶

Example and first steps ¶

Parts and PartDefinitions ¶

Putting the parts together ¶

Modeling interfaces ¶

Modeling variants ¶

Modeling requirements ¶

Mapping from SysML v1 to SysML v2 ¶

Libraries for the eVehicle example ¶

SysML v2 MBSE Methodologies JupyterBook ¶

SYSMOD with SysML v2 ¶

System Idea and System Objectives ¶

System Context ¶

SYSMOD Language Library ¶

FAS with SysML v2 ¶