KIP - ASVT: KIP - ASVT Systems Models Systems Engineering


System approach: System approach System approach: way of thinking and problem solving based on complex treatment of phenomena and processes, taking into account both internal and external links. Methodical, objective: understand, appropriately formulate and solve a problem Tools: models, simulation


Common characteristics of systems: Common characteristics of systems Systems have a structure that is defined by its parts and processes. Systems are generalizations of reality. Systems tend to function in the same way. This involves the inputs and outputs of material (energy and/or matter) that is then processed causing it to change in some way. The various parts of a system have functional as well as structural relationships between each other.


Basics of system approach: Basics of system approach System is more than the sum of its parts We analyze the system to be able to predict its behaviour The main purpose of the system is that in favour of which we can sacrifice other objectives. Every system is an information system: it must analyze the flow of information It may be advisable to decompose complex system into subsystems, which are then treated individually and in the end again as one whole. System is a dynamic network of interconnected elements. The change in one element results in changes other elements. The system boundary can change according to the goal of the analysis.


Systems – basic concepts 1: Systems – basic concepts 1 system – set of elements and their mutual links that exhibit specific behaviour as a whole structure – way of arrangement of elements and their links subsystem – subset of elements with stronger or more numerous links environment – elements not belonging to the system, but having links to its elements (however weaker then within the system) input – action from the environment to the system output - action from the system to its environment process – transformation input output


Systems – basic concepts 2: Systems – basic concepts 2 feedback – link monitoring outputs and feeding information to input closed system - system without inputs and outputs (not interacting with its environment) open system – has inputs and outputs, exchanges mass, energy, information with its environment static system – neither system nor its elements change with time dynamic system - system and/or its elements change in time control, regulation – evaluation of inputs, processes and output and doing changes


System: System


System as a black box: System as a black box


System with feedback: System with feedback negative – system stabilization positive – amplification of the response Try to find examples of both kinds of feedback SYSTEM INPUT OUTPUT FEEDBACK


Systems thinking: Systems thinking Hard systems Soft systems Evolutionary systems


Hard systems: Hard systems Useful for problems that can justifiably be quantified. However it cannot easily take into account unquantifiable variables (opinions, culture, politics, etc), and may treat people as being passive, rather than having complex motivations. Tools: simulations, computer modelling, techniques of operations research.


Soft systems: Soft systems Cannot easily be quantified, especially those involving people holding multiple and conflicting frames of reference. Useful for understanding motivations, viewpoints, and interactions and addressing qualitative as well as quantitative dimensions of problem situations. Tools: Morphological analysis as a method for structuring and analysing non-quantifiable problem complexes.


Evolutionary systems: Evolutionary systems Methodology applicable to the design of complex social systems; open, complex systems with potential capacity to evolve over time. Tools: multidisciplinarity, chaos, complexity, emergence, cybernetics, cultural anthropology, evolutionary theory, and others.


Notes - management: Notes - management Hard management – command and control, rigid organizational structures Soft management – leadership, mentoring, coaching, networking


General system theory: General system theory interdisciplinary approach study of complexity and relation of the whole to its parts (holism) Ludwig von Bertalanffy, Kenneth Boulding attempt to find common features of complex systems across disciplines; later on certain resignation on possibility of finding universal system principles and laws


Applied system disciplines: Applied system disciplines Operations research Systems analysis Cybernetics Methodology of „soft“ systems Systems engineering Development of IS ....


Operations research: Operations research Development and utilization of mathematical models in decision-making Problem statement Model building Finding solution from models Solution implementation and control


Systems analysis: Systems analysis focused on system knowledge; distinguish principle features of the system, general from individual; tools: decomposition, analysis and synthesis warning: the whole is more than sum of its parts


Cybernetics: Cybernetics from Greek - steering Nobert Wiener, 1945 Cybernetics studies systems that can be mapped using loops in networks modeling information flows. Systems of automatic control must use at least one feedback loop


Example 1 - controller: Example 1 - controller 1868 James Clerk Maxwell analyzed “steam engine with controlled under variable load" as a system of non-linear differential equations and concluded that, depending on equations coefficients, the system behaviour will be described by one of the five following patterns:


1 - damping: 1 - damping (1) The velocity is smoothly adjusted to desired value (the best possible response):


2 – damped oscillations: 2 – damped oscillations (2) The velocity is adjusted to desired value after some oscillations (acceptable response):


3 - oscillations: 3 - oscillations (3) permanent oscillations – ineffective response:


4 – non-dumped oscillations: 4 – non-dumped oscillations (4) oscillates with growing amplitude until the explosion:


5 - explosion: 5 - explosion or (5) straightly explodes:


Feedback: Feedback Negative (1,2) –system stability , homeostasis, frequent in technical and live systems Positive (4,5) – response amplification, welcome e.g. in economics – multiplication effects, synergic phenomena


Example 2 - Thermostat: Example 2 - Thermostat Input – gas supplied by gasworks Output - heat Process – temperature monitoring, sending signal to switch the burner on/off; gas is burned and warm air is delivered to the living room Feedback – if the temperature falls below / raise above the setpoint, the thermostat sends signal to switch the burner on/off


Example 3- Family finance: Example 3- Family finance Input –incomes from salaries, gifts, lotteries ... Process – saving money in banks, cash/credit card payments, recording expenses, budgeting Output – bought products and services (energy, rent, insurance, food, home equipment, culture, ...) Feedback – bank statements, comparing incomes with spendings, changing the household economy.


Methodology of soft systems: Methodology of soft systems Extending application of system approaches to social systems reflects subjective interests and attitudes including fuzziness related to subjective interpretation of information and vagueness of the language (hard methods are successful only for well structured, deterministic problems) builds on achievements of biology, informatics, psychology, anthropology, linguistics, etc. cognitive science (P. Thaggard) holism, emergency, synergetics vs. reductionism


Systems classification (taxonomy): Systems classification (taxonomy) Transcendent systems Social systems Man Animals Genetic systems Open systems Cybernetic systems Mechanical systems Physical systems LIVE SYSTEMS Symbolic functions, information INANIMATE SYSTEMS Mass and energy growing complexity


System and order: System and order Order: an arrangement of system elements and links allowing to predict its future behaviour  system can be controlled even with incomplete knowledge of all its elements and links Order is based on knowledge; however, due to our intervention into the system it needn’t have character of the law of nature Deterministic chaos, thriving on chaos (T. Peters) Complex systems, holism, emergence, synergy


Holism: Holism Considers the whole system, in its environment, through its whole life System of Interest, collection of elements with a common identify, e.g. product, organization. Viable system, must include everything needed to maintain its existence and achieve its goals. Consequences of Holism: The viability of a product generally relies upon interactions outside of its immediate (product) boundary. Systems are engineered within the context of one or more “containing systems”.


Emergence: Emergence The whole entity exhibits a property which is meaningful only when attributed to the whole and NOT to one of its parts Emergent properties vary with environment and relationships to related systems. Consequences of Emergence no guarantee of benefit from optimising parts of the system, or even all of the components independently Changing the elements or interactions within a system may effect its properties, this can cause emergent properties to change at a number of system levels.


Systems engineering: Systems engineering


Slide35: A magician takes something Bahill and Dean, http://www.sie.arizona.edu/sysengr/slides/


Slide36: and….. POOF


Slide37: turns it into nothing!


Slide38: An engineer takes nothing 38


Slide39: and….. Bahill & Dean 39


Slide40: turns it into something!


What is Systems Engineering (SE): What is Systems Engineering (SE) Design and control of complex technical systems Basic resources: 4M - Men, Machines, Materials, Money (and Time) Focuses on artificial systems – artifacts Identifying and understanding all the requirements the system must meet Understanding solutions options space ‘Optimal’ path from requirements identification, via solutions, through to customer satisfaction


Purpose: Purpose Produce systems that satisfy the customers’ needs Increase the probability of success Reduce risk Reduce total-life-cycle cost


Artificial systems: Artificial systems Typical features: goals are formulated beforehand and outside of the system system is highly ordered, uncertainty is not welcome man stay outside of the system as its user, client; plays a passive role or acts as one of the system‘s resources


Early Systems developments: Early Systems developments drew heavily on previous experience Expectations centred on performance Fundamental architecture based on years of evolution Fundamental interactions and influences in the environment well precedented e.g. ‘we know who the stakeholders are’ the problem to be tackled was clear Automobile technology about 1890


The Systems challenge is becoming more complex: The Systems challenge is becoming more complex Customer / Enterprise expectations Constraints (performance, time, cost .. including through life cost etc) Customers want Benefits achieved, not features for their own sake We need to decide what is relevant to achieve those benefits Customers want customisation & adaptability Enterprise environment extended, global … organisations, team dynamics & decisions are complex Highly integrated with environment & other systems stronger, wider influences & interrelationships Increasing rate of change … & uncertainty need to establish through life robustness … through life influences Situations are becoming increasingly varied & unprecedented


Slide46: An increasing number of subsystem options (choices) are available Systems are more highly integrated than ever The relationship between Function & Form is changing significantly ….. Systems engineers, must decide what is relevant and critical ….. SE face open problems rather than closed problems


Implications for SE: Implications for SE establish a clear, common understanding of the problem across stakeholders, the SE team etc. cannot rely on previous precedents system context and associated decisions must be established and communicated explicitly gaining confidence in the system is increasingly difficult Soft methods are essential in dealing with ‘open’ problems


Methodology: Methodology define problem or task (of the system) specify (system) goals develop conceptual system design (system synthesis) analyze and evaluate systems being designed select suitable (optimum) system deploy and operate the system


The vee life-cycle model: The vee life-cycle model


Cost evolution for a typical project: Cost evolution for a typical project


The systems engineering process: The systems engineering process But, it is not a serial process. It is parallel and highly iterative


SE is not a waterfall process: SE is not a waterfall process


Systems engineering is not: Systems engineering is not


Systems engineering is a fractal process: Systems engineering is a fractal process The systems engineering process is applied at levels of greater and greater detail. It is applied to the system, then to the subsystems, then to the components, etc. Similarly for the fractal pattern above, the same algorithm was applied at the large structural level, then at the medium-scale level, then at the fine-detail level, etc.


Incremental iterations: Incremental iterations Even the lowest level systems are developed with iterations. The designs get bigger with each iteration. This allows manufacturing to overlap design.


The foundation for a successful project: The foundation for a successful project Complete the problem statement before defining the requirements. Avoid stating the problem in terms of solutions. Involve the customer in the process of defining the problem and the requirements. Early in the system design consult all stakeholders (including manufacturing) about system requirements


Validation and verification: Validation and verification Validation: building the right system Verification: building the system right


Validating requirements: Validating requirements means ensuring that the set of requirements is complete and consistent, a real-world solution can be built that satisfies the requirements, and it can be proven that a real-world system satisfies the requirements. If the requirements specify a perpetual-motion machine, the project should be stopped.


Verifying requirements: Verifying requirements Each requirement must be verified by Logical argument Inspection Modeling Simulation Analysis Test Demonstration


Investigate Alternative Concepts: Investigate Alternative Concepts The systems engineer’s job is to capture the values and preferences of the decision maker, so that the decision maker (and other stakeholders) will have confidence in the decision. The decision maker balances effort with confidence* Often this requires a formal tradeoff study.


Components of a tradeoff study: Components of a tradeoff study Problem statement Evaluation criteria Weights of importance Alternative solutions Evaluation data Scoring functions Scores Combining functions Preferred alternatives Sensitivity analysis


Model the System: Model the System


Modelling myths and the reality: Modelling myths and the reality The modelling process: how should you model? when should you model? to what depth Benefits of modelling: why are you modelling? what value does a model give you?


Where are models used?: Where are models used? Everywhere: Cooking: recipe is a process model for a cake shopping list is a quantity and cost model picture of the output is a graphical model Bridge design Gant chart is a process model Bill of materials a quantity and cost model Loading calculations are mathematical model blueprint is a graphical model


Modelling Myths: Modelling Myths You can think everything through from the start Modelling is a waste of time The world revolves about modelling languages All system engineers know how to model


Myth 1: Myth 1 You can think everything through from the start managers attempt to freeze requirements at an early stage of development


The reality: The reality Paralysis through analysis: Spend so long modelling to an infinite level of detail to determine correct requirements that the model adds little relative value to the project Build exactly what the customer thinks he wants, not what he needs: No true discussion on requirements leads to development of incorrect solutions


Myth 2: Myth 2 Modelling is a waste of time


The Reality: The Reality “The software development process is essentially the same as it was 40 years ago…” “Embedded system engineers are under tremendous time-to market pressure...” Doubling the software size causes the development time to increase by a factor of 10 !


The Reality: The Reality 72.8% of Projects are late and the average delay is 3.8 months 86.5% miss functionality expectations Embedded designs will double from 2000 to 2003 Hardware design resources will need to grow 7.7% Embedded programming resources will need to increase by almost 50%…but it can only grow 20% Model based specifications are a way to speed up the development process and reduce costs (if used properly)


Points to consider: Points to consider People need to ask two questions Where can you use models ? What benefit do they give ? Different stakeholders get different benefits and use models differently Customer Systems Engineer Software Engineer Miscellaneous benefits dependant upon depth of modelling and tools used


Myth 3: Myth 3 The world revolves about modelling languages


The reality: The reality Modelling language is not a methodology Modelling language is useful and have its place Pick the methodology / tools / processes that are appropriate


Myth 4: Myth 4 All system engineers know how to model


The reality: The reality Most people are creating static paper/computer based models Most people are not taught how to model, they learn from experience To model you need experience based on domain, process and tool knowledge


Decomposition: Decomposition physical functional


What do we need to fly?: What do we need to fly? Physical Decomposition For centuries, humans have been unsuccessful in their attempts to fly because they used physical decomposition (brain, eyes, legs, and wings).


What do we need to fly?: What do we need to fly? The Wright Brothers focused on three functions: control, horizontal thrust, and vertical lift. Functional Decomposition


Sensitivity analysis: Sensitivity analysis We must use sensitivity analysis because intuition isn’t always enough. What if ….


Risk management addresses: Risk management addresses System risk Performance, schedule and cost of the product Project risk Business risk Financial and resource risks to the enterprise Safety, environmental and risks to the public


Risk management: Risk management Good risk management will not prevent bad things from happening. But when bad things happen, good risk management will have anticipated them and will reduce their negative effects.


Slide88: Risk factors are often coupled


Risk management: Risk management NEGLECT PREPARE FOR AVOID


Extent of SE depends on risk: Extent of SE depends on risk At NASA, the probability of mission failure was about 10-2, but the severity was near 1. The product of these numbers was big, so they did lots of systems engineering. At a big software house, the probability that a new system will destroy user files was about 1, but their perceived severity was around 10-6. They did not care if users lost a few files. Therefore, they did little systems engineering.


Example - Scenario: Example - Scenario It’s a clear morning Temperature below -10 ºC A dozen skiers are scheduled to fly to Grenoble, France But there is a half inch of ice on the runway As an airline dispatcher, how would you manage this Icy Runway Risk?


Risk management: Risk management Transfer: bus the skiers, thus transferring the risk to bus lines Eliminate: cancel the flight Accept: send the plane as scheduled Mitigate Request removal of ice from runway Change runways Change equipment (different type of aircraft) Change crew


Ignore: Ignore How about ignoring the risk? Not acceptable. There is no I in TEAM.


SE creates a system of systems: SE creates a system of systems The product The process that produces the product The design and development system The testing system The production and manufacturing system The operating system The maintenance system The performance evaluation system The customer service system The retirement and replacement system


Interfaces: Interfaces Interface control definitions (ICDs) define and document the interfaces among components.


Slide96: System integration


Launch the System: Launch the System Configuration management Project management


The synergistic roles of SE and PM: The synergistic roles of SE and PM Systems engineering creates the product documents. Project management creates the process documents.


Creating a new office complex: Creating a new office complex Systems engineering Creates the product Doing the right things What is it for? Who is it for? Alternative concepts Buy, build or lease Concrete building or trailers Total life cycle cost Get customer feedback Create plans Project management Creates the process Doing things right How to build When to build Where to build Cost to build Get feedback Build to plans


Slide101: Total system test “People do what you inspect, not what you expect.”


Make sure that all tasks are done: Make sure that all tasks are done


Ask yourself “Why?”: Ask yourself “Why?” The systems engineering process must be tailored for each project. Often this means omitting certain tasks, which reduces cost but increases risk. If you choose to omit one of these tasks, you should ask yourself, “Why?”


Summary: Summary Systems engineering is the glue that holds it all together Systems engineering is responsible for the big picture. It must ensure that the system satisfies its requirements throughout the entire system life cycle; from birth to death.


Back to basics - can we define Bart Simpson’s Guide to Systems Engineering?: Back to basics - can we define Bart Simpson’s Guide to Systems Engineering? H.Sillitto INCOSE UK Autumn 2004 Assembly


The customer: The customer I want reassurance that I will get what I asked for and am paying for. If the supplier has to change things or has to do trade-offs I won’t feel hoodwinked but will be included in the process. Traceability will allow me to understand how technical features relate to my needs and help me to decide when it is worth persisting to solve difficult technical problems.


The CEO: The CEO I have been offered all sorts of silver bullets over the past ten years - EFQM, 6 sigma, TQM - and none has delivered the claimed benefits. I agree most of my projects are running late and I’d like to improve that situation. But you’re telling me that systems engineering will add delays up front. So if you want me to take you seriously, you have to show me the ROI from introducing systems engineering - and prove it!


Technical Director of 10-man SME: Technical Director of 10-man SME I want systems engineering sold as a simple exercise to integrating engineering activities to deliver what’s wanted when it’s wanted, and give me a broad perspective on the technical aspects of the business.


Prime minister: Prime minister Systems engineering would be interesting if it can resolve conflicts to deliver vital public services - health service - transportation - schools - and deal with the huge security issues we now face. This is important to me because I want to make sure I am remembered for the enduring success of the achievements of my three terms in office But there isn’t much time left and I need results soon.


17-year-old: 17-year-old Can you explain to me what you do at work in 2 minutes in words I can understand? Why are you often so stressed when you get home? Can you make me a mobile that looks cool and works properly? Will I get paid more as a systems engineer than as an accountant? And by the way, can I have the car keys please?


Undergraduate: Undergraduate I’ve only been involved in systems engineering for 2 months and lots of people have described systems engineering to me but all the descriptions are different. A “unified theory of everything” would be a really good idea. We need to show how systems engineering works with other disciplines and what other disciplines need to understand about systems engineering.


Recent graduate: Recent graduate What does a systems engineer do? The SE community needs to know what they are selling, and know how to sell it and show benefits to different groups. Show SE is part of all engineering disciplines make sure undergraduates on other engineering courses understand SE needs to be part of their skill base, show them how what they are learning can be applied within SE show the undergrads what they can expect in the future - NOT ALL OF THEM WILL BE RIGHT FOR SE. Empower them with the information to make that decision for themselves.


Slide114: Unified theory - very difficult but necessary SE has many definitions (some complementary, some at different ends of spectrum) Fewer diagrams/processes/lifecycles but better defined; Simplify language, remove buzzwords Communication very important - relate ideas to known domains, everyday events, Simple ideas, analogies, case studies: supermarket choice, mountaineering, - - Sell through use of SE on real projects: show successes/failures of exciting projects with/without SE Successes - Battle of Britain - failures - many defence projects Final thought It’s not just about recruiting new systems engineers - it’s also making sure that other undergrads understand the role of SE at an early stage in their career Consider re-branding: “Structured problem solving” does it for schoolkids!