High Integrity and High Quality Software The changing

High Integrity and High Quality Software: The changing expectations of Automotive Stuart Jobbins Software Centre of Excellence © 2007 Rolls-Royce plc The information in this document is the property of Rolls-Royce plc and may not be copied or communicated to a third party, or used for any purpose other than that for which it is supplied without the express written consent of Rolls-Royce plc. This information is given in good faith based upon the latest information available to Rolls-Royce plc, no warranty or representation is given concerning such information, which must not be taken as establishing any contractual or other commitment binding upon Rolls-Royce plc or any of its subsidiary or associated companies.

Overview 2 l Draw some parallels of Automotive with Defence and Aerospace l By providing some insight into Automotive l Why is Automotive Powertrain Control ‘High Integrity’? l l Commercial truths Vehicle System Complexity X-by-Wire System interaction – Example Torque demand l Complexity and Complexity growth trends l Complexity and Reliability in Electronics l The AUTOSAR concept l The move to Commodity ‘Components’ from ‘Equipments’ l High Quality (The ZERO ppm target) l 0 ppm software l Standardisation, Sourcing and Business Model Insert filename Private - Rolls-Royce Proprietary Information

High Integrity and Automotive 3 l Commercial truths l l The product warranty includes software warranty Implies not only replacement but other consequential costs - l Customer dissatisfaction, Hire car etc Consequential damage (mechanical etc) Other removals/replacements/spares Service tool updates etc Service campaigns (disruptive), Recall campaigns (bankruptcy? ) - Penalties limited in contract, as volume sensitivity is significant l Impact of ‘tampering’ on warranty (e. g. chip-tuning) l Vehicle System Complexity l l Typical luxury saloon car some 70 off intelligent nodes Increasingly X-by-Wire Controls ‘protect’ as well as provide functionality More Authority / High-Integrity (mechanical assist/full authority) - Braking controllers / Brake by wire - Steering controllers / Steer by wire l l But lots of interaction…. . Significant value is in the way the components interact - System engineering - (mostly in the control system!) Insert filename Private - Rolls-Royce Proprietary Information

Torque Demand Example (Simplified) Driver Demand (Pedal) 4 Gearchange Interaction (Automatic Box) Modelled Transmission Losses (Gearbox, Differential) Transmission Braking Control (ABS) Traction Control (ETC) Stability Control (ESP) Adaptive Cruise Control (ACC) Lane Departure Dynamic Performance Control Torque Demand Plant Alternator Power Steering Air Conditioning Insert filename Private - Rolls-Royce Proprietary Information

Complexity and Complexity Growth 5 l Complexity growth as it relates to Electronic controls l …and by extrapolation embedded control software l In automotive this has been exponential l l On average, doubling every 4 years Despite attempts to halt its progress - Strategy changes - Architecture changes l l Affects I/O, CPU throughput, ROM (Flash) and RAM Has been happening since at least mid-1980 s product - Early 8 -bit micro work through to current day - Development step – digital selection up to 3 years ahead of this! - Reality is that Electronic architectures enable complexity growth l A few trend lines to give you the idea…. l From a typical powertrain controller for a light passenger car Complexity Trends Insert filename Private - Rolls-Royce Proprietary Information

Complexity and Reliability in Electronics 6 l Electronics dominates cost of Vehicle l Already at >25%, expected to exceed 40% by 2012 l Example - French automotive reliability statistics l l Vehicle failure rates/types related to number of ‘interconnects’ Electrical ‘interconnects’ dominate vehicle failure rates - Not just physical connectors l ‘Interconnects’ = boundaries between equipments - Equipments frequently sourced from competitive suppliers l Equipment definitions – the reality of design - Specifications are fluid - Frequently non-existent at contract award - Requirements analysis is Requirement ‘discovery’ process l Reality is that ‘Software’ dominates the ‘Reliability’ issue l l ‘Software’ includes ‘Requirements and System design’ issues Real problem is system complexity, interaction and transient nature - ‘Failed part’ is the warranty level requirement / history - ‘No Fault Found’ is unacceptable l But restarting system/replacing parts makes faults ‘evaporate’ Insert filename Private - Rolls-Royce Proprietary Information

Complexity and Reliability in Electronics… …and Software 7 l Today’s reality is ‘commodity equipments’ l Interconnects reflects inter-supplier boundaries l Solution – reduce number of boundaries? l l l Not at Physical level, more about ‘supplier’ boundaries VMs are targeting more ownership of application in ‘nodes’ VM Strategy - ‘Have made’ once, own and re-use, accrue - Neatly forgets evolution of requirements ! l Deploy anywhere in a ‘vehicle’ network l But precipitates other problems… l Diagnostic route for ‘failed’ parts and warranty responsibility - Multi-sourced hardware and software components - ‘Integrator’ has to resolve! - Burden of proof is a nightmare Insert filename Private - Rolls-Royce Proprietary Information

The AUTOSAR architectural concepts 8 The Application A set of (customer owned, but supplier generated) features, whose disposition amongst the network of ECUs is determined at Configuration time. All application components must conform to a standardised RTE interface (a book of service standards). All inter-feature communication is via the RTE The Run-Time Environment (RTE) A per ECU/Application/Vehicle set-instance of a configurable API Largely modelled on a POSIX ‘sockets’ type concept in services but each instance carries only the ‘required services’ Basic Software (BSW) E. g. System (inc RTOS), Memory, Comms, I/O abstract services A well-defined service oriented set of drivers with device specific roots matched to the common automotive microcontrollers and devices (Also allows some custom drivers) ECU Hardware Insert filename Private - Rolls-Royce Proprietary Information

The AUTOSAR RTE concept (a Virtual Functional Bus) ECU 1 Component 2 ECU 2 Component 3 9 ECU n . . . Component 4 RTE RTE Basic Software Inter Bus Gateway Physical Bus 1 Physical Bus 2 Insert filename Private - Rolls-Royce Proprietary Information

The move to Commodity ‘Components’ from ‘Equipments’ 10 l Push to commoditise product at ‘component’ levels l But product made of commodity components needs standards l Architecture, Interfaces and Performance (see AUTOSAR) - ‘Co-operate on standards, Compete on Implementation’ l Validate the architecture by design - Validation of a product can be substantially reduced l But assuring integrity means some ‘certification’-like system - Has to be standard acceptable to supplier, customer and integrator l Needs a different business model from traditional embedded l l l Hardware & Software sold at cost, as enabler for mechanical product ‘Commodity’ product has to be sold on value (need differentiation) Issues are then product liability - Potential ‘cost’ of failure versus revenue stream from software Insert filename Private - Rolls-Royce Proprietary Information

System Generation from Standard Components Component Descriptions Corresponding Components Vehicle System Requirements System Constraints Software Component Descriptions 11 System Configuration Generator ECU Hardware Component Descriptions ECU Configuration ECU Description Configuration Description ECU Configuration Generator System Configuration Description ECU ECU Software Components ECU Hardware Components Insert filename Private - Rolls-Royce Proprietary Information

High Quality (The Zero ppm target) 12 l We all value the improved quality and reliability of our vehicles l Started by Japanese (who still lead! – see JD Power surveys) - Ethic is of ZERO failure tolerance (every failure is significant) l Strive for 0 ppm Quality – is a design issue l l Not just vehicle level assembly or manufacturing Selection of every sub-assembly and component in final system - Design and Manufacture - Attention to detail l Critical review of Design, Design margin, and process of manufacture - Mechanical, Electrical or Software l Tier 1 have SIGNIFICANT Advanced Quality Engineering departments l Different Quality Organisation for Fielded Failure (inc 0 km returns) Insert filename Private - Rolls-Royce Proprietary Information

0 ppm Software 13 l Not literally, but the principle is the same as for mechanical l Significant education amongst VMs regarding ‘residual errors’ - but tradition allows mitigating design and run-time strategies l Design and Test rigour is largely self-regulated - But industry regulation defines minimum bar only! - Most suppliers aim significantly higher, the commercial imperative! l Many industries struggling with these same challenges l l l Absolute errors are F(size, process) Size - (Complexity) rising (fast) Process - Software Engineering improvements (slow) - But insufficient to mitigate size growth l Coverage – as an absolute, is weakening - Judgement of economically ‘sufficient’ is increasing risk Insert filename Private - Rolls-Royce Proprietary Information

Standardisation as an Antidote? Component Descriptions Corresponding Components Vehicle System Requirements System Constraints Software Component Descriptions 14 System Configuration Generator ECU Hardware Component Descriptions ECU Configuration ECU Description Configuration Description ECU Configuration Generator System Configuration Description ECU ECU Software Components ECU Hardware Components Insert filename Private - Rolls-Royce Proprietary Information

Standardisation as an Antidote? 15 l Push ‘re-use’ hard enough and confidence increases? l l ‘No change’/complete re-use brings higher confidence Requires significant architectural standardisation l But why restrict this to ‘in house’ re-use? l l l Co-operating customers and common (non-competitive) standards Common architectures, common interfaces, common components Also reduction in engineering costs - Specify and implement once - Competition through multiple supply - ‘Shrink-wrapped’ solutions compete on technical/performance basis l Standards need to meet ‘evolution’ requirements (continuously) l Applies to Hardware as well as Software l l Platform Standards Would allow portability of components - Implies some re-certification costs for new environment l Integration Risks and Warranty? l Tradition is Hardware supplier provides warranty for entire product! Insert filename Private - Rolls-Royce Proprietary Information

A new Business Model for embedded controls 16 l Many suppliers, same ‘component’ product – different implementation l Current software business is marginal - not sold as product in own right - Sold as enabler for mechanical product l Sold as flexibility to overcome system issues!! - Revenue is from amortised cost on each mechanical part sold l Future business model? l Software no longer about bespoke customisation l l About assembly of standard components to meet a system goal Components might be ‘mechanical actuator plus software’ or… …’Engine plus control software’ as a bundle. . … but other components (ECU Hardware, Comms) independently sourced l What is the future l l l A ‘holistic’ view of all the computation needs/availability Dispersion of tasks around the ‘network’ Different ‘dependability’ nodes/networks Component purchase, freedom of deployment If the customers are thinking like this… - …then maybe the automotive experience is significant Insert filename Private - Rolls-Royce Proprietary Information

Some personal thoughts… 17 l Our methodology cannot keep pace with complexity l . . so we need a new paradigm l The ‘next’ level in Computing Science l Consider my 3 year-old son, catching a ball (some of the time!) - No way can he comprehend the complex trajectory problem - No way can he ‘compute’ an appropriate ‘capture’ solution - With current sensor/compute technology, it is doubtful that it could be achieved with current ‘portable’ IT solutions, real-time - Certainly not possible with short ‘flights’ l ‘Brute force’ compute will not allow us the evolutionary capacity l l Are there ‘revolutionary’ techniques? What abstract ‘learning’ capabilities can we adopt? - Can the learning be sufficient that failure is insignificant? l Do Tiger Woods/Michael Schumacher etc have ‘off days’? - Need to be MUCH better than human repeatability Insert filename Private - Rolls-Royce Proprietary Information

Thankyou Stuart Jobbins Head of Software Centre of Excellence Stuart. jobbins@Rolls-Royce. com © 2007 Rolls-Royce plc The information in this document is the property of Rolls-Royce plc and may not be copied or communicated to a third party, or used for any purpose other than that for which it is supplied without the express written consent of Rolls-Royce plc. This information is given in good faith based upon the latest information available to Rolls-Royce plc, no warranty or representation is given concerning such information, which must not be taken as establishing any contractual or other commitment binding upon Rolls-Royce plc or any of its subsidiary or associated companies.