the connected car: challenges for free competition ... · neil pattemore figiefa technical director...

Neil Pattemore FIGIEFA Technical Director

The ‘connected car’: Challenges for free competition, innovation and consumer choice

in the automotive aftermarket

3,5 million employees over 500,000

companies serving 260 million motoring

consumers

Roadside Rescue Services

Multi-brand Repairers

Providers of Technical

Information

Parts Distributors Tools Manufacturers

Parts suppliers/

Manufacturers

The multi-brand Aftermarket Value Chain

Equal level playing field between independent service providers and authorised repairers

The Repair World today

= Consumer choice

Connected cars - New world of digital servicing

Increasing wireless transfer of digital data:

• Telematics technology: New possibilities to transfer in-vehicle digital data wirelessly.

• This is in principle good and should benefit the consumer. • However: This technical innovation should not create a monopoly.

Copyright: Bosch

Remote diagnostics

Maintenance management

Fuel management

Theft surveillance

Accident management

Mandate for an ‘Interoperable Platform’

• Article Art.12 (2) of the eCall Regulation: Recognises the need for the development of ‘third party services’ in the digital era.

• Gives a mandate to the Commission to investigate a legislative proposal on:

“the technical requirements for an interoperable, standardised, secure and open-access platform”.

• This Article is now being implemented in the ‘Co-operative Intelligent Transport System’ (C-ITS) forum.

The Vehicle Manufacturers’ Extended Vehicle (ExVe) concept

Proposed future access to vehicle digital data

In-vehicle digital data

Vehicle Manufacturers’ ‘Extended Vehicle’ concept

Multibrand diagnostics

Vehicle system digital data

(examples)

VM’s server

Independent + Non-monitored

B2B contracts

• Restricted • Monitored

Standardised 16 pin OBD connector: reduced

Independent Operators

Consequences for the independent aftermarket

Key changes:

• No more direct, independent communication with the vehicle.

• VMs are able to control the access and management of the real-time in-vehicle digital data

• Controlled and conditional access only through a main competitor.

Independent Operator Service offers would have to follow the vehicle manufacturers’ data content and business models!

Restricts innovation, independent entrepreneurship, aftermarket competitiveness and consumer choice!

Does this meet the Mandate?

NO! - The vehicle manufacturers interpret the requirements to ensure that all access to in-vehicle data is controlled by them, providing a complete monopolistic solution.

This circumvents the intent and the requirements of the EP’s eCall article and recital.

Restricts access and hides any transparency to in-vehicle data.

Changes the basis of free and un-monitored access to in-vehicle data via the existing standardised connector into a contractual ‘service’ with each vehicle manufacturer.

To ensure the continued effectiveness of existing BER, Euro 5/6 and Euro VI Regulations.

What the multi-brand automotive aftermarket needs:

Equal access Equal information Equal timescale

The vehicle driver should be able to choose what width/depth of data is exchanged with whom for what services.

‘Standardised, interoperable, secure and open platform for possible future in-vehicle applications or services’.

Basic principles

Independent Interoperable Telematics Platform

Examples

Release of data

Decentralised telematics

system

Authorised repairers

secure access

Upon

consumer

consent:

Repairers

Conclusions for EP DSM Report

We invite you to:

Echo the eCall mandate with a robust macro-political requirement.

Call upon the Commission to address the ‘platforms of things (– on wheels)’ and to develop rules and standards for their interoperability and avoid monopolisation through technical design to ensure competition-neutrality and consumer choice in the digital era.

This relates to vehicles, but also other industrial products with remote servicing capabilities.

Thank you very much!

FIGIEFA Neil Pattemore

Technical Director

Independent Interoperable Telematics Platform

examples

data

‘Interoperable telematics platform’ for true consumer choice

Decentralised telematics

system

Authorised repairers

independent repairers

secure access

Consum

er

consent:

• Backhand security slides

Critically, the ability to implement a 3rd party application into the vehicle safely and securely is a pre-requisite to achieving an in-vehicle platform for the Aftermarket.

Security proposal

How to achieve security

Standardised telematics system

Standardised requirements for the "in vehicle part "

Standardised requirements for the "access"

How to ensure security?

Telematics system

Secure & encrypted transfer of data

Server

In-vehicle VM Apps verified by VM

Secured server access

High level description – VM today

DATA DATA ACCESS

How to ensure security?

Telematics system

Secure & encrypted transfer of data

Server

Secured server access

High level description

DATA DATA ACCESS

In-vehicle VM and 3rd party Apps

Independent Server

In vehicle Apps verified by VM

Secure & encrypted transfer of data

Secured server access

How to ensure security?

Telematics system

Secure & encrypted transfer of data

Server

Secured server access

High level description

DATA DATA ACCESS

In-vehicle VM and 3rd party Apps

Independent Server

In vehicle Apps verified by VM

Secure & encrypted transfer of data

Secured server access

Unified App security testing Unified, certified and trusted security transmission standard

In-vehicle requirements - transmitter/receiver

A standardised method shall be used for data transfer between vehicle and service provider / customer

This requirement can be achieved by using:

Transmission control protocol/internet protocol (TCP/IP)

SIM card/SIM function

Secure communication using state of the art methods (e.g. VPN, encryption, HTTPS, SSL, etc.)

In-vehicle Application Programming Interface - API

API – a single clearly defined standardised interface providing access…

For all applications to access in-vehicle data

and the exchange of in-vehicle data

In-vehicle application layer

In-vehicle application layer for validated applications…

…allowing independent applications to be written just once, but be implementable on any vehicle

Only validated applications provided through an App store would be able to be implemented in the application layer

The in-vehicle platform should be designed to separate operating systems and applications, as well as monitoring the implementation of an application to ensure that it is valid and safe

Data and vehicle

information

Uses developer guidelines

Developed once for all VMs

Submitted to competent authority (eg TÜV) for validation

Tested against rules (Protection Profile - ISO 15408, ISO 26262)

Secure APP is sent to APP store

Secure APP is downloaded (Communication guarded by

cryptography based on ISO 20828)

In-vehicle APP development and implementation

There is no way of getting software into the car other than

via the approved APP store! Thus, only tested and

trustworthy software can be put in the

vehicle!

Full liability for the APP resides with the developer

Step 1: Release of in-vehicle data to Ind. Operators

Phase 1: Development phase

Definition of data

set to be made

available by

OEMs to

Independent

Service

Providers

(= see C-ITS TF4)

Vehicle Manufacturer

Meta Data/

Test

Data

Independent

Service Provider

develops

Service/Apps on

the basis of test

data/meta data

Service ready!

Remote

Diagnostic

Predictive

Maintenance

Pay-as-you

drive

Breakdown

service

Step 2: Consumer consent (data privacy)

Phase 2: Activation by consumer of real run time data flow

Customer signs

Service Contract

and agrees to

the use of his

vehicle data

a/ Extended Vehicle

VM Server

Data

Examples:

Independant

Providers

Data via VM server

b/ Open Telematics Platform

Data flow directly to IO

Examples:

Independant

Providers

Data

IO Server