The MBSE Podcast

Broadcast date: December 19th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 19th door of our MBSE Podcast Advent Calendar. Today, we take a look at the modeling of variants. Very often, a system contains variants; so does our MBSE Podcast Christmas Tree. We provide trees with different Christmas stars, balls, stands, and fairy lights.  Let’s look at our model of how to define the variants.  Model structure with Configurations, Core, and Variants We restructured our model from a simple system model to a product line model. To do this, we have defined three new packages at the top level: a core package that contains all elements that apply to all products, a variation package that contains the variable elements, and a package that contains the configurations, for example, “product definitions”. Our previous packages are now all arranged below the core package. VAMOS Feature Tree In the TMPCT_Variations package, there is a package diagram that shows the variants of the product line in the form of a feature tree. The variation packages represent the discriminator of variability. Here it is generally only the kinds. The minVariants/maxVariants properties specify how many of the variants may be in a valid configuration at the same time. Mostly it is exactly one. An exception here is the “Christmas Ball Kinds” variation. Here also two variants may be contained at the same time in a configuration. The variant packages each contain all exclusive model elements only required by a variant. Constraints can be defined between the variants. Typical variant constraints are REQUIRES and XOR. A REQUIRES constraint is defined between the “Premium Star” and “Large Stand” variants, i.e. if the “Premium Star” variant is selected, the “Large Stand” variant must also be selected for a valid configuration. Definition of Premium Star Variant The variant “Premium Star” defines a special “Christmas Star” that has a LED starlight. The “Premium Christmas Star” block specializes the common “Christmas Tree Star” block from the core. Configurator The configuration package contains the variant configurations, which are specifications of concrete products of the product line. The three defined editions of our MBSE Podcast Christmas Tree are Eco, Premium, and Standard. Each configuration selects the contained variants, which can be perfectly done in a matrix. The selection is modeled by a package-import relationship. Here we have intentionally included an error for demonstration purposes. The configuration “TMPCT Premium Edition” has selected the variant “Premium Star”. The REQUIRES constraint described above requires that the variant “Large Stand” must then also be selected, but we have selected the variant “Standard Stand”. The error is automatically displayed in the matrix. As already mentioned, the REQUIRES constraint is a stereotype from the SYSMOD profile and also contains an OCL constraint that checks compliance with the rule. This is completely based on standards. The only tool-specific here is, that the tool is able to evaluate the OCL rule. Definition of a Variant Configuration The block definition diagram shows a part of the definition of the “TMPCT Premium Edition”. The edition itself is a system element that specializes the system element from the core. C As an example, it is shown how the “Premium Star” edition system is implemented. The “Premium Christmas Star” is explicitly defined as a part property that redefines the inherited property of the general star. So much for the 19th door of our MBSE Podcast Advent Calendar. We wish you a great 19th of December. Der Beitrag Episode 19.19 – Variant Modeling erschien zuerst auf The MBSE Podcast.

Broadcast date: December 18th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 18th door of our MBSE Podcast Advent Calendar. Today, we take a look at the modeling of profiles and stereotypes. Typically, you cannot use SysML out of the box very well. The language is too general to provide enough words to talk about a concrete system. For example, SysML defines a block, but not a system, subsystem, component, module, domain block, software block, and so forth. Or SysML defines a requirement with only three properties name, id, and text, but neither functional requirements nor performance requirements nor requirement properties like a priority, motivation, or a list of risks.  It is intended that you extend SysML with a more specific vocabulary that fits your needs.  Let’s have a look at how we did it in our model.  Profile Application Besides others, our model applies the SYSMOD profile. A profile defines an extension of SysML. The profile application relationship makes the extension available for the model. The profile is similar to a package and contains stereotypes. A stereotype extends an existing SysML element. It provides a name and semantics and can provide additional properties and notation.  The following diagram shows some stereotypes of the SYSMOD profile, which extends the SysML block.  Stereotype Definitions The <<system>> stereotype specializes the SysML Block and adds two properties to store the problem statement and system idea of the system.  Stereotype Images The SYSMOD stereotypes define different actor categories like external systems, environmental effects, and so on, and as well as it introduces a new notation. Therefore, the actor can be depicted by cubes in the system context. Typically, the first step before modeling stereotypes is creating a concept model of the new concepts.  VAMOS Domain Knowledge Model As one example, this block definition diagram shows the concepts of variant modeling terms from the VAMOS approach. VAMOS stands for “Variant Modeling with SysML”.  VAMOS Stereotypes The VAMOS stereotypes, which are part of the SYSMOD profile, are derived from this concept model.  We will have a more detailed look at variant modeling tomorrow.  So much for the 18th door of our MBSE Podcast Advent Calendar. We wish you a great 18th of December. Der Beitrag Episode 19.18 – Profiles and Stereotypes erschien zuerst auf The MBSE Podcast.

Broadcast date: December 17th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 17th door of our MBSE Podcast Advent Calendar. Today, we take a look at the modeling of parametric.  The parametric diagram depicts a network of constraints that constrain properties of the system. If your modeling tool is able to execute the constraints, it could be an extremely effective modeling approach.  So, let’s have a look at it in our model.  Constraint Block Definitions First, we need the expressions which are defined by constraint blocks. The lower constraint block specifies a min-max-expression using three parameters “minValue”, “maxValue”, and “value” which are each typed by our value-type “cm”.  The constraint block “TrunkStandConnectionConstraint” verifies that the trunk fits into the stand. It does not define a constraint but owns a constraint property typed by our “MinMax” constraint block. The parametric diagram is a special kind of internal block diagram which depicts how the parameters of the constraints are connected with other parameters or value properties.  Parametric Diagram of a Constraint Block The parametric diagram shows the internal structure of the “TrunkStandConnectionConstraint” which simply connects its parameters with the appropriate internal constraint parameters of the “MinMax” constraint block. We defined a constraint property of type “TrunkStandConnectionConstraint” owned by our system to use this constraint for the MBSE Podcast Christmas Tree.  Usage of a Constraint Block In a parametric diagram of the “TMPCT Base Architecture”, we connected the parameters of the constraint with the appropriate value properties of the system. The value properties already have defined default values. However, they could be redefined later by the specialized properties in the physical architecture. Parametric Diagram We also added another interesting constraint property. The constraint block “Height of the Tree” is a constraint block and a requirement at the same time. Since SysML v1.5, any named model element can also be a requirement.  The requirement and constraint block “Height of the Tree” requires and verifies that the height of the tree is between 150 and 200 cm. Constraint Block and Requirement Parametric Diagram with “Constraint Block Requirement” Usage The parametric diagram of the system element “The MBSE Podcast Christmas Tree” shows how everything is connected. Our modeling tool can also run the constraints.  Constraint Execution Results When we instantiate our TMPCT system element, we see in the output that the constraints are satisfied. This tool then displays the corresponding area in green.  So much for the 17th door of our MBSE Podcast Advent Calendar. We wish you a great 17th of December. Der Beitrag Episode 19.17 – Parametric Diagram erschien zuerst auf The MBSE Podcast.

Broadcast date: December 16th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 16th door of our MBSE Podcast Advent Calendar. Today, we take a look at the modeling of a sequence diagram.  A sequence diagram depicts the exchange of messages between properties represented by the so-called lifelines.  Let’s look at it in our model.  Sequence Diagram “Switch on Christmas tree” Our sequence diagram shows a simple scenario of our MBSE Podcast Christmas Tree. Actually, the tree does not include so many scenarios. Well, it is just a tree.  The model element represented by the whole sequence diagram is called an interaction. Here, the interaction is owned by the system context element.  The user sends a switch-on signal to the enjoyment control unit. It is an asynchronous message. Then, the internal operation startFlashingProgram is called, which starts a loop to switch on and off the fairy lights, and in parallel, the lights enjoy a child.  You can use sequence diagrams for several purposes, for example, to specify a test case, to specify a communication protocol, to demonstrate an example, and so forth.  So much for the 16th door of our MBSE Podcast Advent Calendar. We wish you a great 16th of December. Der Beitrag Episode 19.16 – Sequence Modeling erschien zuerst auf The MBSE Podcast.

Broadcast date: December 15th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 15th door of our MBSE Podcast Advent Calendar. Today, we take a look at the modeling of interfaces.  Typically, you use ports typed by interface blocks. With a connector, you model the connection between two ports.  Let’s have a look at our physical architecture in the model. TMPCT Physical Architecture The connection between the trunk and the stand is a typical interface specification: Two ports typed by interface blocks named “ChristmasStandPort” and “TrunkPort” connected with a connector.  Today we show you a way to specify an interface in more detail. A connector can be typed by an association or association block. An association block can define the details of the connection.  Association Block Definition The following block definition diagram shows the definition of the association block PlugSocketInterface between two interface blocks PlugPort and SocketPort, each with nested ports. In addition, the association block has a part property specifying the power cable with a length of 200 cm. Like any other block, an association block can have an internal structure which is depicted in the internal block diagram.  Internal Structure of Association Block The dashed rectangles on the left and the right are references to the association ends typed by the interface blocks with the nested ports. Here, we have modeled a simple structure by connecting the nested ports directly.  This interface definition is applied between the external power supply and our Christmas tree, as depicted in the following diagram.  Typing a Connector with an Association Block So much for the 15th door of our MBSE Podcast Advent Calendar. We wish you a great 15th of December. Der Beitrag Episode 19.15 – Interface Modeling erschien zuerst auf The MBSE Podcast.

Broadcast date: December 14th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 14th door of our MBSE Podcast Advent Calendar. Again, we take a look at the physical architecture. Yesterday we worked on the definition of the physical architecture and the allocation of the elements from the functional architecture. Let’s have a look at it again in the model. TMPCT Physical Architecture Definition As promised yesterday, today we will cover the internal structure of the physical architecture.  TMPCT Physical Architecture The internal block diagram shows all parts and connections of our physical architecture. It is somewhat simplified here and we have not explicitly modeled some of the ports. As a reminder, you can identify the inherited elements by the circumflex symbol before the name. If the system is more complex, you will have more internal block diagrams. On the one hand, different diagrams on the different hierarchical levels of the system and, on the other hand, diagrams for different aspects, for example, internal block diagrams that only show logical or only electrical connections or internal block diagrams that only show the connections necessary for a use case. So much for the 14th door of our MBSE Podcast Advent Calendar. We wish you a great 14th of December. Der Beitrag Episode 19.14 – Connection of the Parts erschien zuerst auf The MBSE Podcast.

Broadcast date: December 13th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to another door of the MBSE Podcast Advent Calendar. Behind the 13th door, we take a look at the physical architecture. In the last few days, we presented the functional architecture. As a reminder, let’s open the internal block diagram of the functional architecture in the tool. TMPCT Functional Architecture We also have created a physical architecture of our MBSE Podcast Christmas tree, which specifies the physical entities that implement the functional entities from the functional architecture.  TMPCT Physical Architecture Definition The physical architecture is a specialization of the base architecture. In this diagram, it is the element with the system stereotype and the name “The MBSE Podcast Christmas Tree”. It inherits most of the parts from the system-element “TMPCT Base Architecture”. As we have seen before, we used illustrations instead of the block notation, which makes it easier for inexperienced users to understand the diagram. The blocks from our functional architecture are allocated to the blocks of the physical architecture. The allocation specifies which physical block implements which functional block.  We manage the allocation in a matrix.  Functional to Physical Allocation The rows list the functional blocks, the columns the physical blocks, and the cells the allocate relationship. Some functional blocks are mapped to more than one physical block, and some physical blocks have more than one allocated functional block. It is a rather rough mapping. For example, if a functional block is allocated to multiple physical blocks, it is not clear whether it is redundantly allocated, or only parts of the functional block. However, this is usually sufficient in the model. More details, if required, can be introduced by extending the allocate relationship with a stereotype. As with the functional architecture, the more interesting part is the internal structure of the physical architecture with ports and connections. We will cover that tomorrow.  So much for the 13th door of our MBSE Podcast Advent Calendar. We wish you a great 13th of December. Der Beitrag Episode 19.13 – Physical Breakdown Structure erschien zuerst auf The MBSE Podcast.

Broadcast date: December 12th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Hohoho, behind the 12th door of our MBSE Podcast Advent Calendar, we take a final look at the functional architecture. Yesterday we created the breakdown structure of the functional architecture.  Functional Architecture Definition Now we look at the interesting part of the functional architecture. It is the internal structure with ports and connections between the functional parts.  Functional Context Definition It is also of interest to consider the functional system context. Therefore, we inherit the functional context from the system context. The inherited actors are not purely functional, but our normal system actors.  An internal block diagram of the functional context element shows the context and the structure of the functional architecture. TMPCT Functional Architecture A functional part represents a group of activities. The connectors and ports are derived from the activity models. If an activity of one part has an output parameter which is an input parameter of an activity in another functional part, they are connected and the port specifies that these parameter objects flow through it.  Some ports have no arrow inside the rectangle symbol. Here the detailed specification of the flow properties is missing because it is not important or has not been modeled yet. Definition of Functional Interfaces The flow properties are specified by interface blocks. The interface blocks are the types of the ports. The block definition diagram shows some of the functional interface blocks. So much for the 12th door of our MBSE Podcast Advent Calendar. We wish you a great 12th of December. Der Beitrag Episode 19.12 – Functional Architecture erschien zuerst auf The MBSE Podcast.

Broadcast date: December 11th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to our MBSE Podcast Advent Calendar. Behind the 11th door, we take a look at the functional architecture again. Yesterday we created the functional groups, and today we look at the derivation of the first version of the functional architecture.  Here comes the special learning gift of this Advent calendar snippet: This step and other steps of the FAS method could be done automatically or assisted by the FAS plugin for MagicDraw, which is provided by the Germany chapter of INCOSE – the GfSE. You can download the plugin for free from Sourceforge at sourceforge.net/projects/fas4md. The functional groups are in a sub-package of the functional architecture package.  For each functional group, we created a functional block and modeled a trace relationship between them. The functional block is also a stereotype specializing the block from the FAS profile. The relationships can again be best depicted in a matrix.  Functional Blocks to Functional Groups Mapping In the matrix, you can easily see that all functional blocks have exactly one relation to one functional group. We created a root functional block that represents the whole functional architecture and created the composition structure as depicted in the block definition diagram.  Functional Architecture Definition The more interesting part of the functional architecture is depicted in the internal block diagram. We will cover that tomorrow.  So much for the 11th door of our MBSE Podcast Advent Calendar. We wish you a great 11th of December. Der Beitrag Episode 19.11 – Functional Breakdown Structure erschien zuerst auf The MBSE Podcast.

Broadcast date: December 10th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 10th door of our MBSE Podcast Advent Calendar. This time, we take a look at functional architectures.  A functional architecture is a system architecture based on functions and independent of the physical entities that implement the functions. However, the functions can depend on physical concepts defined in the base architecture. The FAS method describes how to derive a functional architecture from use case activities.  The first main important step is the grouping of the use case activities. How the activities are grouped is a decision of the system architect. The functional group is modeled by a stereotype specializing the SysML block. The grouping is then modeled by trace relationships from the functional group to the activities.  It is best to show and manage the grouping in a matrix. Let’s have a look at it in the model. Functional Grouping in a Matrix The functional groups and the matrix are located in the functional architecture package in our system model. The columns are the activities from the use case analysis. The rows are the functional groups. The single cells represent the presence of the trace relationship.  The special learning gift of today: Sometimes it is easier to manage relationships between model elements in a matrix instead of showing them in a diagram. The following diagram shows the same information as the matrix. You can easily see that it is more confusing. Functional Grouping in a Diagram (not recommended) The next step is to derive the functional architecture from the groups. We will look at it tomorrow.  So much for the 10th door of our MBSE Podcast Advent Calendar. We wish you a great 10th of December. Der Beitrag Episode 19.10 – Functional Grouping erschien zuerst auf The MBSE Podcast.