The MBSE Podcast

Broadcast date: December 9th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 9th door of our MBSE Podcast Advent Calendar. This time, we take a look at the state machines.  Here, we use a state machine to specify the top-level states of our system and with that, the pre-and post-conditions of the use cases. This state machine is owned by the system element. Let’s look at it in the model. TMPCT State Machine The state machine considers four states of the Christmas Tree: “packed”, “ready to use”, “operation”, and “disposed”.  Do you remember the triggers of our use cases? We specified a textual trigger as well as a formal signal model element. The use case trigger signals trigger the transitions in the state machine. The use case activities are the effect of the transitions or internal behavior of the states. The special learning surprise: you cannot directly set the use case activity on a transition or a state, because they must own the activity. However, the use case activity is already owned by the use case.  The trick is to define an activity with a single call behavior action which calls the use case activity. For example, the effect of the “do behavior” of the Operation state: Activity owned by a State The activity does not need an initial and final node. It is sufficient to just model the call behavior action. So much for the 9th door of our MBSE Podcast Advent Calendar. We wish you a great 9th of December. Der Beitrag Episode 19.9 – State Machines erschien zuerst auf The MBSE Podcast.

Broadcast date: December 8th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome! Behind the eighth door of our MBSE Podcast Advent Calendar, we take a look at the domain knowledge model.  For the object flows in the use case activities, we have defined the types of flowing objects. These are mostly blocks and value types of the domain knowledge model. Or put in another way, the domain knowledge model defines the types of objects that the system uses in its functions. Let’s look at it in the model and again at the use case activity “Enjoy Christmas tree”. Use Case Activity “Enjoy Christmas tree” There are only a few object types like “SI_Power”, “Hi_Light”, and “FlashingProgram”. The prefix “SI” indicates that it is an object type that occurs in a system interface to another system, and the prefix “HI” indicates that it is an object type that occurs in a system interface to a human.  These types are defined besides others in the domain knowledge model, which is partially depicted in the following block definition diagram: Domain Knowledge Model The value type “cm” is a specialization of the primitive type Integer from the SysML library. It is our decision that we take integer values for cm. An alternative would be real. SysML also explicitly supports the modeling of units. However, we did not use that for simplicity. Of course, all these types are good candidates for a model library.  The domain knowledge represents the knowledge of your system. If you ask your system: “Do you know the concept of FlashingProgram?”, it can answer yes. It knows it as defined in the domain block. If you ask the system about Christmas Gifts, it has no idea what it is.  So much for the eighth door of our MBSE Podcast Advent Calendar. We wish you a great 8th of December. Der Beitrag Episode 19.8 – Domain Knowledge Model erschien zuerst auf The MBSE Podcast.

Broadcast date: December 7th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 7th door of our MBSE Podcast Advent Calendar. Behind the door, we take a look at the system use case activities.  Behind each of our use cases, we define an activity to model the functional decomposition, including control and object flows. Let’s look at it in our model. In the containment tree, you can see that the activity is owned by the use case. Use Case Activity “Install Christmas tree” The activity diagram shows the execution order of actions.  We’ve modeled each action as a call behavior action, which means each step of the Christmas tree installation is detailed and defined by an activity. This defines the entire system behavior of the use cases with activities, which has many advantages, e.g., it is a prerequisite for the FAS method for deriving functional architectures, which we will look at another day. Another special feature in our modeling is the separation of the functions responsible for input and output functionality from and to the actors and the other functions. We have modeled this with activity partitions. This is analytically useful and also good preliminary work for the FAS method. The stereotype “IO” comes from the profile for the FAS method. The outgoing transportation net parameter of the activity on the left side is a so-called streaming parameter, which means the object can flow out of the activity during the execution.  The input parameter transportation package flows into a datastore node to make the object available several times for different actions. Finally, we show another example from our MBSE Podcast Christmas Tree: the continuous use case “Enjoy Christmas tree”. Continuous use cases represent a continuous behavior. Use Case Activity “Enjoy Christmas tree” The “Flash lights” activity runs continuously until the tree is turned off. That behavior is modeled in the state machine we will present another day. So much for the seventh door of our MBSE Podcast Advent Calendar. We wish you a great 7th of December. Der Beitrag Episode 19.7 – Use Case Activities erschien zuerst auf The MBSE Podcast.

Broadcast date: December 6th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 6th door of our MBSE Podcast Advent Calendar. Behind the door, we take a look at the system use cases.  There are a lot of methods for modeling use cases published in many books, papers, and other publications. We present a very simple method and avoid use case relationships such as include, extend, or generalization between use cases. The use cases here are simply a list of the functions of the system in which actors are involved and which create value for an actor or stakeholder. Let’s look at it in our model. TMPCT System Use Cases Some of our use cases are depicted in the use case diagram with the associated actors.  There are a few special features in the modeling: The actor Carrier of the use case “Transport Christmas tree” is a generalization of the actors “Christmas Tree Seller” and “Owner”. It is an XOR condition. The use case has only one actor which could be either a seller or an owner. The association end at the Child actor has a multiplicity 0..*, which means that children are optional, but there could be many of them who are enjoying the Christmas tree. Although use case diagrams are very common, they just show more or less only a graphical list of use cases. You can depict the same information in a table plus more properties. TMPCT System Use Cases in a Table The table also shows the documentation of the use case as well as additional properties introduced by the SYSMOD stereotype “systemUseCase” for the trigger and the result of the use case. The triggerSignal property stores a signal to formalize the trigger. You will meet it again when we talk about state machines. That’s the learning surprise behind this door. Tables are valid views of SysML model elements, and they can be much more convenient than the diagram. You do not have layout effort, and – depending on the tool – tables are, typically, queries and always up-to-date. Use the tables for the daily engineering work, and diagrams for workshops, presentations, or eventually documents. So much for the sixth door of our MBSE Podcast Advent Calendar. We wish you a great 6th of December. Der Beitrag Episode 19.6 – Use Cases erschien zuerst auf The MBSE Podcast.

Broadcast date: December 5th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 5th door of our MBSE Podcast Advent Calendar. Today, we take a look at the system context.  We already defined a context for the base architecture behind door #4 of our Advent calendar. The base architecture context constrains the context of our system of interest. We model it by defining a generalization relationship from the system context to the base architecture context. Let’s check that out in the model: The part property “The MBSE Podcast Christmas Tree” is a redefinition of the inherited system property base_tmpct from the base architecture context. In addition to the inherited actors from the base architecture context, the TMPCT system context has an additional actor Christmas Tree Seller. TMPCT System Context Definition The system context elements are SysML blocks with applied stereotype “systemContext” from the SYSMOD profile. It is just a marker profile that introduces a new name and additional semantics, but no new properties. The internal block diagram of the system context element depicts the well-known system context diagram: TMPCT System Context The inherited elements from the base architecture contexts have a circumflex prefix symbol. In our system context, all actors are inherited except the seller. SysML provides only the general concept of an actor. It is useful to define different actor kinds to emphasize the different methodological approaches. At least you should differentiate between humans and non-humans. In the shown context diagram, you can see four different actor kinds: Human users of the system, for example, Santa Claus. External systems, for example, the power supply. A mechanical system is a special kind of external system that has only mechanical interactions with the system. Here, it is the floor of the room. The Planet Environment to consider the impact of the system on the planet. All actors have some kind of interaction with the system, and you could specify the interaction point by ports.  And here we have the little surprise learning in this episode: stakeholders are not in context or only when they interact with the system. For example, we MBSE podcast hosts are stakeholders of the system, but not actors. Of course, as people, we could take on the role of user-actor. But the MBSE podcast host role is not an actor and thus the system does not provide any special interfaces or functions for us. Vice versa all actors are stakeholders of the system. Sometimes they are not directly stakeholders, but representatives. For example, things like the floor are not a stakeholder, but the owner of the floor is a stakeholder. So much for the fifth door of our MBSE Podcast Advent Calendar. We wish you a great 5th of December. Der Beitrag Episode 19.5 – System Context erschien zuerst auf The MBSE Podcast.

Broadcast date: December 4th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 4th door of our MBSE Podcast Advent Calendar. Behind the door, we take a look at base architectures.  We already mentioned the base architecture in the previous days. Now, let’s talk about what it is. In systems engineering, we distinguish the problem space and the solution space. For example, the requirements are in the problem space and are solution-free, and the system architecture is in the solution space and satisfies the requirements. Sounds simple, but it’s not. What does it mean that requirements are solution-free? What is a solution? Can a requirement request that a vehicle has four wheels? Or is the wheel already a solution? The separation of problem and solution space is correct. What is missing is the consideration that there are several levels of it. A solution space on one level is the basis for the problem space on the next level. To return to the vehicle example: On one level, we have requirements in the problem space that the system should be able to move on roads. In the solution space, we have chosen the concept of a wheel, as one alternative, in the architecture to satisfy these requirements.  This architecture is the basis for the next level. The wheel is assumed, and we now set the requirement that there should be four wheels with the size and so on. The system architecture from the higher-level solution space, we call base architecture. When we describe them explicitly, we more strongly separate the problem space from the solution space and make implicit assumptions explicit. The decisions in the base architecture are constraint requirements for the next level. The basic architecture of our Christmas tree already specifies a lot, since the basic structure of a Christmas tree is fixed and not part of the solution space. The diagram shows the definition of the elements in a block definition diagram. Our “The MBSE Podcast Christmas Tree” – abbreviated TMPCT – Base Architecture includes a transportation net, a tree with a trunk and branches, a Christmas tree star, fairy lights, a stand, and a transportation package. SysML modeling tools allow us to use images instead of the SysML shapes. This makes it more illustrative. TMPCT Base Architecture Definition The base architecture also leads to a base system context, which we define in the following block definition diagram. External actors are the floor in a room, Santa Claus, the owner of the tree, eventually children, a power supply, the planet environment for sustainability considerations, and the TMPCT Base Architecture itself. TMPCT Base Arcitecture Context Definition Depicted in an internal block diagram shows the typical figure of a system context diagram. Here, comes the context of our base architecture: TMPCT Base Architecture including Context We leave out most of the connections inside our Christmas tree. They will be defined later in the physical architecture of our system. When we look at those, we also see how the relationship to the base architecture can be modeled. We will explain the concept of Ports, connectors, and part properties in later sessions.  When we consider the system context, we will cover how the system context is related to the base architecture context. What was the surprise behind this door? It is the basic architecture itself that is special. It’s always there, but it’s often carelessly documented. The blurring between problem space and solution space, as well as the implicit assumptions, leads to many potential problems in projects. So much for the fourth door of our MBSE Podcast Advent Calendar. We wish you a great 4th of December. Der Beitrag Episode 19.4 – Base Architecture erschien zuerst auf The MBSE Podcast.

Broadcast date: December 3rd, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 3rd door of our MBSE Podcast Advent Calendar. Behind the third door, we take a brief look at requirements modeling.  There is and has been a lot to say about requirements modeling. We will limit ourselves to one special feature, which is also the learning gift of today: the reuse of requirements. This is a bit unusual but is supported by SysML with a special relationship, and the relationship is not yet used that often. In the Christmas tree business, there is the important International Christmas Standard abbreviated ICS. The specific ICS 242526-12 standard contains a list of requirements for Christmas trees. We import the standard into our model as a model library. Used Libraries and applied Profiles As an example, the following table contains three of the Christmas tree standards in the library: Requirements in the International Christmas Standard ICS 242526-12 Model Library Our MBSE Podcast Christmas Tree project would like to use exactly these requirements from the library. However, we would like to have a different numbering schema and also add additional properties like obligation, priority, or the stakeholder. Therefore, we use the SysML copy relationship to create copies of the requirements in our project. Copied System Requirement “Height of the Tree” The requirement “Height of the Tree” is a copy of the standard requirement “Tree Height”. The relationship assures that the text of the copied requirement is always identical to the master. All other properties can be different. The following table shows some of our MBSE Podcast Christmas Tree requirements with the properties: ID, Name, Text, Obligation, Priority, Stakeholder, and the master if it is a copy. Table with some System Requirements The requirements are in different packages of the model. Some of them are located in the package structure of the related component, for example, those for the tree. So much for the third door of our MBSE Podcast Advent Calendar. We wish you a great 3rd of December. Der Beitrag Episode 19.3 – Requirements Modeling erschien zuerst auf The MBSE Podcast.

Broadcast date: December 2nd, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 2nd door of our MBSE Podcast Advent Calendar. Behind this door, we describe the system idea and system objectives. The system idea is the elevator pitch of the system of interest. It briefly and crisply describes what the system is, with a special focus on what makes it special. It is text and provided with graphics if needed. The SysML language does not know the concept of system idea. Interestingly, SysML does not know the concept of a system either, although it is a Systems Modeling Language. We can teach the language new concepts via the “profiles and stereotypes” extension mechanism. Behind one of the following doors, there will be an explicit explanation about this as well. Here in a nutshell: SYSMOD introduces the concept of a system via a stereotype – specialized from the block – and defines the system idea as a property of it. In the model, it can then be represented like this. It is a tool-specific property that the text can be formatted. If graphics are part of the system idea, they are referenced. The system idea of our Christmas tree is as follows: System Idea in a Diagram System objectives are also a concept that SysML does not recognize. SYSMOD again uses a stereotype to include it in the language. A system goal is a special form of the SysML requirement. The following requirements diagram shows the objectives of our Christmas tree: System Objectives in a Diagram The diagram is illustrative, but the topology of the elements doesn’t really matter much here. It is a good practice instead to manage the model information in tables. This saves a lot of modeling effort. In addition, in today’s modeling tools, tables are usually model queries, i.e., they show all elements in the model. In the diagram, there are only the elements that a modeler has placed manually. If needed, the diagram can be created quickly, for example, for a workshop. System Objectives in a Table You may have noticed the stakeholder. System objectives have a trace relationship to the stakeholders who are responsible for the goal. Here it is we podcast hosts, as we are responsible for the overall system. SysML knows the concept of a stakeholder. SYSMOD nevertheless defines a stereotype “extendedStakeholder” to add special properties like contact or a priority. Since the stakeholders are also related to the requirements and they also belong there thematically, they are stored in the requirements package in the model. You could represent them in a diagram, but it is much more practical in tabular form. The table does not show all properties of the stakeholders but only the name, documentation, contact information, and priority. Stakeholders in a Table So much for the second door of our MBSE Podcast Advent Calendar. We wish you a great 2nd of December. Der Beitrag Episode 19.2 – System Idea and Objectives erschien zuerst auf The MBSE Podcast.

Broadcast date: December 1st, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the MBSE Podcast Advent Calendar. We will open a new door every day until December 24th. This means that every day there will be a short MBSE Podcast episode. In 24 episodes, we will each briefly describe how to model a system using the SYSMOD methodology. Each episode highlights a new aspect. The system is our super cool MBSE Podcast Christmas tree.  The example is not entirely serious, of course, but we are modeling seriously. Sometimes this will make it look a bit strange and certainly very much like over-modeling. With our advent calendar, you get a lightweight overview of modeling a system and the essential steps of the MBSE methodology SYSMOD. In addition, each episode also contains a small gift in the form of good practice. The Advent Calendar episodes are different from the previous episodes. They are only about around 5 minutes long, we don’t have a guest, and since we also want to show the modeling, the audio-only channel only works to a limited extent. We use Cameo Systems Modeler and the SYSMOD profile as the system modeling environment for our project. However, any other SysML-compliant modeling tool could also be used for the project. In 2022 we will continue with our regular MBSE podcast episodes with live sessions exciting guests from the MBSE community. Now, let’s take a first look at the model.  Package Structure of The MBSE Podcast Christmas Tree Model On the left side, you can see the model structure. The package “Derived Properties” is tool-specific. We don’t need to look at that any further. The “International Christmas Standard” is a model library covered in the following session about requirements. The package symbol with the tiny triangle is the root of our product model, “The MBSE Podcast Christmas Tree” – abbreviated TMPCT. On the next level, you can see packages for several engineering artifacts like context, requirements, or architectures. They will be covered step by step in the following episodes. Here comes the special learning gift of this episode: It is a good practice to design the package structure the following way. At the top level, separation is made according to primary engineering artifacts. The package names are each given the namespace above as a prefix, e.g. TMPCT_Context. At the base architecture or physical architecture level below, the elements of individual components of the system, such as the tree, are stored in their own packages. Their substructure behaves like the structure of the system model. Thus the package structure scales very well. If required, these packages can be cut out and used as separate system models. Let’s open the package diagram “TMPCT Model Structure”. It depicts the applied profiles and used libraries of our system model.  Used Libraries and applied Profiles From left to right:  We apply the SYSMOD profile to use SYSMOD-specific model elements like system, system context, or system use cases. We apply the FAS profile for the modeling of functional architectures using the FAS method. We import the Engineering4Planet model library for sustainability elements. That library is provided by SYSMOD. We import the PartsCatalogue model library to get some nice reusable elements. That library is also provided by SYSMOD. And we import the “International Christmas Standard” model library to get common Christmas tree requirements. All the profiles and libraries will be used in some of the following sessions as well as we will explicitly cover profiles and model libraries. So much for the first door of our MBSE Podcast Advent Calendar. We wish you a great 1st of December. Der Beitrag Episode 19.1 – The MBSE Podcast Christmas Tree Project erschien zuerst auf The MBSE Podcast.

Broadcast date: November 18, 19:00 CET – Language: English – Some Audio Issues This episode is again part of our MBSE Tools series, and we look at the Incquery Suite.  Our guest Istvan Rath is CEO and co-founder of Incquery Labs. The suite enables the Digital Thread in which it analyses and connects MBSE models. It increases data quality and connects silos. As an integration platform, the Incquery Suite watches over all the phases and provides continuous model analysis, in particular, inter-domain validation and consistency analysis. We are happy to welcome Enrique Kranjmalnik as a guest in this episode as well. Enrique is COO of Vitech, which is part of Zuken. Among other things, we will talk about how the Incquery Suite can be used for consistency of a tool chain with Vitech’s GENSYS for a system architecture, and Zuken’s E3.series for a detailed wiring design. You can join us live, at the Youtube Livestream on November 18, 2021, at 19:00 CET or later on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Der Beitrag Episode 18 – MBSE Tools: The Incquery Suite with Istvan Rath and Enrique Krajmalnik erschien zuerst auf The MBSE Podcast.