The MBSE Podcast

Broadcast date: April 27th, 2022, 19:00 CET SysML v2 is in its final run. In this episode, we address the question of what will then become of the many SysML v1 models.  The SysML v2 specification also includes a formal definition of the transformation from SysML v1 to SysML v2 models. Since Tim is one of the transformation developers, we didn’t invite an additional guest this time. We’ll talk about how the transformation works and what the challenges are. We will also look at different use cases of how a transition from SysML v1 to SysML v2 can look like. You can join us live at the Youtube Livestream on April 27th, 2022, at 19:00 CET or later on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts.   Der Beitrag Episode 24 – Migration of SysML v1 to SysML v2 erschien zuerst auf The MBSE Podcast.

Broadcast date: March 29th, 2022, 19:00 CET Broadcast date: March 29th, 2022, 19:00 CET The interoperability of engineering tools is a hot topic. That means, we want to break up the data silos, where data of specific tools is often hidden. There is hardly any engineering project that does not have it as a challenge.  One way to interoperate between tools, is a common file format, for example, XMI. The problem with these container-like Data Exchanges is, that the data potentionally is outdated seconds after it´s transmission. Although, there are Use Cases for Data Exchange Scenarios. A good reason for us to look at the Data Integration Standard OSLC in this episode. Our guest Axel Reichwein is CEO of Koneksys, a company that is all about linking data. He is a global OSLC expert and integrates for his customers different tools along and aside from the so-called standardized OSLC Specifications (for example, Requirements Management). We’ll talk about what OSLC actually is, where it comes from, who develops it, and what you can do with it. OSLC is also mentioned in connection with the new SysML v2 API and Services. We will also talk about how OSLC and SysML v2 are related. You can join us live, at the Youtube Livestream on March 29th, 2022, at 19:00 CET or later on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts.   Der Beitrag Episode 23 – Open Services for Lifecycle Collaboration (OSLC) with Axel Reichwein erschien zuerst auf The MBSE Podcast.

Broadcast date: February 28th, 2022, 19:00 CET – Language: English This time we are talking about ISO/IEC/IEEE 15288. In the following, we will refer to this standard as 15288. Probably many of you know this number. It is the leading standard on system life cycle processes. Our guest is David Endler. David served for 2 years as INCOSE’s technical director, is a member of oose, and is an independent consultant and trainer. He can give us excellent information about 15288, as he is the lead editor of the current revision as well as the lead editor of 24748-2, the guide to 15288. We will talk about what will change, what 15288 has to do with MBSE, and how standards are developed in general.  You can join us live, at the Youtube Livestream on February 28th, 2022, at 19:00 CET or later on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts.   Der Beitrag Episode 22 – ISO/IEC/IEEE 15288 System Life Cycle Processes and MBSE with Dr. David Endler erschien zuerst auf The MBSE Podcast.

Broadcast date: February 7th, 2022, 19:00 CET – Language: English This episode is part of our MBSE Methodology series. Dealing with product lines and variants keeps many projects busy. And now we are making the whole thing model-based as well: Model-Based Product Line Engineering (MBPLE). Our guest can tell us how MBPLE works. Marco Forlingieri is responsible at Airbus for introducing MBPLE into the Airbus-wide product development methodology. We’ll talk about what MBPLE actually is, why who needs it, and what the challenges are in implementing it. And of course everything possible around it like tools etc. You can join us live, at the Youtube Livestream on February 7th, 2022, at 19:00 CET or later on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Der Beitrag Episode 21 – Model-Based Product Line Engineering with Marco Forlingieri from Airbus erschien zuerst auf The MBSE Podcast.

Broadcast date: January 28th, 2022, 19:00 CET – Language: English The first episode of 2022 is part of our MBSE tool series and starts right away with a hot topic: “Connected engineering information for a connected world” – that’s the claim of the OpenMBEE platform. Their promise sounds like a dream for every (system) engineer: “It enables engineers to work in the language of their choice and easily share and document their work across other tools.”. So, let’s have a look at how to make the engineers dream true. Our guest is Chris Delp, group supervisor at NASA JPL, and one of the masterminds behind OpenMBEE. We’ll ask Chris all about OpenMBEE: how it started, who’s behind it, how it works, what’s planned for the future, how to try it out, and many more. We will talk about which organizations and projects are already using OpenMBEE and what is needed to implement OpenMBEE in a project. You can join us live, at the Youtube Livestream on January 28th, 2022, at 19:00 CET or later on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Links OpenMBEE Der Beitrag Episode 20 – The Open Model-Based Engineering Environment (OpenMBEE) with Chris Delp from Nasa JPL erschien zuerst auf The MBSE Podcast.

Broadcast date: December 24th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Hohoho, and welcome to the 24th and final door of our MBSE Podcast Advent Calendar.  Today is a special day for many. We will avoid burdening your brain with modeling topics today. Instead, we will end by lighting up our Christmas tree. Here, only with a static picture, but the simulated version in the video actually lights. Enlightened The MBSE Podcast Christmas Tree This can also be done much more amazing with more effort. Model simulations can be provided with graphical interfaces in order to play around with a system at an early stage before anything has been implemented.  Finally, here’s a little gift from us: our MBSE Podcast Christmas Tree model. You can download it as Cameo model or as an XMI model and you play around with it yourself. 019 MBSE Podcast Advent CalendarDownload The MBSE Podcast Christmas Tree XMIDownload Next year we will see and hear you again in the usual way. We will soon announce the first dates with new exciting topics via our website and social media channels Facebook, LinkedIn, Instagram, and Twitter. We wish you all a Merry Christmas, and a Happy New Year, and stay healthy! Der Beitrag Episode 19.24 – Merry Christmas! erschien zuerst auf The MBSE Podcast.

Broadcast date: December 23rd, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 23rd door of our MBSE Podcast Advent Calendar. Today, we show you some more aspects of the next-generation modeling language SysML v2. Yesterday we showed a simplified physical architecture of our Christmas tree in SysML v2. Today we will briefly look at requirements, the modeling of variants, and the SysML v2 API. First, let’s open our Jupyter notebook again. This a quick reminder of what we already have. It is a simple physical architecture that specifies the parts of our Christmas tree and their connections. Structure of the TMPCT Physical Architecture with SysML v2 Now we look at the requirements. We import a part of the requirements from the “International Christmas Standard” ICS-242526-12, which is modeled here with only one requirement. package ICS242526_12 { requirement def ReqTreeHeight { doc /* The tree shall be at least 150 cm and maximum 200 cm high. */ attribute treeHeight : ScalarValues::Integer; require constraint{ 150 <= treeHeight <= 200 } } } import TMPCT_PhysicalArchitecture::*; package TMPCT_Requirements { import ICS242526_12::*; requirement <'REQ1'> 'Height of the Tree' : ReqTreeHeight { attribute :>> treeHeight = theMBSEPodcastChristmasTree.tree.height; } } The ICS242526 requirement “ReqTreeHeight” is a requirement definition. It specifies the name “ReqTreeHeight”, the requirement text after the “doc” keyword, and an attribute “treeHeight” to formally specify the constraint that the height of the tree must be between 150 and 200. In the package “TMPCT_Requirements” we use the defined ICS242526 requirement. Our TMPCT requirement “Height of the Tree” is a usage of the requirement definition “ReqTreeHeight”. In addition, we specified a requirement ID “REQ1” and redefine the “treeHeight” attribute by setting it to the value of the appropriate value property of our Christmas tree. TMPCT Requirement with SysML v2 The visualization of the requirements is not very exciting. Among other things, because we have not used relationships. The diagram only shows the relationship “defined by”, which you already know from yesterday. Next, we have a brief look at how to model variants, because this is a hot topic in MBSE. First, we take our TMPCT physical architecture again.  The variability is defined in two additional packages. In the TMPCT_Variations package, we define an abstract “christmasTreeVariations” part that contains the variations which constrain the allowed variants. The keyword and concept “variation” in SysML v2 is similar to the concept of a variation point. For example, we specified that our part “christmasTreeStar” can have one of the three variants “ecoStar”, “premiumStar”, or “standardStar”. package TMPCT_Variations { import TMPCT_PhysicalArchitecture::*; import TMPCT_Variants::*; abstract part christmasTreeVariations :> theMBSEPodcastChristmasTree { variation part redefines christmasTreeStar { variant part ecoStar; variant part premiumStar; variant part standardStar; } variation part redefines christmasTreeStand { variant part largeStand; variant part standardStand; } abstract constraint { (christmasTreeStar == premiumStar & christmasTreeStand == largeStand) } } } package TMPCT_Variants { part ecoStar; part premiumStar { part ledLight; } part standardStar; part largeStand; part standardStand; } We also defined another variation for the part “christmasTreeStand”. In addition, we defined a constraint that specifies if the “premiumStar” variant is selected, you must also select the “largeStand” variant. The variants are defined in another package “TMPCT_Variants”. Very simple, we just defined the parts. Only the “premiumStar” part owns another part “ledLight”. The visualization of the model depicts some new special SysML v2 notation elements for the variants. It shows the specified variants of a variation by a relationship. SysML v2 Variations and Variants of the TMPCT Finally, we defined two products of our MBSE Podcast Christmas Tree: the “ecoTree” subsets the abstract part “christmasTreeVariations” and selects the “ecoStar” and the “standardStar” variants. The “premiumTree” selects the “premiumStar” and the “largeStand” variants. package TMPCT_Configurations { import TMPCT_Variations::*; part ecoTree :> christmasTreeVariations { part redefines christmasTreeStar = ecoStar; part redefines christmasTreeStand = standardStand; } part premiumTree :> christmasTreeVariations { part redefines christmasTreeStar = premiumStar; part redefines christmasTreeStand = largeStand; } } TMPCT Product Configurations with SysML v2 We close this episode with a brief look at the SysML v2 API. We can publish our model to a SysML v2 repository server which is provided by the company intercax. To have everything in one model, we put all our previous packages into one package called TMPCT. The %publish command posts the model to the intercax SysML v2 server. There, we can access our model via the SysML v2 API. Through the Swagger UI, you can use the API in a browser. As an example, we show how to view the list of projects in the SysML v2 repository. With the project number, you could then get the commits via the API and via the project and commit number, then the elements of the model. Swagger UI to access the SysML v2 API So much for the 23rd door of our MBSE Podcast Advent Calendar. We wish you a great 23rd of December. Der Beitrag Episode 19.23 – SysML v2 Requirement, Variants, and API erschien zuerst auf The MBSE Podcast.

Broadcast date: December 22nd, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 22nd door of our MBSE Podcast Advent Calendar. Today, we travel to the future and model our great MBSE Podcast Christmas Tree with the next-generation modeling language SysML v2. The SysML v2 is currently under development. It will be officially available probably in 2023 or 2024. So, there is still some time. However, it is already interesting to take a look at it now in order to set the course in good time. 2-3 years is a very short time in relation to major changes in the process and tool landscape in MBSE. The SysML Submission Team (SST for short) is currently working on the specification of SysML v2. What is great is, that they also provide a pilot implementation so that you can experiment with SysML v2. We use the pilot implementation based on Jupyter Lab to show you some more or less equivalent SysML v2 models of our Christmas tree. To avoid having to set up a Jupyter Lab environment yourself, my company oose provides a ready-to-use implementation at sysmlv2lab.com. Here you will also find a general introduction to SysML v2, the current state of the specification, and many examples. You can also create your own models and play around with them. But beware: From time to time, the server will be restarted and all files will be lost. If you want to save your models, you have to download them manually. We have already uploaded our Jupyter notebook for the MBSE Podcast Christmas Tree. SysML v2 offers a textual notation in addition to the graphical notation known from SysML v1. To create the models in the pilot implementation, one has to use the textual notation and can then generate the graphical notation automatically. Later there will probably be graphical editors for SysML v2 as well.  So, let’s have a look. package TMPCT_PhysicalArchitecture { part theMBSEPodcastChristmasTree { part tree { part trunk; part branch[1..*]; attribute height : ScalarValues::Integer; } part transportationNet; part christmasTreeStar; part christmasTreeStand; part fairyLights; part transportationPackage; part ball[1..*] : ChristmasTreeBall; part christmasBlanket; part powerManagementModule; part enjoymentControlUnit; } part def ChristmasTreeBall { enum def BallColor { enum red; enum blue; enum gold; } attribute color : BallColor; } } Our TMPCT – model is a simplified version of our SysML v1 physical architecture of the Christmas tree. We have directly modeled the parts. They have no explicit type. Simplified, in SysML v1, it would mean to define part properties without blocks. What works in SysML v2, but not in SysML v1, is that the parts can also define structures themselves, as you can see here, for example, with the part “tree” which defines the trunk, the branches, and a value property for the height of the tree. If no type is defined, however, a type from the system library of SysML v2 is implicitly set in the background. Also, a part always needs a context. If this is not given, for example, with our top-level part “theMBSEPodcastChristmasTree”, then the element “Anything” from the KerML base library is set as the context element. BTW: KerML is the metamodel of SysMLv2. For one part, we set the type. The part “ball” is of type “ChristmasTreeBall”, which is defined at the end. It contains the definition of an enumeration, which is then used to specify the attribute “color”.  So far, all we have is a list of things. The diagram is, therefore, also just a simple tree structure, which of course, fits perfectly with our Christmas tree project. TMPCT Parts with SysML v2 The graphical notation of SysML v2 is very similar to SysML v1. One difference in the diagram is the relationship between the part “ball” and the part definition “ChristmasTreeBall”. The relationship is a “defined by” relationship. package TMPCT_PhysicalArchitecture { part theMBSEPodcastChristmasTree { part tree { part trunk; part branch[1..*]; attribute height : ScalarValues::Integer; connect trunk to branch; } part transportationNet; connect transportationNet to tree; part christmasTreeStar; connect christmasTreeStar to tree; part christmasTreeStand; connect christmasTreeStand to tree.trunk; part fairyLights; connect fairyLights to tree.branch; part transportationPackage; connect transportationPackage to christmasTreeStar; connect transportationPackage to tree; connect transportationPackage to fairyLights; connect transportationPackage to powerManagementModule; connect transportationPackage to christmasTreeStand; connect transportationPackage to christmasBlanket; part ball[1..*] : ChristmasTreeBall; connect ball to tree.branch; part christmasBlanket; connect christmasBlanket to christmasTreeStand; part powerManagementModule; connect powerManagementModule to enjoymentControlUnit; connect powerManagementModule to fairyLights; part enjoymentControlUnit; connect enjoymentControlUnit to fairyLights; } part def ChristmasTreeBall { enum def BallColor { enum red; enum blue; enum gold; } attribute color : BallColor; } } Now we add some connections to our model. For this, we use simple connection relationships. If we visualize the model, we can see the structure of our Christmas tree. However, since the visualization is generated automatically, we cannot adjust the layout. TMPCT Connected Parts with SysML v2 So much for the 22nd door of our MBSE Podcast Advent Calendar. We wish you a great 22nd of December. Der Beitrag Episode 19.22 – Next Generation Christmas Tree with SysML v2 erschien zuerst auf The MBSE Podcast.

Broadcast date: December 21st, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 21st door of our MBSE Podcast Advent Calendar. Today, we take a look at the death of the actors. That doesn’t sound very Christmassy, but we need to talk about it. The actors died a long time ago. Curious? Let’s take a look at it in our model. TMPCT System Context Our system context diagram clearly shows actors. So who is dead here? We need to distinguish the concept “actor” from the SysML model element “actor”. The model element is dead, or rather we bury it. Why? Let’s take a closer look. So the concept of “actor” is great. So, external entities interact with the system and so on with all the methodological variants that exist. The SysML model element “actor” is problematic. It comes from UML and is there defined in such a way, that an Actor may not have any ports, receptions, operations, attributes, or parts. But these are features that are needed now and then. For example, our actor “power supply” has a port, or our actor “room” has a part “floor”. If we just claimed that a SysML actor couldn’t have that, why could we model that? SYSMOD Actor Stereotypes Because we did not use the SysML actor. As mentioned at the beginning, the actor is dead respectively nonexistent to us. Formally, our actor kinds from the SYSMOD profile are stereotypes specializing the SysML block. The stereotypes define the appropriate actor semantics. This is not a nasty workaround but is formally mapped correctly. Even the SysML specification uses this kind of actor modeling in its example Hybrid SUV model. Thus, actors have the same capabilities as blocks and can have ports, internal structures, and so on. So we have by no means trashed the concept of the actor, but the SysML model element. The Actor is Dead! Long live the Actor! So much for the 21st door of our MBSE Podcast Advent Calendar. We wish you a great 21st of December. Der Beitrag Episode 19.21 – The Death of the Actors erschien zuerst auf The MBSE Podcast.

Broadcast date: December 20th, 2021 You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts. Welcome to the 20th door of our MBSE Podcast Advent calendar. Today, we take a look at non-SysML views.  SysML defines 9 different diagram types, such as the use case diagram, the block definition diagram, and so on. Additionally, tables and matrix views are defined. Other views are perfectly possible, even if they are not covered by the standard. Let’s have a look at some of them. The Relation Map Diagram is a special diagram of the Cameo Systems Modeler. Starting from one element, a tree is spanned based on defined relationships. In this example, all elements that are in the namespace of the previous node are shown. It shows all use cases in the selected package and then all contained use case activities. Relation Map Diagram The classic is, of course, Excel. Some modeling tools offer directly out-of-the-box exporting model elements to Excel. Some can also make the return trip and import Excel data into the model. Excel export TMPCT Use Cases Needless to say that you can also generate text documents from models. The text document is another special view of the model. Other interesting views are dynamic diagrams such as those offered by the graph database neo4j. The Syndeia tool from intercax can export SysML models to neo4j. There, the model can then be viewed in the dynamic graph diagrams, for example, to identify patterns and derive insights. MBSE for Electronic Voting System Security – Part 6 (MagicDraw or Rhapsody with Neo4j) So much for the 20th door of our MBSE Podcast Advent Calendar. We wish you a great 20th of December. Der Beitrag Episode 19.20 – Non-SysML Views erschien zuerst auf The MBSE Podcast.