Neil Pattemore FIGIEFA Technical Director The ‘connected car’: Challenges for free competition, innovation and consumer choice in the automotive aftermarket
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