Variant Modelling
Scarecrow MBSE Extravaganza Day 2 – Wednesday 20 February 2019
Copyright © 2019
Overview
I. Introduction
– Context
II. Problems
– Lots of approaches, duplication, non-triviality
III. A Solution
– Requirements, overview, concepts, example
IV. Summary & Questions
Copyright © 2019 1
I : Introduction
Copyright © 2019
1. Context – Three-plus-two Packages
Copyright © 2018 3
ImplementationApproach System
Process Set
Tool
Visualisation
Framework
Ontology Viewpoint
ModelSystem
View
Notation
Diagram
Compliance
Standard
1..*
1..*
implements
1..*
1
abstracts
1..*
1..*complies with
1..*
1
is consistentwith
1..*
1 1..*
1..*
complies with
1..*
1..*
visualises
1
1..*
is based on
1
1..*
implements
1..*
1..*describes how
to use1..*
1
is consistentwith
1..*
1
defines templatefor
1..*
1..*
2. Context – Evolution
Copyright © 2019 4
Stage 1: Document-
based
Stage 2: Document-
centric
Stage 3: Model-
enhanced
Stage 4: Model-centric
Stage 5: Model-based
II : Problems
Copyright © 2019
1. Which approach to use?
• Lots of approaches out there • Feature Oriented Domain Analysis (FODA)
– Old (1990)
• Common Variability Language (CVL) – Intended to be an OMG standard; no longer
• Orthogonal Variability Model (OVM) – Implemented in some tools
• VAriant MOdeling method for SysML (VAMOS) – Tim Weilkiens
• SysML 2.0 – Not yet released
Copyright © 2019 6
2. Common Problems
• Duplication of effort – Model the System
– Model the variants separately
– Map variant model to System model
• Non-standard notion – FODA, CVL, OVM
• Somewhat unclear definition – VAMOS
• Not supported by all tools
Copyright © 2019 7
3. Variant modelling is non-trivial
• SCL tried and failed twice
– Tried to adopt existing approaches to way we work
– This is an example of the Tool leading the Process
• Often organisations want to apply it in wrong place
– In MBSE, walk (and jog) before run
– VM is running
Copyright © 2019 8
Attempt in the correct stage
Copyright © 2019 9
Stage 1: Document-
based
Stage 2: Document-
centric
Stage 3: Model-
enhanced
Stage 4: Model-centric
Stage 5: Model-based
III : A Solution
Copyright © 2019
1. Requirements
• Must use our existing notation (SysML)
• Must use our standard approach (Ontology & Framework)
• Must not require duplication of effort – Variation aspects must be able to be added to existing
System model, not modelled separately
• Must support some level of automation, e.g. – Automatic checking of conformance to approach
– Extracting an actual variant, as a new model, (semi-) automatically from the variation-annotated model
Copyright © 2019
2. Overview of the Scarecrow Approach
• Approach assumes: – You have a model of your System
– You are using a Framework with an Ontology and defined Viewpoints (defined using the Framework for Architecture Frameworks – FAF)
– You want to annotate your model with Variant Modelling information
• Approach defines a number of key concepts
• These now discussed and examples given
Copyright © 2019 12
3. Key Concepts & Examples
• Variation Points – What allowed to vary, in terms of Ontology & Model
Elements
• Variation Elements – The options available to vary a specific Model
Variation Point
• Variant Configurations – The possible configurations that can be made from
regular Model Elements and Variation Elements
• Variant Configuration Instances – Example instances of Variant Configurations
Copyright © 2019 13
Key Concepts & Examples (cont.)
• Viewpoint Sets – Used in definition of Variants (see below) – Define all the types of Viewpoint that a given Model
Element can appear on; deterministic, based on Framework
• Variants, View Sets and View References – Used when want to extract a Variant Configuration from a
model – A Variant shows what actual Views (instances of
Viewpoints) contain the model information for a given Variation Element and its constituent elements
– These Views are represented as View References that are collected into View Sets
Copyright © 2019 14
Variation Points
Copyright © 2019 15
«ontology element»System
«ontology element»Subsystem
«ontology element»Part
«ontology element»Part Port
«ontology element»Subsystem Port
«ontology variation point»System VP
«ontology variation point»Subsystem VP
«ontology variation point»Part VP1
«ontologyrelationship»interacts with
1..*
«impacts»
1..*
1
«ontologyrelationship»interacts with
1..*
«impacts»
«impacts»
«identifies»
«identifies»
0..*
«identifies»
1..*
Only Systems, Subsystems & Parts can be
varied
Subsystem Ports & Part
Ports can NOT be varied
Steam Beam Engine and Building are Systems that
vary
«system,model variation point»Steam Beam Engine
«ontology variation point»System VP
«system,model variation point»Building
«conforms to»
1
is housed in
1
«conforms to»
«impacts»
Variation Elements
Copyright © 2019 16
Abstract, must have defined
Variation Elements
Boiler must be EITHER a Coal-fired
Boiler OR a Gas-fired Boiler
Fuel Source must be EITHER Coal OR Gas
If Coal-fired Boiler chosen, then Fuel Source MUST be
Coal
«subsystem,model variation point»Boiler
«subsystem,variation element»Gas-fired Boiler
«subsystem,variation element»Coal-fired Boiler
«part,model variation point»Fuel Source
«variation element,part»Gas
«variation element,part»Coal
«XOR»
«XOR»
«XOR»
«requires»
«requires»
«XOR»
Variation Elements can have structure defined
Copyright © 2019 17
Single Beam System MUST have Gas-
fired Boiler Subsystem
«variation element,system»Single Beam
«subsystem»Steam Cylinder
«subsystem»Beam
«subsystem»Boiler Feed Pump
«subsystem»Condenser
«system,model variation point»Building
«subsystem»Water Pump
«subsystem,variation element»Gas-fired Boiler
1
takes steam from
11
powers
1
11
1
«identifies»
1
recycles water into
1
«requires»
1
1
moves
1
1
provides water for
1
wp 1
1
1provides steam for
1
Must have a Building but not specific about the actual Variation Element, hence use a Model Variation Point
Variant Configurations
Copyright © 2019 18
Two concrete Variant Configurations defined. Both are made up of a Single Beam through the abstract Variant Configuration, Single Beam System Set-up. Single Beam System Set-up #1 requires that the Single Beam is in a Shed. Single Beam System Set-up #2 requires that the Single Beam is in a Museum.
An (abstract) Model Variation Point MUST be replaced by a (concrete) Variation Element within a Variant Configuration
«variation element,system»Single Beam
«variation element,system»Shed
«subsystem»Steam Cylinder
«subsystem»Beam
«subsystem»Boiler Feed Pump
«subsystem»Condenser
«subsystem»Water Pump
«subsystem,variation element»Gas-fired Boiler
«part»Burner
«part»Boiler Chamber
«part»Chimney
«variation element,part»Gas
«variant configuration»Single Beam System Set-up #1
«variant configuration»Single Beam System Set-up #2
«variant configuration»Single Beam System Set-up
«system,model variation point»Building
«variation element,system»Museum
«identifies»
1
1
1
1
«requires»
wp 1
1
1
«XOR»
1
«requires»
1
1
«requires»
1
«requires»
«XOR»
1
Variant Configuration Instances
Copyright © 2019 19
«variant configuration»Single Beam System Set-up #1
«variant configuration instance»Swansea Site
«variant configuration instance»Crofton Site
«variant configuration»Single Beam System Set-up #2
«variant configuration instance»Wolverhampton Site
«instance of»
«instance of»
«instance of»
There are two instances of Single Beam System Set-up #1, one in Swansea and one in Wolverhampton. Both of these will be in Sheds (as per Variant Configuration Single Beam System Set-up #1)
There is a single instance of Single Beam System Set-up #2, in Crofton. This will be in a Museum (as per Variant Configuration Single Beam System Set-up #2)
Viewpoint Sets
Copyright © 2019 20
We know System can appear on these Viewpoints (from our AF), so…
«ontology element»System
«viewpoint»System Identification
Viewpoint
«viewpoint»System Types Viewpoint
«viewpoint»System Configuration
Viewpoint
«viewpoint»System Behaviour Viewpoint
«viewpoint»Interface Identification
Viewpoint
«viewpoint set»System Viewpoint Set
«ontology variation point»System VP
1..*
1
«contains»
1..*
defines behaviour for
1
«contains»
1..*
«contains»
1
0..*
1..*defines configurations for
1
«contains»«identifies»
1defines types in
1
«contains»
System has an associated Ontology Variation Point, so MUST have…
… a Viewpoint Set for System
…we know which Viewpoints appear in the Viewpoint Set
Variants, View Sets & View References
Copyright © 2019 21
«variant»Single Beam
«variation element,system»Single Beam
«view set»Water Pump Views
«subsystem»Steam Cylinder
«view reference»System Identification View
«subsystem»Beam
«subsystem»Boiler Feed Pump
«subsystem»Condenser
«subsystem»Water Pump
«subsystem,variation element»Gas-fired Boiler
«view set»Boiler Pump Views
«view set»Steam Cylinder Views
«view set»Beam Views
«view set»Condenser Views
«variant»Gas-fired Boiler
«view reference»System Configuration View
«view reference»Subsystem Types View
«specifies»«specifies»«uses»
«specifies» «configures»«specifies»«specifies»
Every Variation Element MUST have an associated Variant
Variant contains View Sets that specify relevant Views for all Model Elements in the Variation Element
The Views in a View Set are represented by View References (omitted for some of the View Sets here for clarity)
Single Beam is made up of another Variation Element Gas-fired Boiler. This will be configured by the Variant Gas-fired Boiler, but from p.o.v. of Single Beam the «uses» shows that its Variant does not specify the View Sets (& hence View References) for Gas-fired Boiler.
IV : Summary & Questions
Copyright © 2019
Summary • Variant modelling is hard • Must tackle it in the correct stage of your MBSE evolution
– Not too early
• Many flavours exist; need to choose for yourself, but be aware of: – Duplication – Non-standard notation – Unclear definition
• Scarecrow have a solution that: – Uses SysML – Annotates your existing model – Is not tool-specific – Can support automation
Copyright © 2019 23
Questions?
Copyright © 2019 24