the principles of model-based systems engineering...– modern methods of systems engineering jenny...

The Principles of Model-Based Systems Engineering

James Towers

Chair INCOSE UK MBSE Working Group

Copyright © 2016

• The 3 Evils of Systems Engineering

• MBSE Definitions

• The Principles

• The Enablers

• The Benefits

• Questions

Agenda

Copyright © 2016 2

The 3 Evils of Systems Engineering

Copyright © 2016 3

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)

Copyright © 2016 4

2 - Complexity (Plus Simplicity, Complicated and Chaotic)

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

– "English does not contain a suitable word for 'system of problems.' Therefore, I have had to coin one. I choose to call such a system a mess”

• Russell L. Ackoff, Redesigning the future, 1974

• It is useful to make a distinction between how we define structures and behaviour

• We can define at least 4 different patterns of system behaviour

– Simple(or Obvious) = 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)

Copyright © 2016 5

The 3 Spaces (or Systems)

Problem Space

Problem Space

Defines the Problem or Opportunity The “Context System” i.e. UK Transport Network

Specifics the Solution The “Modified Context System” i.e. UK Transport Network + HS2

Shapes the Activity The Organisations, People, Processes, Standards and Tools used to perform the SE Activity The “Realization System” i.e. HS2 Ltd et al.

Solution Space

Solution Space

Project Space

Project Space

See - The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems, Martin 2008

Copyright © 2016

• For every 25% increase in problem complexity, there is a 100% increase in solution complexity. (Woodfield, 1979)

• Conway’s Law:

– A system reflects the organizational structure that built it.

– Intended as a joke, but turns out to be true! (Herbsleb et al 1999)

Why is this important?

Copyright © 2016 7

Cynefin Sense Making Framework

Copyright © 2016 8

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 they require

• Even when we understand (or think we understand) each others needs this can be hindered by a lack of a common language

9

MBSE Definitions

10

• The formalised application of modelling to support:

– System requirements,

– Analysis,

– Design, and

– V&V activities.

• Beginning in the conceptual design phase and continuing throughout development and later lifecycle phases.

INCOSE Definition

Other?

i.e. “all phases”

Copyright © 2016 11

• “Model-based systems engineering is an approach to realising successful systems that is driven by a model that comprises a coherent and consistent set of views that reflect multiple viewpoints of the system”

• SysML for Systems Engineering, 2nd Edition: A model-

based approach

• Jon Holt & Simon Perry

A complementary definition:


The Principles

13

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 & View

Author: James Towers

Version: 1.0

Created: 09/09/2013 18:59:04

Updated: 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)

– “Essentially, all models are wrong, but some are useful.”

• George Box, Empirical Model-Building and Response Surfaces (1987)

• Purposes include Synthesis, Analysis, Specification, Communication and others

• Scopes include the Problem, Solution and Project Spaces

• By constraining the Purpose and Scope of a View to a particular Viewpoint it allows us to manage the complexity

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


4 – The Model is of sufficient quality

• 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

See: “The Advanced Modeler’s [sic] Practical Glossary”, Stambouly (2014)


5 – The Model is constructed from the most appropriate elements

• 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

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


6 – Everything we claim to ‘know’ is within the model

• The Model is: – An abstraction of a System of Interest constructed from one or

more Representations. The Model is the total recorded knowledge of the project i.e. a single point of reference. Ideally it will be in one place but in practice may be distributed across multiple tools or repositories.

• The model is not: – Just the stuff written in SysML (or other modelling language) – Just the stuff in the ‘modelling tool’

• Because: – We get the most benefit when we apply these principles to our

entire project knowledge


The Enablers

20

• The features of a useful modelling languages are: – Well defined and relevant constructs

– It’s readable

– It’s standardised

– It’s reusable

– Inherent and scalable structure

– Separation of concerns

– Appropriate paradigms and topologies

– Appropriate abstraction mechanisms

– Facilitates communication amongst stakeholders

1 – Modelling Languages


• 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 partitioning and hiding

– Helps us identify omissions

– Provides traceability & navigability

– Aids communication as may be common across multiple projects

– Define ontologies and standardises concepts

2 - 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

3 - Process Frameworks


• The People involved have the appropriate competencies

4 - People

Behaviour (Cynefin)

Practices Work Type Skill Level How to Achieve

Simple Best “Assembly Line” Proficiency Training

Complicated Good Information Fluency Training & Experience

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 underlying representation of the Views 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

5 - Tools


The Benefits

26

Benefits

• Improved understanding – Allows us to systematically explore “unknown”

quadrant of Johari window

• Ability to better manage complexity – By use of structure, abstraction and separation of

concerns

• Improved communication – With project stakeholders, between engineering

disciplines and across spoken language barriers – Reduces knowledge in “blind” and “hidden” quadrants

of Johari window


• Improved quality – Early identification of requirements issues – Consistent documentation, both within and across projects

• Increased productivity – Reuse of existing models to support design and technology

evolution – Automated generation of documentation – Common definitions means changes are made in fewer places

• Reduced risk – Improved cost estimates – Early and on-going requirements validation through inspection,

and design verification through the use of simulation and automatic verification

– Improved systems assurance

Which lead to…


• Websites:

– MBSE Working Group Wiki • www.incosewiki.org.uk/Model_Based_Systems_Engineering/

– OMG MBSE Wiki • www.omgwiki.org/MBSE/

• Books – A Practical Guide to SysML - The Systems Modeling Language Friedenthal, Moore & Steiner

– A Primer for Model-Based Systems Engineering Long & Scott

– Modern Methods of Systems Engineering Jenny et al.

– SysML Distilled - A Brief Guide to the Systems Modeling Language Delligatti

– SysML for Systems Engineering - 2nd Edition: A Model-Based Approach Holt & Perry

– Systems Engineering with SysML/UML - Modeling, Analysis, Design Weilkiens

Further resources


http://www.incosewiki.org.uk/Model_Based_Systems_Engineering/



http://www.omgwiki.org/MBSE/



Questions


• Thanks to the following for their contributions, either directly or via published work

– Tom Riley (Thales)

– Prof Jon Holt and Simon Perry (Scarecrow)

– Prof Dave Snowden (Cognitive Edge)

Acknowledgments


the principles of model-based systems engineering...– modern methods of systems engineering jenny...

Documents