Your SlideShare is downloading. ×
  • Like
  • Save
Iet Prestige Lecture Coping With Complexity 7th December
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Iet Prestige Lecture Coping With Complexity 7th December


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

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

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    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


  • 1. Coping with Complexity
    McKinney Associates
    Francis McKinney
  • 2. Introductions
    McKinney Associates is an independent management consultancy providing systems based solutions across the automotive, ICT and defence industries.
    Core to our business is a systems approach.
  • 3. Areas of expertise
    Management and delivery of complex projects
    Systems design and integration
    Systems thinking and holistic problem solving
    Innovation and technology management
    Interim management solutions
  • 4. Tonight’s agenda
    Coping with Complexity
  • 5. Contents
    What is complexity?
    How did we get here?
    The business impact of complexity
    Coping methods
    Summary & conclusions
  • 6. What is complexity?
    Coping with Complexity
  • 7. Complex systems
    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.
    Source: Wikipedia definition
  • 8. Characteristics of complex systems
    The emergent properties will almost certainly contain undesirable as well as desirable behaviours
    Complexity is related to hierarchy and therefore the position of the observer
    Level of interaction of the elements means the emergent properties are not always repeatable or predictable
    They have nearly always evolved from a system which seemed to work.
  • 9. Properties of complex systems
    A complex system requires a great deal of information to specify – a really important feature of complexity
    Complexity is an absolute and quantifiable property of a system - once a metric and boundary has been established
    Apparent complexity is the perception that something is complex - complicated things have a high apparent complexity.
    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.
  • 10. Properties of complex systems
    Complexity arises in a system as more is asked of it
    Complexity manifests itself at the interfaces between elements or modules
    It is the role of the architect to keep
    the actual complexity as low as possible
    the system uncomplicated.
    Complexity is inherently neither a good nor bad, however it must be managed
  • 11. How did we get here?
    Coping with Complexity
  • 12. Where does it come from?
    Programme Management
    Issues compound
    Solutions must also be multidimensional
    Only describing the technical and programme management
  • 13. Evolution of systems
  • 14. Hierarchy of system views
  • 15. Properties of Systems of Systems
    Autonomy of elements
    Evolutionary development
    Heterogeneous elements
    Sharing of resources
    Geographic distribution
    Emergent behaviour.
  • 16. The growth of silicon
    In 1970 a control unit had a memory capacity of 1Kb
    In 2010 it is typical to see 1Mb memory capacity
    In premium level vehicles the number of ECUs is approximately 75
    There is now a greater use of FPGA devices for audio and video applications where high performance processing is often required.
  • 17. High-end vehicle architecture
    PTC Heater
    Motors x N
    Sensor Cluster
    Climate Module
    Rear Climate Control
    Restraints Control
    Parking Aid
    LH Sensor
    RHR Window Motor
    Blindspot Monitor
    LH Mirror
    Rear BCU
    Steering Angle
    Engine Control
    Park Brake Control
    Occupancy Sensing
    RH Sensor
    Transm’n Control
    LH Switch Pack
    RHR Door Module
    RH Seat Module
    Transm’n Control
    Suspension Controller
    Adaptive Lighting
    Alarm Sounder
    Window Motor
    RHF Door Module
    Front BCU
    Damping Control
    Pedestrian Detection
    Gearshifter Control
    Rain/Light Sensor
    LHR Motor
    RH Mirror
    Gearshifter Control
    Steering Column
    Gearshifter Control
    FFH Control
    RH Switch Pack
    LH Seat Module
    LHR Door Module
    Key Interface
    Battery Management
    Window Motor
    RH Door Module
    Steering Switches
    Control Panel
  • 18. Comparisons with other complex systems
  • 19. The business impact of complexity
    Coping with Complexity
  • 20. A changing business
    Automotive is traditionally a mechanically led business
    Shifting models for revenue
    Implications for skills
    Impact on supply chains and procurement models.
    Source: McKinsey & Co
  • 21. Innovation contribution of software systems
    Flexibility of software based systems
    Disruption from innovation
    Rapid evolution
    Convergence from neighbouring industries.
    Source: McKinsey & Co
  • 22. Whole-life costs of complexity
    Occurrence of customer level defects
    Cost to repair defects in a distributed information system
    Root cause of network issues is difficult to determine
    Component with symptoms gets replaced.
    Source: McKinsey & Co
  • 23. Impact of repair costs on warranty
    System issues difficult to diagnose and repair
    Issues can be emergent and have complicated use cases
    Replacing controllers and sensors always easiest and lowest risk option.
    Source: McKinsey & Co
  • 24. Coping strategies
    Coping with Complexity
  • 25. Committed lifecycle costs against time
    • Leverage early
    • 26. Validation is an expensive and risky error discovery process
    • 27. Try and discover early and fix quickly.
    Drive costs here
    Errors here
    Source: INCOSE
  • 28. Systems Integrator risks
    eg Boeing, Ford, NG…
    OEM n
    OEM 1
    e.g. NG, Bosch,…
    || . . . ||
    Competitive selection amongst suppliers worldwide
    Competitive selection amongst suppliers worldwide
    Supplier …N
    Supplier A1
    System …N
    System A

    Code …N
    Code A
    System Integration
    Integration at a unit level
  • 29. Actual
    validation effort
    validation effort
    System Validation vs. Complexity
    Complexity increasing N
    validation effort increases Nx
  • 30. Heuristics for Systems of Systems
  • 31. Three steps for coping
  • 32. Design structure matrices
    Coping with Complexity
  • 33. Design Structure Matrices
    A method for analysing dependences in systems and processes
    System analysis & project management tool
    A complex system is a complex network of inter-dependences.
  • 34. Design Structure Matrices
    Identifying dependencies
    minimise iterations in sequential processes
    highlight closely coupled elements
    identify optimal partitioning structures
    Uses a simple notation
    detailed knowledge of nature of dependency not required.
  • 35. Benefits realised in the use of DSM
    Link from the architecture to the delivery team structure
    easier to identify where cooperation needs to be strongest
    Identification of key elements and their dependencies
    easier to understand which elements of the systems of systems needs to be managed most closely
    Functional decomposition and partitioning
    insights into the task of systems integration and the sequence to build in order to achieve stable intermediate forms
    Identification of critical interfaces and components
    easy to see which elements need closer technical analysis.
  • 36. Systems robustness studies
    Coping with Complexity
  • 37. Robustness of Systems of Systems
    Robustness concerns the resilience of a system to maintain a desired emergent property during and after perturbations
    cope with variance
    ensure undesired emergent conditions are not propogated around the System of Systems.
  • 38. Robustness Analysis
    The earlier business impact data showed that overwhelmingly issues are at the systems level
    Robustness problems are complex, interactive and emergent
    transient conditions
    failures in other systems
    multiple root causes
    tolerance spread
    Unforeseen use cases
    Robustness issues are not always present under normal operation
    Static Analysis methods (e.g. FMEA) not effective enough at finding robustness issues.
  • 39. Modelling of Systems of Systems
    Large Scale
    effort to model
    understanding of interactions
    Non-homogeneous nature of individual systems
    different levels of detail
    different modelling techniques
    continuous and state-based behaviours
    different failure modes
    What properties to model?
    those that relate most strongly to robustness.
  • 40. Methods for systems robustness
    Computer simulation
    evaluate options without risk to the real systems
    accepting that for very complex systems there is no model which will be simpler than the Systems of Systems itself
    Monitoring of the systems of systems
    using the real systems of systems instrumented to monitor for behaviours
    very representative
    may be risky using the real system
    Simplified models
    attempt to reduce the complex behaviour to a more simplified abstract model for the specific area of interest
    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.
  • 41. Formal methods
    Coping with Complexity
  • 42. Formal Methods for Systems of Systems
    A technique is mathematically based if its notations and methods can be explained in mathematical terms
    e.g., in predicate logic or in set theory
    underlying mathematics may be embedded in tools
    Formal methods are particular kinds of mathematically based techniques for the precise specification, development, or verification of software and hardware systems
    Formal methods are based on logic, discrete mathematics, and computer-readable languages
    They allow properties of a computer system to be predicted from a mathematical model
    Logical statements are ‘solved’ by establishing truth or falsehood.
    Prof J Woodcock
  • 43. Why bother…?
    "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.
    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, ….”
    [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]
  • 44. ISO 26262 Road Vehicle – Functional Safety
    Adaptation of generic standard IEC 61508
    Addresses the specific needs of developing electrical and electronic systems for road vehicles
    Applies to all activities for developing systems comprising electrical, electronic and software elements that provide safety-related functions.
  • 45. Who is doing this ?
    Scandinavian railways now mandate the use of Formal Methods in systems development
    Ever since the floating point liability, Intel always use Formal Methods – other have followed
    The mobile phone payment system in Japan is formally defined
    All Airbus flight control systems are defined formally from specification through source code to object code
    All Typhoon flight control and engine control software is independently, formally proven.
  • 46. What happens?
    Systems of Systems
  • 47. Code
    Overview and rationale for the approach
    Hand code
    vast majority
    of effort
    compliance to
    Typically only
    Analyse results
    of test
    Reduction to Validation
    and Hardware testing
  • 48. How does the process work?
    • The semantics of the Formal Notation
    • 49. The assumptions
    • 50. The properties to be proved
    • 51. The proof is valid
    • 52. The mapping from the Formal Notation to the executable is understood
    • 53. The assumptions were correct
    Source: QinetiQ systems assurance
  • 54. Background to architectural analysis
    The aim is to be able to check for properties of complex Systems of Systems
    Traditionally done through test, but test has its limitations
    i.e. not exhaustive
    Formal modelling could help as it can be exhaustive, but has to be usable
    Exploitation of appropriate formalism and use of existing modelling tools to enable non-specialist access to formal methods.
  • 55. 48
    Implications for the systems integrator
    Top down development paradigm from requirements to code does not apply
    Systems integrator does not have the required control
    Consequently a conventional view of correctness by construction does not work
    Systems integrator holds the risk
    Control over software and architecture risks can make or break a large complex project
  • 56. 49
    Implications for the systems engineer
    The analysis, through the exploitation of mathematical proof, enables :
    identification of requirements (properties) under normal and abnormal conditions
    ‘what-if’ the architecture
    identify risks, accept results or adapt
    plan testing
    All of which is robust and underpins acceptance of the System of Systems
  • 57. The Benefits
    The benefits can be described as follows:
    avoiding errors being discovered late in the development cycle
    reduce the cost of the re work cycle...hidden re-work factory
    Cost benefits are difficult to measure, but we do understand …..
    recall costs >£20M
    production line delay ~£1M per day
    software cycle ~£100k
  • 58. Summary & conclusions
    Coping with Complexity
  • 59. Summary
    Vehicle systems are necessarily becoming more complex through:
    response to competitive pressures
    increasing reliance on embedded software systems
    Simple systems have evolved into Systems of Systems
    Increasing complexity is having and will continue to have a profound business impact
    Complexity must be managed effectively
    Systems design and the role of the architect are more critical than ever
    The role of the OEM as the systems integrator has become more difficult and riskier.
  • 60. Summary
    There are heuristics which can help us manage the complexity of closed or collaborative systems
    We have explored three techniques which underpin the heuristics
    Design Structure Matrices
    robustness of Systems of Systems
    Formal Methods
    Methods are built on mathematical principles and enable
    identification of dependencies and optimal partitioning
    identification of which interface properties are critical to robustness through modelling and simulation
    formal proof that those properties can be maintained under all desired and undesired emergent conditions
  • 61. Conclusions
    Increasing requirement for the use of Formal Methods
    Issues discussed are not totally unique to the automotive industry
    Would recommend a framework architecture model is developed for the auto industry
    building on the efforts of AUTOSAR
    Interesting research going on in the field of complexity science which can be drawn into this arena
    Systems modelling techniques – multi-domain
    Symmetry and invariance
  • 62. Thank you for listening
    Coping with Complexity
  • 63. Visit and follow us
    Our web-site:
    Visit us on LinkedIn
    Follow us on twitter
    E-mail us at
  • 64. Questions
    Feedback please to:
    A copy of this presentation is available at