Iet Prestige Lecture Coping With Complexity 7th December


Published on

Coping with Complexity Lecture given at Coventry University on 7th December 2010. Download available at

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • We will see how to manage some of the information being generated to deal with the specificaiton of complex systemsWe can use fairly simple measures to compare the complexity of one system with anotherApparent complexity is important as we want to distinguish true complexity from just difficult and challenging work
  • The term System of Systems has arisen for two main reasons. Firstly, the increased interconnectedness of the built world arising from the pervasiveness of distributed information systems, supported by novel sensors, GPS and computer intelligence. This provides opportunities to develop more complex entities by joining up existing ones, and building new ones, based on sharing of information. Secondly, science is improving our knowledge of how systems interact to the point where we are in a better position to explain – though not always predict – system of systems behaviour. The classic example is climate change. Although meteorological science, supported by modern supercomputers, allows us predict the weather 2 or 3 days ahead quite reliably, it has taken research on global warming to make us realise that the whole eco-system – comprising rivers, oceans, atmosphere, biosphere and human economic activity - are all coupled with each other and giving rise to largely undesirable emergent outcomes.
  • As systems have evolved they have also become nested and hierarchical sometimes the single elements of SoS are in themselves simple systems.
  • Electrical & Electronic Systems are in fact Systems of Systems being composed of a number of individual System of Systems such as engine management systems, chassis control systems, body control systems and infotainment systems which have their own particular functions but rely on shared resources such as power supplies, processing resources and networked data. This approach is necessary for their effective & efficient implementation, however this systems of systems approach also brings accompanying issues of emergent behaviour that can manifest itself as quality problems (3, 4 )Complexity50 – 100 ECUs, 10+ Networks, 100M L.O.C. now, 200M – 300M in near future according to Frost & SullivanHuge number of variants – the first instance of many of these will be when they are producedTime to market< 2 years from approval to Start of ProductionVolumes (10s – 100s thousands units per annum)Constrains testing on each unit producedExposure to tolerance spreadCosts of rectificationImpact of failuresMix criticality safety, comfort & convenience but Even failures associated with convenience features damaging for customer retention & Brand imageIncreasing levels of integration with SupersystemsDiagnostics & manufacturingConsumer Electronics - Bluetooth, USBITS – Road-tolling, traffic information, Advanced Driver Support
  • In the first two cases – Directed and Collaborative System of systems – it is possible to lay out some heuristics or ‘rules of thumb’ to guide their development. These are intended to allow system of systems to grow, or be reconfigured, for new technology to be added and for the constituent systems to be developed with relative independence. Aim for stable intermediate formsApply triage – direct effort only to those areas which are important, and in which you can make a differenceLeverage at interfacesEnsure cooperation between developersRecognise the Primacy of CommunicationsA key issue in applying these heuristics is the ability of those seeking to achieve particular results, in the form of desirable emergent properties, to predict or control the outcome of making particular changes to constituent systems. The underlying problem is that when complexity increases, it becomes difficult to characterise the systems in terms of simple, abstract models. In the extreme, for truly complex systems, there is no model of the system simpler than the system itself.
  • Excel-based, dependences are represented using simple notationLots of DSM tools support Both freeware and commercial toolsLots of analytical approachesBanding, partitioning, tearing, clusteringOptimising task sequences, team structures, system architecturesImpact analysis (feedback loops and iterations).
  • A key characteristic for successful implementation of System of Systems is robustness. Robustness concerns the resilience of a system to maintain an appropriate level of function during and after variations or disturbances. It is the ability to cope with variation rather than relying on preventing it occurring. For an automotive electrical system comprising of many interlinked sub-systems is it clearly desirable that any abnormal behaviour in one sub-system is not cascaded to other sub-systems.
  • To date there is a lack of analytical modelling techniques at SoS level to capture inter system interactions. Part of the reason for this is the inherent scale of Systems of Systems and the subsequent conflict between detail and coverage as well as differing levels of detail known by integrator across sub-systems. This paper will describe the development of novel robustness models for distributed automotive electronics systems.
  • None of these is a complete solution, almost certianly a hybrid approach will need to be used
  • Iet Prestige Lecture Coping With Complexity 7th December

    1. 1. Coping with Complexity<br />McKinney Associates<br />Francis McKinney<br />1<br />
    2. 2. Introductions<br />McKinney Associates is an independent management consultancy providing systems based solutions across the automotive, ICT and defence industries. <br />Core to our business is a systems approach. <br />2<br />
    3. 3. Areas of expertise<br />Management and delivery of complex projects<br />Systems design and integration<br />Systems thinking and holistic problem solving<br />Innovation and technology management<br />Interim management solutions<br />3<br />
    4. 4. Tonight’s agenda<br />Coping with Complexity<br />4<br />
    5. 5. Contents<br />What is complexity?<br />How did we get here?<br />The business impact of complexity<br />Coping methods<br />Summary & conclusions<br />5<br />
    6. 6. What is complexity?<br />Coping with Complexity<br />6<br />
    7. 7. Complex systems<br />A complex system is a system composed of interconnected and interrelated parts that as a whole exhibit one or more emergent properties not obvious from the examination of the properties of a single component part.<br />Source: Wikipedia definition<br />7<br />
    8. 8. Characteristics of complex systems<br />The emergent properties will almost certainly contain undesirable as well as desirable behaviours<br />Complexity is related to hierarchy and therefore the position of the observer<br />Level of interaction of the elements means the emergent properties are not always repeatable or predictable<br />They have nearly always evolved from a system which seemed to work.<br />8<br />
    9. 9. Properties of complex systems<br />A complex system requires a great deal of information to specify – a really important feature of complexity<br />Complexity is an absolute and quantifiable property of a system - once a metric and boundary has been established<br />Apparent complexity is the perception that something is complex - complicated things have a high apparent complexity.<br />It is the role of a good systems architect to manage the evolution of complexity in such a way that a complex system doesn’t seem complicated. <br />9<br />
    10. 10. Properties of complex systems<br />Complexity arises in a system as more is asked of it <br />Complexity manifests itself at the interfaces between elements or modules<br />It is the role of the architect to keep<br />the actual complexity as low as possible<br />the system uncomplicated.<br />Complexity is inherently neither a good nor bad, however it must be managed<br />10<br />
    11. 11. How did we get here?<br />Coping with Complexity<br />11<br />
    12. 12. Where does it come from?<br />Processes<br />Organisation<br />Programme Management<br />Technical<br />Multidimensional<br />Issues compound<br />Solutions must also be multidimensional<br />Only describing the technical and programme management<br />12<br />
    13. 13. Evolution of systems<br />13<br />
    14. 14. Hierarchy of system views<br />14<br />
    15. 15. Properties of Systems of Systems<br />Autonomy of elements<br />Evolutionary development<br />Heterogeneous elements<br />Sharing of resources<br />Geographic distribution <br />Emergent behaviour.<br />15<br />
    16. 16. The growth of silicon<br />In 1970 a control unit had a memory capacity of 1Kb<br />In 2010 it is typical to see 1Mb memory capacity<br />In premium level vehicles the number of ECUs is approximately 75<br />There is now a greater use of FPGA devices for audio and video applications where high performance processing is often required.<br />16<br />
    17. 17. High-end vehicle architecture<br />Powertrain<br />Systems<br />Safety<br />Systems<br />Chassis<br />Systems<br />Body<br />Systems<br />PTC Heater<br />Motors x N<br />Radar<br />Sensor Cluster<br />ACC<br />DSC/ABS<br />Climate Module<br />Rear Climate Control<br />Restraints Control<br />Parking Aid<br />LH Sensor<br />RHR Window Motor<br />Blindspot Monitor<br />LH Mirror<br />Rear BCU<br />Alternator<br />Steering Angle<br />Engine Control<br />Park Brake Control<br />Occupancy Sensing<br />RH Sensor<br />Transm’n Control<br />LH Switch Pack<br />RHR Door Module<br />RH Seat Module<br />Transm’n Control<br />Suspension Controller<br />Adaptive Lighting<br />Alarm Sounder<br />Window Motor<br />RHF Door Module<br />Front BCU<br />Damping Control<br />Pedestrian Detection<br />Gearshifter Control<br />Rain/Light Sensor<br />LHR Motor<br />RH Mirror<br />Gearshifter Control<br />Steering Column<br />Gearshifter Control<br />FFH Control<br />RH Switch Pack<br />LH Seat Module<br />Receivers<br />LHR Door Module<br />Key Interface<br />Battery Management<br />TPMS<br />Diagnostics<br />Window Motor<br />RH Door Module<br />Gateway<br />J1962<br />Connector<br />Steering Switches<br />Instruments<br />Infotainment <br />Systems<br />Control Panel<br />17<br />
    18. 18. Comparisons with other complex systems<br />18<br />
    19. 19. The business impact of complexity<br />Coping with Complexity<br />19<br />
    20. 20. A changing business<br />Automotive is traditionally a mechanically led business<br />Shifting models for revenue<br />Implications for skills<br />Impact on supply chains and procurement models.<br />20<br />Source: McKinsey & Co<br />
    21. 21. Innovation contribution of software systems<br />Flexibility of software based systems<br />Disruption from innovation<br />Rapid evolution<br />Convergence from neighbouring industries.<br />21<br />Source: McKinsey & Co<br />
    22. 22. Whole-life costs of complexity<br />Occurrence of customer level defects <br />Cost to repair defects in a distributed information system<br />Root cause of network issues is difficult to determine<br />Component with symptoms gets replaced.<br />Source: McKinsey & Co<br />22<br />
    23. 23. Impact of repair costs on warranty<br />System issues difficult to diagnose and repair<br />Issues can be emergent and have complicated use cases<br />Replacing controllers and sensors always easiest and lowest risk option.<br />23<br />Source: McKinsey & Co<br />
    24. 24. Coping strategies<br />Coping with Complexity<br />24<br />
    25. 25. Committed lifecycle costs against time<br /><ul><li>Leverage early
    26. 26. Validation is an expensive and risky error discovery process
    27. 27. Try and discover early and fix quickly.</li></ul>25<br />Drive costs here<br />Errors here<br />Source: INCOSE<br />
    28. 28. Systems Integrator risks<br />Prime/Integrator<br />eg Boeing, Ford, NG…<br />OEM n<br />OEM 1<br />e.g. NG, Bosch,…<br />|| . . . ||<br />Competitive selection amongst suppliers worldwide<br />Competitive selection amongst suppliers worldwide<br />Supplier …N<br />Supplier A1<br />System …N<br />System A<br />…<br />…<br />Code …N<br />Code A<br />System Integration<br />Contracts<br />Integration at a unit level<br />Contracts<br />26<br />
    29. 29. Actual <br />validation effort<br />Projected <br />validation effort<br />Actual <br />complexity<br />Projected <br />complexity<br />System Validation vs. Complexity<br />Verification<br />Cost<br />Complexity<br />Complexity increasing N<br />Unbounded<br /> risk/cost<br />validation effort increases Nx<br />Time<br />27<br />
    30. 30. Heuristics for Systems of Systems<br />28<br />
    31. 31. Three steps for coping <br />29<br />
    32. 32. Design structure matrices<br />Coping with Complexity<br />30<br />
    33. 33. Design Structure Matrices<br />A method for analysing dependences in systems and processes<br />System analysis & project management tool<br />A complex system is a complex network of inter-dependences.<br />31<br />
    34. 34. Design Structure Matrices<br />Identifying dependencies<br />minimise iterations in sequential processes<br />highlight closely coupled elements<br />identify optimal partitioning structures<br />Uses a simple notation<br />detailed knowledge of nature of dependency not required.<br />32<br />
    35. 35. Benefits realised in the use of DSM<br />Link from the architecture to the delivery team structure<br />easier to identify where cooperation needs to be strongest<br />Identification of key elements and their dependencies<br />easier to understand which elements of the systems of systems needs to be managed most closely<br />Functional decomposition and partitioning<br />insights into the task of systems integration and the sequence to build in order to achieve stable intermediate forms<br />Identification of critical interfaces and components<br />easy to see which elements need closer technical analysis.<br />33<br />
    36. 36. Systems robustness studies<br />Coping with Complexity<br />34<br />
    37. 37. Robustness of Systems of Systems<br />Robustness concerns the resilience of a system to maintain a desired emergent property during and after perturbations<br />cope with variance<br />ensure undesired emergent conditions are not propogated around the System of Systems.<br />35<br />
    38. 38. Robustness Analysis<br />The earlier business impact data showed that overwhelmingly issues are at the systems level<br />Robustness problems are complex, interactive and emergent<br />transient conditions<br />failures in other systems <br />multiple root causes<br />tolerance spread<br />Unforeseen use cases<br />Robustness issues are not always present under normal operation<br />Static Analysis methods (e.g. FMEA) not effective enough at finding robustness issues.<br />36<br />
    39. 39. Modelling of Systems of Systems <br />Large Scale<br />effort to model<br />understanding of interactions<br />Non-homogeneous nature of individual systems<br />different levels of detail <br />different modelling techniques<br />continuous and state-based behaviours<br />different failure modes<br />What properties to model?<br />those that relate most strongly to robustness.<br />37<br />
    40. 40. Methods for systems robustness<br />Computer simulation<br />evaluate options without risk to the real systems<br />accepting that for very complex systems there is no model which will be simpler than the Systems of Systems itself<br />Monitoring of the systems of systems<br />using the real systems of systems instrumented to monitor for behaviours<br />very representative<br />may be risky using the real system<br />Simplified models<br />attempt to reduce the complex behaviour to a more simplified abstract model for the specific area of interest<br />e.g. in Physics, the truly complex world of gas dynamics has been reduced to the laws of Thermodynamics, by taking a very high-level statistical view of the ‘average’ behaviour of molecules.<br />38<br />
    41. 41. Formal methods<br />Coping with Complexity<br />39<br />
    42. 42. Formal Methods for Systems of Systems<br />A technique is mathematically based if its notations and methods can be explained in mathematical terms<br />e.g., in predicate logic or in set theory<br />underlying mathematics may be embedded in tools<br />Formal methods are particular kinds of mathematically based techniques for the precise specification, development, or verification of software and hardware systems<br />Formal methods are based on logic, discrete mathematics, and computer-readable languages<br />They allow properties of a computer system to be predicted from a mathematical model<br />Logical statements are ‘solved’ by establishing truth or falsehood.<br />Prof J Woodcock<br />40<br />
    43. 43. Why bother…?<br />"Traditional software development methods rely on human inspection and testing for validation and verification. Formal methods also use testing, but they employ notations and languages that are amenable to rigorous analysis, and they exploit mechanical tools for reasoning about the properties of requirements, specifications, designs and code. <br />Practitioners have been sceptical about the practicality of formal methods. Increasingly, however, there is evidence that formal methods can yield systems of very high dependability in a cost-effective manner, ….”<br />[Ref. Software for Dependable Systems: Sufficient Evidence? Daniel Jackson, Martyn Thomas, and Lynette I. Millett, Editors, Committee on Certifiably Dependable Software Systems, National Research Council, 2007]<br />41<br />
    44. 44. ISO 26262 Road Vehicle – Functional Safety<br />Adaptation of generic standard IEC 61508<br />Addresses the specific needs of developing electrical and electronic systems for road vehicles<br />Applies to all activities for developing systems comprising electrical, electronic and software elements that provide safety-related functions.<br />42<br />
    45. 45. Who is doing this ?<br />Scandinavian railways now mandate the use of Formal Methods in systems development<br />Ever since the floating point liability, Intel always use Formal Methods – other have followed<br />The mobile phone payment system in Japan is formally defined<br />All Airbus flight control systems are defined formally from specification through source code to object code<br />All Typhoon flight control and engine control software is independently, formally proven.<br />43<br />
    46. 46. What happens?<br />Time<br />Systems of Systems<br />LegacySystems<br />OTSSystems<br />New<br />Systems<br />Software<br />Software<br />Software<br />44<br />
    47. 47. Code<br />Development<br />System<br />Requirements<br />Verification<br />Review<br />Test<br />Analysis<br />Overview and rationale for the approach<br />Hand code<br />Autocode<br />Specification<br />Model<br />Typically <br />vast majority <br />of effort<br />Typically <br />compliance to <br />Standards/process<br />Typically only<br />Analyse results <br />of test<br />Reduction to Validation <br />and Hardware testing<br />Exploit <br />automated <br />proof<br />
    48. 48. How does the process work?<br />46<br /><ul><li>The semantics of the Formal Notation
    49. 49. The assumptions
    50. 50. The properties to be proved
    51. 51. The proof is valid
    52. 52. The mapping from the Formal Notation to the executable is understood
    53. 53. The assumptions were correct</li></ul>Source: QinetiQ systems assurance<br />
    54. 54. Background to architectural analysis<br />The aim is to be able to check for properties of complex Systems of Systems<br />Traditionally done through test, but test has its limitations<br />i.e. not exhaustive<br />Formal modelling could help as it can be exhaustive, but has to be usable<br />Exploitation of appropriate formalism and use of existing modelling tools to enable non-specialist access to formal methods.<br />47<br />
    55. 55. 48<br />Implications for the systems integrator<br />Top down development paradigm from requirements to code does not apply<br />Systems integrator does not have the required control<br />Consequently a conventional view of correctness by construction does not work<br />Systems integrator holds the risk<br />Control over software and architecture risks can make or break a large complex project<br />
    56. 56. 49<br />Implications for the systems engineer<br />The analysis, through the exploitation of mathematical proof, enables :<br />identification of requirements (properties) under normal and abnormal conditions<br />‘what-if’ the architecture<br />identify risks, accept results or adapt<br />plan testing<br />All of which is robust and underpins acceptance of the System of Systems<br />
    57. 57. The Benefits<br />The benefits can be described as follows:<br />avoiding errors being discovered late in the development cycle<br />reduce the cost of the re work cycle...hidden re-work factory<br />Cost benefits are difficult to measure, but we do understand …..<br />recall costs >£20M<br />production line delay ~£1M per day<br />software cycle ~£100k<br />50<br />
    58. 58. Summary & conclusions<br />Coping with Complexity<br />51<br />
    59. 59. Summary<br />Vehicle systems are necessarily becoming more complex through:<br />response to competitive pressures<br />increasing reliance on embedded software systems<br />Simple systems have evolved into Systems of Systems<br />Increasing complexity is having and will continue to have a profound business impact<br />Complexity must be managed effectively<br />Systems design and the role of the architect are more critical than ever<br />The role of the OEM as the systems integrator has become more difficult and riskier.<br />52<br />
    60. 60. Summary<br />There are heuristics which can help us manage the complexity of closed or collaborative systems<br />We have explored three techniques which underpin the heuristics<br />Design Structure Matrices<br />robustness of Systems of Systems<br />Formal Methods<br />Methods are built on mathematical principles and enable<br />identification of dependencies and optimal partitioning<br />identification of which interface properties are critical to robustness through modelling and simulation<br />formal proof that those properties can be maintained under all desired and undesired emergent conditions<br />53<br />
    61. 61. Conclusions<br />Increasing requirement for the use of Formal Methods<br />ISO26262<br />Issues discussed are not totally unique to the automotive industry<br />Would recommend a framework architecture model is developed for the auto industry<br />building on the efforts of AUTOSAR<br />Interesting research going on in the field of complexity science which can be drawn into this arena<br />Systems modelling techniques – multi-domain<br />Symmetry and invariance<br />54<br />
    62. 62. Thank you for listening<br />Coping with Complexity<br />55<br />
    63. 63. Visit and follow us<br />Our web-site:<br /><br />Visit us on LinkedIn<br /><br />Follow us on twitter<br />@mckinneyassoc<br />E-mail us at<br /><br />56<br />
    64. 64. Questions<br />Feedback please to:<br />A copy of this presentation is available at<br />57<br />