variant modelling - scarecro · through the abstract variant configuration, single beam system...

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


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


Variation Points


«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


«system,model variation point»Building

«conforms to»

1

is housed in

1

«conforms to»

«impacts»

Variation Elements


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


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


«subsystem»Water Pump


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


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»Shed


«subsystem»Beam





«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


«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



«variant configuration instance»Swansea Site

«variant configuration instance»Crofton Site


«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


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


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


«variant»Single Beam


«view set»Water Pump Views


«view reference»System Identification View

«subsystem»Beam





«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.

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


Questions?


variant modelling - scarecro · through the abstract variant configuration, single beam system...

Documents