Tim Weilkiens

Avatar

Tim Weilkiens, Managing Director of the German consulting company oose (http://www.oose.de), is a member of the OMG working groups about SysML and UML and has written sections of the SysML specification. He is a content developer of the OCEB and OCSMP certification program. He is well known for developing the SYSMOD methodology (http://www.sysmod.de). He is involved in the INCOSE MBSE activities and co-founder of the MBSE Challenge Team SE^2 Telescope Modeling (http://mbse.gfse.de/). Tim Weilkiens is Model based system engineering blog author (www.model-based-systems-engineering.com). He is author of several articles and books, e.g. about the SysML (http://www.system-modeling.com), UML, Business Process Management, and MBSE.

Aug 052014
 

Many systems exist in different configurations. A product line, a custom product or different designs for trade-off studies. The current version 1.2 of SysML doesn’t provide explicit built-in language constructs to model variants. The profile mechanis of SysML can be used to extend SysML with a concept for variant modeling.

I’ve defined a simple variant profile that consists of three core stereotypes and some additional optional extensions. The core stereotypes of the SYSMOD variant profile are:

  1. A variation point marks a core element as a docking point for a variant element. A core element is an element that is valid for all variants.
  2. A variation contains a set of variants that have a common discriminator.
  3. A variant is a complete set of variant elements that varies the system according to the variation discriminator. A variant is also known as a feature of the system.
Variant modeling example with SYSMOD profile

Variant modeling example with SYSMOD profile

At least one element in the variant package is connected with the variation point. The relationship is typically a generalization, but could also be another one, e.g. a derive relationship between requirements.

Maybe you already know the common feature trees to describe variations (e.g. FODA). You can also use SysML with the SYSMOD variant profile to create feature trees:

SYSMOD variant example: Variant feature tree

SYSMOD variant example: Variant feature tree

 

OPTIONAL ADDITIONAL VARIANT ELEMENTS

There are two new elements in the variant feature tree to add constraints to the possible feature configurations. {xor} and {requires} are SysML constraints to model rules between variants of the same or different variations. In our example the password-based customer identification requires a visual user interface, e.g. some kind of a display. And it is not allowed to select the barcode and the fingerprint customer identification feature at the same time ({xor}, exclusive or).

The min/max values are properties of the variation stereotype. They control the number of variants of the variation that can be selected for a single system configuration. For both variations in our example you must select at least one feature, but could also select two of them, e.g. a system that provides two different ways of customer identification.

Finally we need a model element to store a single system configuration. Unfortunately the current SysML version 1.2 doesn’t have a generic grouping mechanism. There are some ideas in the SysML working group of the OMG to add such a construct in a future SysML version. I use a stereotyped block with trace relationships to define a system configuration:

SYSMOD system configuration example

SYSMOD system configuration example

Although the stereotypes are simple and powerful it’s a challenge to handle the complexity of the model. Even a system model without variants could be a challenge. With variants it is a multidimensional configuration space. Special views, reports and model transformations are helpful to manage the complexity.

This article was originally published in Model Based Systems Engineering Blog by Tim Weilkiens

Jul 252014
 

Many companies deal with the challenge to introduce MBSE. As a consultant for MBSE I often ask my customer about their objectives to apply MBSE techniques. The answers are more or less the same: the systems are getting more complex and at the same time we must decrease costs and time-to-market and increase the quality.

These are good arguments to change development processes and to apply MBSE. However these arguments are not new. I would had heard the same arguments 20 years ago. Today something is different. There is an enormous pressure on the companies that require major changes.

We are at the beginning of a new era characterized by global cooperations, networking, and global markets with customers, users, and competitors from different cultures with completely different mindsets. We develop complex systems with complex development organizations for complex markets.

The methods & tools to develop these systems must follow the systems challenge curve. The curve for the methods & tools is below the system curve. The gap is filled by the intelligence of the engineers (“project heroes”). Of course we are always better than our methods & tools allow. But the gap is getting wider and wider. Many organizations already feel the pain from the gap.

Systems Challenge Curve

Systems Challenge Curve

I think there are two fundamental techniques to shorten the gap. Agile methods and Modeling. Agile methods focus on the – often home made – complexity of the organisation to develop a system. Modeling focus on the inherent complexity of the system itself. That’s why I believe that it is important for many companies to introduce MBSE.

This article was originally published in Model Based Systems Engineering Blog by Tim Weilkiens