The 5 principles of Model Based Systems Engineering (MBSE)

The 5 Principles of MBSE 1

The 5 Principles of Model Based Systems Engineering

James Towers

Object Flow Ltd

Chair INCOSE UK MBSE Working Group


The 3 Evils (from Holt & Perry)


1 – A Lack of Understanding (Unknown Unknowns)

Applies to both individuals and organisations (projects)

The dip in productivity corresponds with the body of the “Brontosaurus of Complexity” (Holt & Perry)

“There are unknown unknowns – there are things we do not know we don't know” (Donald Rumsfeld)


We often use the word complex as a synonym for ‘difficult’ or ‘no recognisable pattern’

We should make a distinction between how we define structures and behaviour

We can define at least 4 different behaviours of systems Simple = easily knowable Complicated = not simple, but still knowable Complex = not fully knowable, but reasonably predictable Chaotic = neither knowable nor predictable

Each of the 3 spaces (Problem, Solution & Project) can behave in a different way (and at different points in time)

2 - Complexity (Plus Simplicity, Complicated and Chaotic)


The 3 Spaces

Problem Space

Defines the Problem or Opportunity

e.g. User Requirements

Specifics the Solution

e.g. System Requirements

Shapes the Activity

The Organisations, People, Processes, Standards and Tools used to perform the SE Activity

SolutionSpace

ProjectSpace

Time


Cynefin Sense Making Framework


3 - Communication - I don’t know what you need to know

We can’t rely on a process to tell us what artefacts to produce and who to give them to

We can’t rely on request - response protocols because other stakeholders in the project may not even know we exist, let alone what information we have or require


The 5 Principles


bdd [Package] Model, View & Diagram [Model & View]

«block»Model

«block»View

«block»Model element

«block»View element

«block»Diagram

«block»System

«block»Graphical Symbol

«block»Text

«block»Mathamatical

Language

«block»Architecture

«block»Matrix

«block»Table

«block»Text Document

Name: Model & ViewAuthor: James TowersVersion: 1.0Created: 09/09/2013 18:59:04Updated: 06/10/2013 16:28:29

1

abstracts

1..*

1..*

represents

1

1..*

is a projection of

1

1..*

1

1..*

1

1..*

1

0..*

is related to

0..*

1 – Modelling is more than just drawing


There’s a temptation when building models to first model everything you know and then model everything you discover

It’s important to remember that every model is in someway incomplete, and it’s this incompleteness that makes it valuable (See Principle 3). Knowing what to omit requires you to know what its purpose is If someone wanted to know how far it was from Tooting Bec to Edgware

then consulting the Tube map would be pointless (it wasn’t built for that purpose)

Purposes include Synthesis, Analysis, Specification, Communication and others

Scopes include the Problem, Solution and Project Spaces and others

2 – Each View has a defined purpose and scope


The Model is insightful: It can be queried in ways unconnected sources can’t. It can be navigated, thus allowing us to discover its content without prior

knowledge of what to expect.

The Model is more accessible, quicker, cheaper, controllable, adaptable or less risky (in a safety, security and financial sense) to construct and/or interrogate than the real world.

The Model is pragmatic: The degree to which it conforms to any of these principles is decided based on risk.

3 – The Model adds value


The Model is: Concise -

It records one fact in one place (Model Element) Consistent -

It doesn’t contradict itself Coherent -

Its parts produce a unified whole Correct –

It can be Verified and Validated based on defined criteria It uses abstraction to allow imprecision without inaccuracy

4 – The Model is of sufficient quality


Where appropriate the Model is constructed using recognisable and documented patterns May be public or proprietary, general or domain-specific

The Model uses the most appropriate languages, paradigms & topologies Languages may include natural language (text), mathematics, general

purpose graphical languages (UML, SysML), domain-specific languages and others

Paradigms may include functional, object-oriented, symbolic, logical and others

Topologies may include graphs, trees, matrices, tables, natural-language (requirements boilerplates) and others

5 – The Model is constructed from the most appropriate elements


The 4 Enablers


May be public or proprietary, general or domain-specific Architectural Frameworks enable MBSE by:

Ensuring the Model is coherent and consistent, by providing architectural rules and syntax

Help us manage complexity and clarify what is important by the use of information portioning and hiding

Helps us identify omissions Provides traceability & navigability Aids communication as may be common across multiple projects Define ontologies and standardises concepts

1 - Architectural Frameworks


Process Frameworks provide guidelines and principles that allow us to generate a customised process

Where appropriate the Enterprise uses recognisable and documented process patterns

The Project Team follows a defined System Engineering Process based on one or more of the Process Frameworks All activities within the process involve the Model. All newly discovered Systems Engineering knowledge is recorded in the

Model. The Model is shared in a controlled manner

Configuration / Version Control Access Control – although the default is open

2 - Process Frameworks


The People involved have the appropriate competencies

3 - People

Complexity (Cynefin)

Practices

Work Type Skill Level

Hot to Achieve

Simple Best “Assembly Line”

Proficiency Training

Complicated

Good Information Fluency Training & Expereince

Complex Emergent

Knowledge Literacy Deliberate Practice

Chaos Novel Concept Mastery Deliberate Practice(10,000 hrs)


The tools used have the appropriate capabilities There is a single Model of the System Under Consideration (SUC) i.e.

they’re modelling not drawing tools They support the required languages, paradigms and topologies and

ideally (where possible) can translate between them They support open standards and data formats

4 - Tools


Questions


Thanks to the following for their contributions, either directly of via published work Tom Riley (Thales) Jon Holt and Simon Perry (Atego) Dave Snowden (Cognative Edge)

Acknowledgments