Systems Thinking and Systems Engineering

1. Systems Thinking and Systems Engineering What to model at what level? Borders between system and environment. 29 January 2013 Francois Christophe Galina Medyna Eric Coatanéa

2. Objectives of the lecture Being able to know what to model and being able to select appropriate modelling approaches Practice the approach and concepts on your projects

3. Outline of the lecture Context and some important concepts (Eric) Model Based Systems Engineering (Francois) An example of a modelling approach, SysML(Francois) Conclusions

4. Context and some important concepts (Eric)

5. Context (1/17) Cartesian paradigm System paradigm • Each system is defined according to the explicit and implicit intentions of the modeler. • A system is a part of a super system. • Relativity and contingency of the causality principle, the important aspect is the study of the behavior and of the objectives. • Analyzing the environment of a system involves the analysis of the objectives of a system. • Conscious limitation of the analysis of systems on viewpoints and justifications about the choices of these viewpoints. • Objectivity, rationality and logic of the objectives are pre-supposed • A system is the sum of its parts (reductionism) • Invariability of the causality principle • Possibility to describe exhaustively and completely a system are pre-supposed • Specialization of the task is required Versus

6. Context (2/17) System Thinking VS cartesian paradigm? « We define more usefully a polar bear by the conjunction of: - a project: survive by functioning - an environment: the Arctic continent than by analyzing the structural anatomy of this bear... » H.A. Simon

7. Context (3/17) Some concepts that might support a system approach • Interactions • Cause/effect, • 3 levels of causality: - Direct causality, causality with feedback, recursive causality (the effects are necessary to the process generating them). • Loops (balancing, reinforcing), • Flow (Energy, material, information), Stocks (Energy, material, information), • Function (Service, constraint, sub-function, technical) and Structure • Requirements (functional, non-functional or quality requirements), • Contradictions, conflicts, • Stability, un-stability, • Etc…

8. Context (4/17) System Thinking is the attempt to use the system thinking paradigm for problem solving, by viewing "problems" as parts of an overall system, rather than reacting to specific part, outcomes or events and potentially contributing to further development of unintended consequences.

9. Evolution Structure Functioning (activity) Context (5/17) A GENERAL SYSTEM is an artifact (artificial object) evolving in a certain environment with a purpose (a finality). This artifact is functioning (doing activities) and its internal structure evolves over time, without losing its structure. Objectives (goals) Environment

10. How is it transformed overtime? (evolution) Why this system is developed? Objectives (goals) Where is the system located and what is its environment? What is the structure of the system? How does it function? What types of flows and relations exist between the elements? (energy, information or material) Context (6/17) Questioning about the System Thinking paradigm?

11. Context (7/17) At each question is corresponding a representation (model). Each of the representation is using a language Using a graphical representation when possible help

12. Context (8/17) Brief: A document describing the context, problem, goals Traditional layout of a brief: 1- History Company history 2- Company Profile Specializations Past Accomplishments 3- Problem Statement Problem Description Constraints Budget Time Needs of the Problem 4- Goals What you plan to accomplish Due dates Risks/Benefits 5- Summary

13. Context (9/17) Needs (Why is this system developed?) To whom is the system useful? On what is the system acting? Team/ University Fake Fruits and vegetables System:Autonomous robot What is the goal of the product or service? To harvest as much as possible of fruits and vegetables in 90s

14. Context (10/17) • The 5 Whys: • The five whys is a question asking method used to explore the cause/effect relationships underlying a particular need. The goal is to determine a root cause of a need. • Example: • We need a new machine to clean our house. (the need) • Why? The actual vacuum cleaners are not satisfying. (first why) • Why? The dust is constantly present in the house. (second why) • Why? The air is full of dust particles. (third why) • Why?The vacuum cleaner is rejecting air particles. (fourth why) • Why?The air filter is inefficient. (fifth why, root cause) Sakichi Toyoda

15. Context (11/17) Summarizing the ideal need in form of a causal graph Need: To ensure the health of teeth and mouth Ideal Need + Coloring Coffee + Cigarette Tartar deposit + Food deposit Food + + + Acidity Halitosis (bacteria) + + + Age Caries Receding gums + + Infections (Yannou, 2010)

16. Context (12/17) Compare ideal need VS existing Conventional toothpaste Ideal Need + Coloring Coffee + Cigarette Tartar deposit + Food deposit Food + + + Acidity Halitosis (bacteria) + + + Age Caries Receding gums + + Infections Conventional toothpaste (Yannou, 2010)

17. Context (13/17) Types of requirements A good requirement model should answer the following questions: – What is the system supposed to do and not to do? – How well must it do what it does? – What is available and allowable to build the system? – How well resources have been utilized? – What are the trade-offs between performance and cost? – How can it be proven that the as-built system meets expectations? Input / Output Requirements Performance Requirements Technology Requirements Cost Requirements Trade-off Requirements Test Requirements • (Wymore, 1993)

18. Context (14/17) Functional perspective In the functional/logical viewpoint: A requirement can be functional or non-functional? A function can be seen as an INTERFACE between two elements of the environment. In the representation popularized by Pahl and Beitz, a function is an interface between two types of flows.

19. Context (15/17) Functional perspective The functions exhibit a structure (dependency between functions and hierarchy of functions) F F1 F1 F3 F21 F2 F1 F1 F2 FA F22 F22 F22 F21 F3 F22 Functional tree Coupling matrix Functional structure

20. Context (16/17) Functional perspective Need Functions Should provide Service Are implemented by Constraints Function Service Function Deliver Are fulfilled by Are implemented by Technical Function Structure Exist in form of Effect Function Transformation Function Allocated to Non-functional requirement

21. Context (17/17) Functional perspective It is possible to imagine how the transitions between functioning modes are organized. Charge when stopped In the example of the hybrid vehicle, 6 main modes have been listed and are allowed by the architecture.

22. What is Model Based Systems Engineering?(Francois)

23. What is Model Based Systems Engineering? Term first coined by A. Wayne Wymore, Ph.D. Mathematician, INCOSE Pioneer Established grounds for SE Set-theoretic approach: • Defines necessary and sufficientinformation set for SE in canonicalform [Wymore, 93]

24. Why models in Systems Engineering? SE involves making decisions under risk and uncertainty The core activity of SE is to define the problem • Solving it is only secondary (primary in engineering design) Models are meant to support this decision making: • By embedding all known information about the problem • By enabling predictions and simulations of potential futures

25. From previous lectures Focus of SE methodologies SE process

26. Modeling language All models are based on a language that can be understood by a large community (e.g. Mathematical models). Aims: • Exchange on the limitations, validity of models • Universal consensus if no proof

27. An example using SysMLmodelling language (Francois)

28. Position in SE process SE process

29. Understand user requirements F: refine requirements list into categories and model • Define use cases of the system B: define activities expected by the system S: define the boundaries between System and Environment • Interaction points • Interfaces

30. S: Boundaries System and Environment

31. S: Boundaries System and Environment

32. F: Use cases

33. Relations between requirements

34. F: Requirements: example

35. Position in SE process SE process

36. Develop concept and validation plan F: define all the services required by parts of the system • Define the attributes needed for fulfilling this service S: define the physical parts dedicated to certain services (concept of object containing services and attributes) B: define sequence of activities provided by parts while system in use Validation: define tests and simulations for validation

37. F: Functions of sub-system

38. S: Structure: System architecture

39. B: Behaviour

40. Position in SE process SE process

41. Develop system performance specification and validation plan S - F: define interactions between parts of system • define type of attributes and range of values for them B: define behaviours and tasks achieved by each part (sub-system) Validation plan: define tests and simulations for each sub-system

42. S- F: Derive System Interfaces An interface describes a contract between the elements in the system/environment • Services offered by the system OR services requested from the system

43. Structure – Functional view

44. Position in SE process SE process

45. Expand performance specification into Configuration Identification and verification plan S - F: Configuration items (items are components or easily changeable parts of a system) • Requirements are allocated to components B: behaviour of components found from abaques or other time tests

46. Structure

47. Behaviour

48. Conclusion As the description of a system becomes more precise, models associated need to be more formal. When considering your system at a certain level of description, it is important to ask yourselves the right questions and to associate models for answering these questions.

49. To go further ... [INCOSE, 98] http://www.incose.org/productspubs/pdf/techdata/ertc/glossarydefnsofterms_1998-10_twg.pdf http://www.incose.org/mediarelations/glossaryofseterms.aspx (under construction) [Wymore, 93] A. W. Wymore Model-Based Systems Engineering, CRC Press, Boca Raton, 1993. [SysML, 10] http://www.omg.org/spec/SysML/1.2/ , June, 2010. [Friedenthal, 08] S. Friedenthal, A. Moore, R. Steiner, Practical Guide to SysML: Systems Modeling Language, Morgan Kaufmann Publishers, Inc.: San Francisco, CA, 2008. [Weilkiens, 08] T. Wielkiens, Systems Engineering with SysML/UML: Modeling, Analysis, Design, The MK/OMG Press, 2008. [omgSysML wiki] http://www.omgwiki.org/MBSE/doku.php?id=mbse:methodology#list_of_mbse_methodologies