Variant Modeling with SysML

Variant Modeling with SysML

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


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.



3 Responses

  1. Markus Schacher says:

    How does this relate to OMG’s Common Variability Language (CVL)?

    • The basic concept is similar. Both – CVL and SYSMOD – separate the common part from the system parts that are only valid for a specific variant. The main difference is that CVL stores the core part and the variant part in different models. In SYSMOD both parts are in the same model separated by the package organisation.

  2. Find Tim’s method applied in a more abstract example in German on my blog at

Leave a Reply

Your email address will not be published. Required fields are marked *