The 5 Principles of Model Based Systems Engineering

1. The 5 Principles of Model Based Systems Engineering James Towers Object Flow Ltd Chair INCOSE UK MBSE Working Group

2. The 3 Evils (from Holt & Perry)

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)

4. 2 - Complexity (Plus Simplicity, Complicated and Chaotic) • 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)

5. The 3 Spaces Defines the Problem or Opportunity e.g. User Requirements Problem Space Solution Space Specifics the Solution e.g. System Requirements Project Space Shapes the Activity The Organisations, People, Processes, Standards and Tools used to perform the SE Activity Time

6. Cynefin Sense MakingFramework

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

8. The 5 Principles

9. 1 – Modelling is more than just drawing

10. 2 – Each View has a defined purpose and scope • 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

11. 3 – The Model adds value • 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.

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

13. 5 – The Model is constructed from the most appropriate elements • 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

14. The 4 Enablers

15. 1 - Architectural Frameworks • 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

16. 2 - Process 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

17. 3 - People • The People involved have the appropriate competencies

18. 4 - Tools • 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

19. Questions

20. Acknowledgments • 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)