![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](https://image.slidesharecdn.com/ietprestigelecturecopingwithcomplexity7thdecember-12980700987922-phpapp02/85/Iet-Prestige-Lecture-Coping-With-Complexity-7th-December-43-320.jpg)
Iet Prestige Lecture Coping With Complexity 7th December
- 1. Coping with ComplexityMcKinney AssociatesFrancis McKinney1
- 2. IntroductionsMcKinney 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 expertiseManagement and delivery of complex projectsSystems design and integrationSystems thinking and holistic problem solvingInnovation and technology managementInterim management solutions3
- 4. Tonight’s agendaCoping with Complexity4
- 5. ContentsWhat is complexity?How did we get here?The business impact of complexityCoping methodsSummary & conclusions5
- 6. What is complexity?Coping with Complexity6
- 7. Complex systemsA 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 definition7
- 8. Characteristics of complex systemsThe emergent properties will almost certainly contain undesirable as well as desirable behavioursComplexity is related to hierarchy and therefore the position of the observerLevel of interaction of the elements means the emergent properties are not always repeatable or predictableThey have nearly always evolved from a system which seemed to work.8
- 9. Properties of complex systemsA complex system requires a great deal of information to specify – a really important feature of complexityComplexity is an absolute and quantifiable property of a system - once a metric and boundary has been establishedApparent 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 systemsComplexity arises in a system as more is asked of it Complexity manifests itself at the interfaces between elements or modulesIt is the role of the architect to keepthe actual complexity as low as possiblethe system uncomplicated.Complexity is inherently neither a good nor bad, however it must be managed10
- 11. How did we get here?Coping with Complexity11
- 12. Where does it come from?ProcessesOrganisationProgramme ManagementTechnicalMultidimensionalIssues compoundSolutions must also be multidimensionalOnly describing the technical and programme management12
- 14. Hierarchy of system views14
- 15. Properties of Systems of SystemsAutonomy of elementsEvolutionary developmentHeterogeneous elementsSharing of resourcesGeographic distribution Emergent behaviour.15
- 16. The growth of siliconIn 1970 a control unit had a memory capacity of 1KbIn 2010 it is typical to see 1Mb memory capacityIn premium level vehicles the number of ECUs is approximately 75There 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 architecturePowertrainSystemsSafetySystemsChassisSystemsBodySystemsPTC HeaterMotors x NRadarSensor ClusterACCDSC/ABSClimate ModuleRear Climate ControlRestraints ControlParking AidLH SensorRHR Window MotorBlindspot MonitorLH MirrorRear BCUAlternatorSteering AngleEngine ControlPark Brake ControlOccupancy SensingRH SensorTransm’n ControlLH Switch PackRHR Door ModuleRH Seat ModuleTransm’n ControlSuspension ControllerAdaptive LightingAlarm SounderWindow MotorRHF Door ModuleFront BCUDamping ControlPedestrian DetectionGearshifter ControlRain/Light SensorLHR MotorRH MirrorGearshifter ControlSteering ColumnGearshifter ControlFFH ControlRH Switch PackLH Seat ModuleReceiversLHR Door ModuleKey InterfaceBattery ManagementTPMSDiagnosticsWindow MotorRH Door ModuleGatewayJ1962ConnectorSteering SwitchesInstrumentsInfotainment SystemsControl Panel17
- 18. Comparisons with other complex systems18
- 19. The business impact of complexityCoping with Complexity19
- 20. A changing businessAutomotive is traditionally a mechanically led businessShifting models for revenueImplications for skillsImpact on supply chains and procurement models.20Source: McKinsey & Co
- 21. Innovation contribution of software systemsFlexibility of software based systemsDisruption from innovationRapid evolutionConvergence from neighbouring industries.21Source: McKinsey & Co
- 22. Whole-life costs of complexityOccurrence of customer level defects Cost to repair defects in a distributed information systemRoot cause of network issues is difficult to determineComponent with symptoms gets replaced.Source: McKinsey & Co22
- 23. Impact of repair costs on warrantySystem issues difficult to diagnose and repairIssues can be emergent and have complicated use casesReplacing controllers and sensors always easiest and lowest risk option.23Source: McKinsey & Co
- 24. Coping strategiesCoping with Complexity24
- 25. Committed lifecycle costs against timeLeverage early
- 26. Validation is an expensive and risky error discovery process
- 27. Try and discover early and fix quickly.25Drive costs hereErrors hereSource: INCOSE
- 28. Systems Integrator risksPrime/Integratoreg Boeing, Ford, NG…OEM nOEM 1e.g. NG, Bosch,…|| . . . ||Competitive selection amongst suppliers worldwideCompetitive selection amongst suppliers worldwideSupplier …NSupplier A1System …NSystem A……Code …NCode ASystem IntegrationContractsIntegration at a unit levelContracts26
- 29. Actual validation effortProjected validation effortActual complexityProjected complexitySystem Validation vs. ComplexityVerificationCostComplexityComplexity increasing NUnbounded risk/costvalidation effort increases NxTime27
- 30. Heuristics for Systems of Systems28
- 31. Three steps for coping 29
- 32. Design structure matricesCoping with Complexity30
- 33. Design Structure MatricesA method for analysing dependences in systems and processesSystem analysis & project management toolA complex system is a complex network of inter-dependences.31
- 34. Design Structure MatricesIdentifying dependenciesminimise iterations in sequential processeshighlight closely coupled elementsidentify optimal partitioning structuresUses a simple notationdetailed knowledge of nature of dependency not required.32
- 35. Benefits realised in the use of DSMLink from the architecture to the delivery team structureeasier to identify where cooperation needs to be strongestIdentification of key elements and their dependencieseasier to understand which elements of the systems of systems needs to be managed most closelyFunctional decomposition and partitioninginsights into the task of systems integration and the sequence to build in order to achieve stable intermediate formsIdentification of critical interfaces and componentseasy to see which elements need closer technical analysis.33
- 36. Systems robustness studiesCoping with Complexity34
- 37. Robustness of Systems of SystemsRobustness concerns the resilience of a system to maintain a desired emergent property during and after perturbationscope with varianceensure undesired emergent conditions are not propogated around the System of Systems.35
- 38. Robustness AnalysisThe earlier business impact data showed that overwhelmingly issues are at the systems levelRobustness problems are complex, interactive and emergenttransient conditionsfailures in other systems multiple root causestolerance spreadUnforeseen use casesRobustness issues are not always present under normal operationStatic Analysis methods (e.g. FMEA) not effective enough at finding robustness issues.36
- 39. Modelling of Systems of Systems Large Scaleeffort to modelunderstanding of interactionsNon-homogeneous nature of individual systemsdifferent levels of detail different modelling techniquescontinuous and state-based behavioursdifferent failure modesWhat properties to model?those that relate most strongly to robustness.37
- 40. Methods for systems robustnessComputer simulationevaluate options without risk to the real systemsaccepting that for very complex systems there is no model which will be simpler than the Systems of Systems itselfMonitoring of the systems of systemsusing the real systems of systems instrumented to monitor for behavioursvery representativemay be risky using the real systemSimplified modelsattempt to reduce the complex behaviour to a more simplified abstract model for the specific area of intereste.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 methodsCoping with Complexity39
- 42. Formal Methods for Systems of SystemsA technique is mathematically based if its notations and methods can be explained in mathematical termse.g., in predicate logic or in set theoryunderlying mathematics may be embedded in toolsFormal methods are particular kinds of mathematically based techniques for the precise specification, development, or verification of software and hardware systemsFormal methods are based on logic, discrete mathematics, and computer-readable languagesThey allow properties of a computer system to be predicted from a mathematical modelLogical statements are ‘solved’ by establishing truth or falsehood.Prof J Woodcock40
- 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 SafetyAdaptation of generic standard IEC 61508Addresses the specific needs of developing electrical and electronic systems for road vehiclesApplies 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 developmentEver since the floating point liability, Intel always use Formal Methods – other have followedThe mobile phone payment system in Japan is formally definedAll Airbus flight control systems are defined formally from specification through source code to object codeAll Typhoon flight control and engine control software is independently, formally proven.43
- 46. What happens?TimeSystems of SystemsLegacySystemsOTSSystemsNewSystemsSoftwareSoftwareSoftware44
- 47. CodeDevelopmentSystemRequirementsVerificationReviewTestAnalysisOverview and rationale for the approachHand codeAutocodeSpecificationModelTypically vast majority of effortTypically compliance to Standards/processTypically onlyAnalyse results of testReduction to Validation and Hardware testingExploit automated proof
- 48. How does the process work?46The 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 correctSource: QinetiQ systems assurance
- 54. Background to architectural analysisThe aim is to be able to check for properties of complex Systems of SystemsTraditionally done through test, but test has its limitationsi.e. not exhaustiveFormal modelling could help as it can be exhaustive, but has to be usableExploitation of appropriate formalism and use of existing modelling tools to enable non-specialist access to formal methods.47
- 55. 48Implications for the systems integratorTop down development paradigm from requirements to code does not applySystems integrator does not have the required controlConsequently a conventional view of correctness by construction does not workSystems integrator holds the riskControl over software and architecture risks can make or break a large complex project
- 56. 49Implications for the systems engineerThe analysis, through the exploitation of mathematical proof, enables :identification of requirements (properties) under normal and abnormal conditions‘what-if’ the architectureidentify risks, accept results or adaptplan testingAll of which is robust and underpins acceptance of the System of Systems
- 57. The BenefitsThe benefits can be described as follows:avoiding errors being discovered late in the development cyclereduce the cost of the re work cycle...hidden re-work factoryCost benefits are difficult to measure, but we do understand …..recall costs >£20Mproduction line delay ~£1M per daysoftware cycle ~£100k50
- 58. Summary & conclusionsCoping with Complexity51
- 59. SummaryVehicle systems are necessarily becoming more complex through:response to competitive pressuresincreasing reliance on embedded software systemsSimple systems have evolved into Systems of SystemsIncreasing complexity is having and will continue to have a profound business impactComplexity must be managed effectivelySystems design and the role of the architect are more critical than everThe role of the OEM as the systems integrator has become more difficult and riskier.52
- 60. SummaryThere are heuristics which can help us manage the complexity of closed or collaborative systemsWe have explored three techniques which underpin the heuristicsDesign Structure Matricesrobustness of Systems of SystemsFormal MethodsMethods are built on mathematical principles and enableidentification of dependencies and optimal partitioningidentification of which interface properties are critical to robustness through modelling and simulationformal proof that those properties can be maintained under all desired and undesired emergent conditions53
- 61. ConclusionsIncreasing requirement for the use of Formal MethodsISO26262Issues discussed are not totally unique to the automotive industryWould recommend a framework architecture model is developed for the auto industrybuilding on the efforts of AUTOSARInteresting research going on in the field of complexity science which can be drawn into this arenaSystems modelling techniques – multi-domainSymmetry and invariance54
- 62. Thank you for listeningCoping with Complexity55
- 63. Visit and follow usOur web-site:www.mckinneyassociates.co.ukVisit us on LinkedInhttp://uk.linkedin.com/pub/francis-mckinney/8/b58/a79Follow us on twitter@mckinneyassocE-mail us atenquiries@mckinneyassociates.co.uk56
- 64. QuestionsFeedback please to: http://www.mckinneyassociates.co.uk/blog.htmlA copy of this presentation is available at http://www.mckinneyassociates.co.uk/57
Editor's Notes
- #10: 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
- #14: 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.
- #15: As systems have evolved they have also become nested and hierarchical sometimes the single elements of SoS are in themselves simple systems.
- #18: 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
- #29: 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.
- #33: 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).
- #36: 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.
- #38: 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.
- #39: None of these is a complete solution, almost certianly a hybrid approach will need to be used