Transcript Document

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

    

Draw some parallels of Automotive with Defence and Aerospace

By providing some insight into Automotive Why is Automotive Powertrain Control ‘High Integrity’?

   

Commercial truths Vehicle System Complexity X-by-Wire System interaction – Example Torque demand Complexity and Complexity growth trends Complexity and Reliability in Electronics

The AUTOSAR concept The move to Commodity ‘Components’ from ‘Equipments’

2  

High Quality (The ZERO ppm target) 0 ppm software

Standardisation, Sourcing and Business Model

Insert filename

Private - Rolls-Royce Proprietary Information

3

High Integrity and Automotive

 

Commercial truths

The product warranty includes software warranty

Implies not only replacement but other consequential costs

-

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 Impact of ‘tampering’ on warranty (e.g. chip-tuning) Vehicle System Complexity

Typical luxury saloon car some 70off 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 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

Driver Demand (Pedal) Braking Control (ABS) Traction Control (ETC) Stability Control (ESP) Adaptive Cruise Control (ACC) Lane Departure Dynamic Performance Control

Torque Demand Example (Simplified)

4 Gearchange Interaction (Automatic Box) Modelled Transmission Losses (Gearbox, Differential)

Transmission Torque Demand Plant Alternator Power Steering Air Conditioning

Insert filename

Private - Rolls-Royce Proprietary Information

Complexity and Complexity Growth

5 

Complexity growth as it relates to Electronic controls

…and by extrapolation embedded control software

In automotive this has been exponential

On average, doubling every 4 years

  

Despite attempts to halt its progress

-

Strategy changes Architecture changes Affects I/O, CPU throughput, ROM (Flash) and RAM Has been happening since at least mid-1980s 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

A few trend lines to give you the idea….

From a typical powertrain controller for a light passenger car Complexity Trends

Insert filename

Private - Rolls-Royce Proprietary Information

Complexity and Reliability in Electronics

Electronics dominates cost of Vehicle

Already at >25%, expected to exceed 40% by 2012

6 

Example - French automotive reliability statistics

 

Vehicle failure rates/types related to number of ‘interconnects’ Electrical ‘interconnects’ dominate vehicle failure rates

 -

Not just physical connectors ‘Interconnects’ = boundaries between equipments

 -

Equipments frequently sourced from competitive suppliers Equipment definitions – the reality of design

-

Specifications are fluid

-

Frequently non-existent at contract award Requirements analysis is Requirement ‘discovery’ process

Reality is that ‘Software’ dominates the ‘Reliability’ issue

‘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 But restarting system/replacing parts makes faults ‘evaporate’

Insert filename

Private - Rolls-Royce Proprietary Information

Complexity and Reliability in Electronics… …and Software

Today’s reality is ‘commodity equipments’

Interconnects reflects inter-supplier boundaries

7 

Solution – reduce number of boundaries?

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 !

Deploy anywhere in a ‘vehicle’ network

But precipitates other problems…

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

ECU 1 Component 1 Component 2 RTE Basic Software The AUTOSAR RTE concept (a Virtual Functional Bus)

9

ECU 2 Component 3 ...

RTE Basic Software Inter Bus Gateway ECU n Component 4 RTE Basic Software Physical Bus 1 Physical Bus 2

Insert filename

Private - Rolls-Royce Proprietary Information

 

The move to Commodity ‘Components’ from ‘Equipments’

Push to commoditise product at ‘component’ levels But product made of commodity components needs standards

  

Architecture, Interfaces and Performance (see AUTOSAR)

-

‘Co-operate on standards, Compete on Implementation’ Validate the architecture by design

-

Validation of a product can be substantially reduced But assuring integrity means some ‘certification’-like system

-

Has to be standard acceptable to supplier, customer and integrator

10 

Needs a different business model from traditional embedded

  

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

11

Corresponding Components Component Descriptions System Constraints Vehicle System Requirements ECU Configuration ECU Configuration Description ECU ECU ECU Software Component Descriptions System Configuration Generator ECU Configuration Generator Software Components ECU Hardware Component Descriptions System Configuration Description ECU Hardware Components

Insert filename

Private - Rolls-Royce Proprietary Information

High Quality (The Zero ppm target)

12 

We all value the improved quality and reliability of our vehicles

Started by Japanese (who still lead! – see JD Power surveys)

-

Ethic is of ZERO failure tolerance (every failure is significant)

Strive for 0ppm Quality – is a design issue

  

Not just vehicle level assembly or manufacturing Selection of every sub-assembly and component in final system

-

Design and Manufacture

-

Attention to detail Critical review of Design, Design margin, and process of manufacture

-

Mechanical, Electrical or Software

Tier 1 have SIGNIFICANT Advanced Quality Engineering departments

Different Quality Organisation for Fielded Failure (inc 0km returns)

Insert filename

Private - Rolls-Royce Proprietary Information

0ppm Software

13 

Not literally, but the principle is the same as for mechanical

Significant education amongst VMs regarding ‘residual errors’

-

but tradition allows mitigating design and run-time strategies

Design and Test rigour is largely self-regulated

-

But industry regulation defines minimum bar only!

-

Most suppliers aim significantly higher, the commercial imperative!

Many industries struggling with these same challenges

   

Absolute errors are F(size, process) Size - (Complexity) rising (fast) Process - Software Engineering improvements (slow)

-

But insufficient to mitigate size growth Coverage – as an absolute, is weakening

-

Judgement of economically ‘sufficient’ is increasing risk

Insert filename

Private - Rolls-Royce Proprietary Information

Component Descriptions System Constraints Vehicle System Requirements

Standardisation as an Antidote?

14

Corresponding Components ECU Configuration ECU Configuration Description ECU ECU ECU Software Component Descriptions System Configuration Generator ECU Configuration Generator Software Components ECU Hardware Component Descriptions System Configuration Description ECU Hardware Components

Insert filename

Private - Rolls-Royce Proprietary Information

  

Standardisation as an Antidote?

15

Push ‘re-use’ hard enough and confidence increases?

‘No change’/complete re-use brings higher confidence

Requires significant architectural standardisation But why restrict this to ‘in house’ re-use?

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 Standards need to meet ‘evolution’ requirements (continuously)

Applies to Hardware as well as Software

Platform Standards

Would allow portability of components

-

Implies some re-certification costs for new environment

Integration Risks and Warranty?

Tradition is Hardware supplier provides warranty for entire product!

Insert filename

Private - Rolls-Royce Proprietary Information

  

A new Business Model for embedded controls

16

Many suppliers, same ‘component’ product – different implementation

Current software business is marginal

-

not sold as product in own right Sold as enabler for mechanical product

 

Sold as flexibility to overcome system issues!!

-

Revenue is from amortised cost on each mechanical part sold Future business model?

Software no longer about bespoke customisation

   

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 What is the future

  

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  

Our methodology cannot keep pace with complexity

..so we need a new paradigm The ‘next’ level in Computing Science

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’

‘Brute force’ compute will not allow us the evolutionary capacity

Are there ‘revolutionary’ techniques?

What abstract ‘learning’ capabilities can we adopt?

 -

Can the learning be sufficient that failure is insignificant?

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 [email protected]

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