Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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:
Copyright © 2016 12
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
Copyright © 2016 14
• 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
Copyright © 2016 15
• 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
Copyright © 2016 16
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)
Copyright © 2016 17
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
Copyright © 2016 18
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
Copyright © 2016 19
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
Copyright © 2016 21
• 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
Copyright © 2016 22
• 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
Copyright © 2016 23
• 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.)
Copyright © 2016 24
• 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
Copyright © 2016 25
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
Copyright © 2016 27
• 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…
Copyright © 2016 28
• 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
Copyright © 2016 29
Questions
Copyright © 2016 30
• 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
Copyright © 2016 31