SysML v2 JupyterBook

Last update: July 31st, 2021

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: [email protected].

Table of Contents

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 the architecture. The eVehicle architecture itself is a simple 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]:
eVehicle_LogicalArchitecture«part»eVehicle: Part«part»body: Part«part»battery: Part«part»engine: Part«part»frontAxis: Part«part»rearAxis: Part«part»frontWheel: Part«part»rearWheel: Part22

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 eVehicle in SysML v1, I would have had to first define blocks and then part properties whose types are the blocks.

eVehicle in SysML v1

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]:
eVehicle_LogicalArchitecture«dataType»Integer«part»eVehicle: Part«part»body: Part«part»battery: Part«part»engine: Part«part»frontAxis: Part«part»rearAxis: Part«part»frontWheel: Partsize: Integer«part»rearWheel: Partsize: Integer22

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]:
eVehicle_Definitions«dataType»Integer«part def»Wheelsize: Integer
In [16]:
%viz --view=tree eVehicle_LogicalArchitecture
Out[16]:
eVehicle_LogicalArchitecture«part»eVehicle: Part«part»body: Part«part»battery: Part«part»engine: Part«part»frontAxis: Part«part»rearAxis: Part«part»frontWheel: Wheel«part»rearWheel: Wheel22

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]:
eVehicle_Definitions«attribute def»WheelSizesize: Integer«dataType»Integer«part def»Wheelsize: WheelSize
In [18]:
%viz --view=tree eVehicle_LogicalArchitecture
Out[18]:
eVehicle_LogicalArchitecture«part»eVehicle: Part«part»body: Part«part»battery: Part«part»engine: Part«part»frontAxis: Part«part»rearAxis: Part«part»frontWheel: Wheel«part»rearWheel: Wheel22

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]:
eVehicle: Partbody: Partbattery: Partengine: PartfrontAxis: PartrearAxis: PartfrontWheel: WheelrearWheel: Wheel

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]:
eVehicle: Partbattery: Partengine: Partbody: PartpowerOut: PortpowerIn: PortfrontAxis: PartrearAxis: PartfrontWheel: WheelrearWheel: Wheel

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]:
eVehicleLibrary«dataType»Integer«attribute def»ElectricEnergy«attribute def»Capacity«port def»PowerOutPortenergy: ElectricEnergy«interface def»PowerInterfaceconsumerPort: ~PowerOutPort:>>Interface::targetsupplierPort: PowerOutPort:>>Interface::sourceports

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]:
eVehicle: Partbattery: Partengine: Partbody: PartpowerOut: PowerOutPortpowerIn: ~PowerOutPortfrontAxis: PartrearAxis: PartfrontWheel: WheelrearWheel: Wheel

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]:
eVehicle_LogicalArchitecture«part»eVehicle: Part«part»body: Part«part»battery: Batterycapacity: BatteryCapacity= 42;:>>Battery::capacitypowerOut: PowerOutPortports«part»engine: EnginepowerIn: ~PowerOutPortports«part»frontAxis: Part«part»rearAxis: Part«part»frontWheel: Wheel«part»rearWheel: Wheel22

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]:
«part»eVehicleVariations: Part«variation»«part»battery: Battery«part»batterLow: Battery«part»batteryHigh: Battery«variation»«part»engine: Engine«part»standardEngine: Engine«part»powerEngine: Engine«variant»«variant»«variant»«variant»
In [84]:
%viz --view=tree eVehicle_VariantModel::eVehicle_Configurations
Out[84]:
eVehicle_Configurations«part»eVehicleStandard: Part«part»engine: Engine«part»battery: Battery«part»eVehiclePremium: Part«part»engine: Engine«part»battery: Battery«part»INVALIDeVehicle: Part«part»engine: Engine«part»battery: Battery

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]:
eVehicle_LogicalArchitectureeVehicle: PartfrontAxis: PartfrontWheel: PartrearAxis: PartrearWheel: Partengine: EnginelugBolt: PartboltCircle: Parthousing: PartlugBolt: PartboltCircle: Parthousing: Part

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]:
eVehicle_LogicalArchitecture«part»eVehicle: Part«part»engine: Engine«part»frontAxis: Part«part»frontWheel: Part«variation»«part»lugBolt: Part«part»lugBolt23: Part«part»lugBolt42: Part«part»boltCircle: Part«part»housing: Part«part»rearAxis: Part«part»rearWheel: Part«part»lugBolt: Part«part»boltCircle: Part«part»housing: PartDefinition of the variation-------------26«variant»«variant»26

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 [2]:
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[2]:
Package eVehicleRequirementDefinitions (35e8700a-06ac-4e92-857c-736132c061f5)
In [12]:
%viz eVehicleRequirementDefinitions
Out[12]:
eVehicleRequirementDefinitions«requirement def»BatteryCapacityReqDefThe actual battery capacity shall be greater than or equaltothe required capacity.capacityActual: BatteryCapacitycapacityRequired: BatteryCapacityrequire: ConstraintCheck { capacityActual <=capacityRequired }constraints«requirement def»MaxSpeedReqDefThe maximum speed of the vehicle shall be not greater thanthe required maximum speed.maxSpeedRequired: SpeedmaxSpeedVehicle: Speedrequire: ConstraintCheck { maxSpeedVehicle <=maxSpeedRequired }constraints

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]:
«part»eVehicle: PartmaxSpeed: Speed= 142;«part»body: Part«part»battery: Batterycapacity: BatteryCapacity= 42;:>>Battery::capacitypowerOut: PowerOutPortports«part»engine: EnginepowerIn: ~PowerOutPortports«part»frontAxis: Part«part»rearAxis: Part«part»frontWheel: Wheel«part»rearWheel: Wheel22
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]:
eVehicleRequirements«requirement»eVehicleSpecification: RequirementCheckRequirement Specification of the eVehiclerequire: BatteryCapacityReqDefrequire: MaxSpeedReqDefconstraints«requirement»[REQ.B.1] eVehicleBatteryCapacity: BatteryCapacityReqDefcapacityRequired: BatteryCapacity= 50;:>>BatteryCapacityReqDef::capacityRequiredcapacityActual: BatteryCapacity= eVehicle::battery::capacity;:>>BatteryCapacityReqDef::capacityActual«requirement»[REQ.V.1] eVehicleMaxSpeed: MaxSpeedReqDefmaxSpeedRequired: Speed= 140;:>>MaxSpeedReqDef::maxSpeedRequiredmaxSpeedVehicle: Speed= eVehicle::maxSpeed;:>>MaxSpeedReqDef::maxSpeedVehicle

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)

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 [1]:
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[1]:
Package eVehicleLibrary (deed4eff-a92a-4807-a4c5-4eb08b39112c)
Package eVehicleDefinitions (c1b733eb-e970-477a-85c0-b80b321256d6)
In [5]:
%viz eVehicleLibrary
Out[5]:
eVehicleLibrary«dataType»Integer«attribute def»ElectricEnergy«attribute def»BatteryCapacity«port def»PowerOutPortenergy: ElectricEnergy«interface def»PowerInterfaceconsumerPort: ~PowerOutPort:>>Interface::targetsupplierPort: PowerOutPort:>>Interface::sourceports
In [4]:
%viz eVehicleDefinitions
Out[4]:
eVehicleDefinitions«part def»Wheelsize: Integer«part def»Batterycapacity: BatteryCapacity«part def»Engine

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]:
SYSMOD«requirement def»ObjectiveA objective is an objective of the system. It is a special kind ofa requirement that is typically not satisfied but amplified by thesystem.«part def»SystemproblemStatement: StringsystemIdea: String«dataType»String
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]:
ForestFireDetectionSystemModelFFDS_CoreFFDS: SystemFFDS_RequirementsFFDS_ObjectivesMarket Leader: ObjectiveReliable Detection: ObjectiveAffordability: ObjectiveproblemStatement: String= ''How can weprovide a forest fire detection system for forestauthorities that can be scaled to any forest size, is affordable, highly reliable and accurate indetecting forest fires.'';:>>System::problemStatementsystemIdea: String= ''The FFDS is a satellite-based system to detect forest fires in very largeareas. The system is also equipped withstationary sensors and animal sensors. Usingdifferent sources for the fire detectionincreases the reliability of the system andenables different system configurations fordifferent environmental contexts and pricesegments. Main features of the FFDS areDetecting and reporting forest fires on timeMonitoring forest and fires Uses the behavior offorest animals to detect fires'';:>>System::systemIdeasubj: Anything:>>Objective::subjsubj: Anything:>>Objective::subjsubj: Anything:>>Objective::subj

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]:
ForestFireDetectionSystemModelFFDS_CoreFFDS_RequirementsFFDS_Objectives«part»FFDS System Context: SystemContext«part»FFDS: SystemproblemStatement: String= "How can we provide a forest firedetection system for forest authorities that can be scaled toany forest size, is affordable, highly reliable and accurate indetecting forest fires.";:>>System::problemStatementsystemIdea: String= "The FFDS is a satellite-based system todetect forest fires in very large areas. The system is alsoequipped with stationary sensors and animal sensors. Usingdifferent sources for the fire detection increases the reliabilityof the system and enables different system configurations fordifferent environmental contexts and price segments. Mainfeatures of the FFDS are Detecting and reporting forest fireson time Monitoring forest and fires Uses the behavior of forestanimals to detect fires";:>>System::systemIdea«part»Operator: User«part»Administrator: User«part»Forest Ranger: User«part»Maintenance: User«part»Fire Department: ExternalSystem«part»Meteorology data system: ExternalSystem«part»Research analysis system: ExternalSystem«part»Weather: EnvironmentalEffect«part»Fire: EnvironmentalEffect«part»Planet Environment: EnvironmentalImpact«requirement»[OBJ-B1] Market Leader: ObjectiveThe system will make the vendor the market leader for forestfire detection systems.«requirement»[OBJ-S1] Reliable Detection: ObjectiveAny forest fire is detected by the system on time to starteffective counteractions.«requirement»[OBJ-S2] Affordability: ObjectiveThe system is affordable for any forest authority.

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]:
SYSMOD«part def»System«part def»SystemContext«requirement def»Objective«dataType»StringproblemStatement: StringsystemIdea: StringsystemOfInterest: Systemactors: Part«part def»User«part def»ExternalSystem«part def»EnvironmentalEffect«part def»EnvironmentalImpact

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]:
TheFASJukeBoxFASLanguageUseCasesDomainKnowledgeFunctionalArchitectureFunctionalInterfaces«part def»FunctionalBlock«action def»(Un)install and Move Jukebox«action def»Ask for Track to Play«action def»Assemble Music Collection«action def»Connect Jukebox with Electrical Supply«action def»Disconnect from Electrical Supply«action def»Distribute Energy«action def»Get Energy«action def»Get Mechanical Energy«action def»Get Money«action def»Insert Cash«action def»Install Jukebox«action def»Listen to Music«action def»Make Music Available«action def»Monitor Payment«action def»Play Music Track«action def»Produce Sound«action def»Provide Music Track«action def»Retrieve Identification of Music Track«action def»Retrieve Money«action def»Supply Jukebox with Energy«action def»Transform Mechanical Engery into Something Harmless«action def»Uninstall Jukebox«action def»Use Means of Music Transfer to Retrieve Music«item def»AudioSignal«item def»ClearanceToPlayMusic«item def»ElectricalEnergy«item def»IdentificationOfMusicTrack«item def»MechanicalEnergy«item def»Money«item def»MusicTrack«part»TheFASJukeBoxFunctionalContext: Part«part»TheFASJukeBoxFunctionalArchitecture: Part«part»I/O Customer: FunctionalBlockp1: MoneyPortp2: ~AudioSignalPortp3: IdentificationOfMusicTrackPortports«part»I/O Electrical Supply: FunctionalBlockp1: ElectricalEnergyPortports«part»I/O Music Supplier: FunctionalBlockp1: MusicTrackPortports«part»I/O Pub Interior: FunctionalBlockp1: MechanicalEnergyPortports«part»I/O Pub Manager: FunctionalBlockp1: IdentificationOfMusicTrackPortports«part»Accounting: FunctionalBlockp1: ClearanceToPlayMusicPortp2: ~MoneyPortports«part»Energy Distribution: FunctionalBlockp1: ~ElectricalEnergyPortports«part»Music Player: FunctionalBlockp1: AudioSignalPortports«part»Music Storage: FunctionalBlockp1: ~IdentificationOfMusicTrackPortp2: ~MusicTrackPortp3: ClearanceToPlayMusicPortports«part»Suspension: FunctionalBlockp1: ~MechanicalEnergyPortports«part»Customer: User«part»Pub Manager: User«part»Music Supplier: ExternalSystem«part»Electrical Supply: ExternalSystem«part»Pub Interior: ExternalSystem«port def»AudioSignalPorta: AudioSignalitems«port def»ClearanceToPlayMusicPortm: ClearanceToPlayMusicitems«port def»ElectricalEnergyPorte: ElectricalEnergyitems«port def»IdentificationOfMusicTrackPortm: IdentificationOfMusicTrackitems«port def»MechanicalEnergyPortm: MechanicalEnergyitems«port def»MoneyPortm: Moneyitems«port def»MusicTrackPortm: MusicTrackitems«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»«depend»
In [4]:
%viz --view=interconnection TheFASJukeBox::FunctionalArchitecture::TheFASJukeBoxFunctionalContext
Out[4]:
TheFASJukeBoxFunctionalContext: PartTheFASJukeBoxFunctionalArchitecture: PartI/O Customer: FunctionalBlockI/O Electrical Supply: FunctionalBlockI/O Music Supplier: FunctionalBlockI/O Pub Interior: FunctionalBlockI/O Pub Manager: FunctionalBlockAccounting: FunctionalBlockEnergy Distribution: FunctionalBlockMusic Player: FunctionalBlockMusic Storage: FunctionalBlockSuspension: FunctionalBlockp1: MoneyPortp2: ~AudioSignalPortp3: IdentificationOfMusicTrackPortp1: ElectricalEnergyPortp1: MusicTrackPortp1: MechanicalEnergyPortp1: IdentificationOfMusicTrackPortp1: ClearanceToPlayMusicPortp2: ~MoneyPortp1: ~ElectricalEnergyPortp1: AudioSignalPortp1: ~IdentificationOfMusicTrackPortp2: ~MusicTrackPortp3: ClearanceToPlayMusicPortp1: ~MechanicalEnergyPortCustomer: UserPub Manager: UserMusic Supplier: ExternalSystemElectrical Supply: ExternalSystemPub Interior: ExternalSystem

VAMOS (Variant Modeling with SysML)