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

1. Coping with Complexity McKinney Associates Francis McKinney 1

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

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 3

4. Tonight’s agenda Coping with Complexity 4

5. Contents What is complexity? How did we get here? The business impact of complexity Coping methods Summary & conclusions 5

6. What is complexity? Coping with Complexity 6

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 7

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

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

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 10

11. How did we get here? Coping with Complexity 11

12. Where does it come from? Processes Organisation Programme Management Technical Multidimensional Issues compound Solutions must also be multidimensional Only describing the technical and programme management 12

13. Evolution of systems 13

14. Hierarchy of system views 14

15. Properties of Systems of Systems Autonomy of elements Evolutionary development Heterogeneous elements Sharing of resources Geographic distribution Emergent behaviour. 15

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

17. High-end vehicle architecture Powertrain Systems Safety Systems Chassis Systems Body Systems PTC Heater Motors x N Radar Sensor Cluster ACC DSC/ABS Climate Module Rear Climate Control Restraints Control Parking Aid LH Sensor RHR Window Motor Blindspot Monitor LH Mirror Rear BCU Alternator 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 Receivers LHR Door Module Key Interface Battery Management TPMS Diagnostics Window Motor RH Door Module Gateway J1962 Connector Steering Switches Instruments Infotainment Systems Control Panel 17

18. Comparisons with other complex systems 18

19. The business impact of complexity Coping with Complexity 19

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. 20 Source: McKinsey & Co

21. Innovation contribution of software systems Flexibility of software based systems Disruption from innovation Rapid evolution Convergence from neighbouring industries. 21 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 22

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. 23 Source: McKinsey & Co

24. Coping strategies Coping with Complexity 24

26. Validation is an expensive and risky error discovery process

27. Try and discover early and fix quickly.25 Drive costs here Errors here Source: INCOSE

28. Systems Integrator risks Prime/Integrator 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 Contracts Integration at a unit level Contracts 26

29. Actual validation effort Projected validation effort Actual complexity Projected complexity System Validation vs. Complexity Verification Cost Complexity Complexity increasing N Unbounded risk/cost validation effort increases Nx Time 27

30. Heuristics for Systems of Systems 28

31. Three steps for coping 29

32. Design structure matrices Coping with Complexity 30

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

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

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

36. Systems robustness studies Coping with Complexity 34

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

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

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

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

41. Formal methods Coping with Complexity 39

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 40

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] 41

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

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

46. What happens? Time Systems of Systems LegacySystems OTSSystems New Systems Software Software Software 44

47. Code Development System Requirements Verification Review Test Analysis Overview and rationale for the approach Hand code Autocode Specification Model Typically vast majority of effort Typically compliance to Standards/process Typically only Analyse results of test Reduction to Validation and Hardware testing Exploit automated proof

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 correctSource: 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. 47

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 50

58. Summary & conclusions Coping with Complexity 51

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

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 53

61. Conclusions Increasing requirement for the use of Formal Methods ISO26262 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 54

62. Thank you for listening Coping with Complexity 55

63. Visit and follow us Our web-site: www.mckinneyassociates.co.uk Visit us on LinkedIn http://uk.linkedin.com/pub/francis-mckinney/8/b58/a79 Follow us on twitter @mckinneyassoc E-mail us at enquiries@mckinneyassociates.co.uk 56

64. Questions Feedback please to: http://www.mckinneyassociates.co.uk/blog.html A copy of this presentation is available at http://www.mckinneyassociates.co.uk/ 57