dr. jörg brakensiek - logtel-events.com€¦ · dr. jörg brakensiek ... android api specified...

Dr. Jörg Brakensiek is the Chief Architect within the Car Connectivity Consortium (CCC, www.carconnectivity.org). Jörg has 20+ years of experience in wireless and automotive. He has been the Standardization Director in Microsoft’s Devices Compatibility and

Industry Collaboration team, responsible for Automotive and held various managing, engineering and research positions within Nokia before. He started his career in Nokia’s Corporate Research Center Germany in 1999 and moved to the Silicon Valley in 2007. Jörg is the original inventor and main technical architect behind MirrorLink® (www.mirrorlink.com). He is the Chair of the Technical

Work Group within the Car Connectivity Consortium, and responsible for the further development and enhancement of MirrorLink’sand other Car Connectivity technical specifications. Jörg is frequently speaking on conferences, workshops, analyst and media events

about MirrorLink around the globe. Being in the Silicon Valley, Jörg is also the Chief Architect and Co-founder of an Industrial IoTStart-up (www.wivity.com). Jörg received his diploma and doctor degrees in electrical engineering from the Technical University of

Dortmund, Germany in 1994 and 1999 respectively. He has a broad research background on SoC architectures, software radio, multi-processors, mobile virtualization. Jörg had been involved in the definition and execution of multiple German and European funded

research projects.

Dr. Jörg Brakensiek

© 2017 Car Connectivity Consortium. All Rights Reserved.

From MirrorLink to Digital Key The role of the Smartphone in the Connected Car

Dr. Jörg Brakensiek

Chief Architect and Chair of Technical WG, Car Connectivity Consortium

© 2017 Car Connectivity Consortium. All Rights Reserved. 4/28/2017

Outline

Car Connectivity Consortium

MirrorLink Today & Tomorrow

Digital Car Key


Car Connectivity ConsortiumDeveloping Global Standards and Solutions for

Smartphone and in-Vehicle Connectivity


Smartphone-based Connected-Car Solutions

• Seamless

• End-to-End

• Responsible


Car Connectivity ConsortiumA Global Consortium

To bring car, handset and head-unit industries together

• Established in February, 2011

To develop smartphone-based connected-car solutions

• Membership open to any interested company

• Solutions are platform agnostic

• Solution are not owned/governed by a single member

• Runs certification programs to ensure compatibility

To jointly work on common Work Items

• MirrorLink® (established)

• Car Data Market Place (in planning)

• Digital Car Key (in development)


Car Connectivity ConsortiumSome of Our Members


Car Connectivity ConsortiumOur Way of Working

Eco-System Working Group

(Samsung)

User Experience

Working Group

(VW)

Technical Working Group

(CCC)

Certifica-tion

Working Group

(RealVNC)

Steering Committee + Staff Officers: Executive Director (CCC), Vice President (PSA), CFO (Alpine),

WG Chairs, VP China (CCC), App & Device Certification Bodies (CCC), Admin

Board of DirectorsPresident (Samsung)


Maintenance

Existing Features

Car Connectivity ConsortiumFuture Directions

Application Platform

New Service

Enablement(Digital Key, Car Data)

Standard

Centric

Approach


MirrorLink®Giving Consumers Access to their Smartphone,

while Driving, in a Responsible Way


MirrorLink® Experience3 Simple Steps for Consumers

Get Into your Car Plug In your Phone Access Your Apps


MirrorLink® ExperienceThe Consumer’s View


MirrorLink® ArchitectureDetect Device on Physical Layer

USB Connectivity• USB CDC/NCM

interface descriptor

• Dedicated ML USB

command to switch to

CDC/NCM device class.

Infrastructure Wi-Fi

• No ML specific information

Wi-Fi P2P

• CCC Information Element in

IEEE 802.11 layer

USB Host(Head-Unit)

USB Device(Phone)

Connect

Support for CDC/NCM?

Select CDC/NCM

Conn

ectivity

Re-Connect

Support for CDC/NCM

ML USB Command


MirrorLink® ArchitectureEstablish IP Connectivity – TCP and UDP over IPv4

IPv4

TCPUDP

ARP

DHCP

Ethernet

CDC/NCMInfrastructure

Wi-Fi

Conn

ectivity

Wi-Fi P2P

USB IEEE 802.11x CCC IE


Dis

cover

Serv

er

IPv4

UDP

SSDP

Serv

er

Dis

co

ve

ry &

Ide

ntification

MirrorLink

Server Device

MirrorLink® ArchitectureUPnP based ML Server Discovery & Identification

Device Discovery (SSDP)

• Server: Periodic SSDP:Alive

• Client: Individual SSDP:Discover

Device Identification (HTTP-Get)

• Client: Retrieve Server Device XML

• Provides supported services and

event/control URLs

• Manufacturer Name/URL

• Model Name/Number

• UUID/USN

• BT/Wi-Fi Connectivity Info

• MirrorLink Version

• Supported transports

• Localization Info

• Signature

TCP

HTTP

Identify

Serv

er


Identify

Clie

nt

HTTP

Clie

nt

Dis

covery

&

Ide

ntification

MirrorLink Client

Control Point

MirrorLink® ArchitectureUPnP based ML Client Discovery & Identification

Device Identification (SOAP)• Server implements a Client Profile

service (based on SOAP)

• Client uploads a Profile.

• Content similar to Server Device XML.

Session Start• Client sends SetClientProfile SOAP

action (Client Profile).

Session Termination• Client sends SetClientProfile SOAP

action (“”).

• Server sends SSDP:byebye.

SOAP

Client Profile

Service


Device Attestation

• Validate Device Integrity

• ML Server measures ML stack

components and returns

• Nonce Detect replay

• URL Bound Port

• Public Key Protocol specific

• Certificates Trust Chain

• Signed using RSA PKCS#1 v1.5

• Public key is used for validating

signature or encrypting data

Esta

blis

h T

rust

Rela

tio

nship

MirrorLink® ArchitectureSecurity Architecture – Device Attestation

Sub-Root CA

Root CA


1. Phone contains a set of

(certified) ML Apps

2. Head-Unit requests list of

available (certified) ML Apps

3. Phone provides app list with

meta information

4. Head-Unit presents apps

5. Consumer launches app

6. Head-Unit requests app launch

from Phone

7. Phone brings app to foreground

ML A

pp

licatio

n

Ma

na

gm

en

t

MirrorLink® ArchitectureApplication Control from the Head-Unit


MirrorLink® ArchitectureProject the User Interface & Receive Remote Control

Use

r In

terf

ace

Pro

jectio

n

VNC

(Multi) Touch Steering WealRotary KnobHSML


MirrorLink® ArchitectureStream Audio via Car Stereo / Receive Voice Command

Audio

“Turn Right in 500 m”

Legacy Bluetooth

BT HFP & BT A2DP

RTP Audio Streaming

48 kHz, 16 bit, Stereo

RTP header extension


MirrorLink® ArchitectureBringing MirrorLink to Applications

Mirro

rLin

k A

PI

Apps need MirrorLink

Session Information

• To adapt to provided

capabilities

• To ensure driver

distraction

• To create user

experience

Identical on all Phones

(Platform specific)

Android API specifiedMirrorLink

Car C

MirrorLink Phone 3

MirrorLink Car B

MirrorLink Phone 2

MirrorLink Car A

MirrorLink Phone 1

MirrorLink API

Application


Common Data Bus

• Data service level

• Service advertisement

• Start/Stop service

• Data Payload, Response

Service Binary Protocol

• Data objects level

• Object values

• Object type (Int, Dbl, struct, [ ], …)

• Object access (Get, Set, Subscribe)

Data Service

Endpoint

Data

Service 1

A B

Data

Service 2

C

MirrorLink® ArchitectureFramework to Exchange Data between Phone & Car

Data

Acce

ss

D


STRUCTURE Coordinates {

DOUBLE latitude;

DOUBLE longitude;

DOUBLE altitude;

DOUBLE accuracy;

DOUBLE altitudeAccuracy;

DOUBLE heading;

DOUBLE speed;

};

Object GeoLocation {

STRUCTURE Coordinates coord;

TIME timestamp;

}; Data Service

Endpoint

GeoLocation

Location Data

Service

MirrorLink® ArchitectureData Service Example

Data

Serv

ices


MirrorLink® ApplicationsChallenges

Challenge 1: User is Interacting via the In-Vehicle Controls

•Different screen size and positions

• Interaction at arm-length

•Different controls available

Challenge 2: App Must Minimize Driver Distraction

•Main task is driving

•Easy to visually process

•Quick to interact

Two Sets of Application Requirements

•Does the App Work in Automotive Context?

•Does the App Minimize Distraction?


MirrorLink® ApplicationsSimple Application Guidelines


MirrorLink® ApplicationsBase “Park” Requirements – Basic Interoperability

Head Unit Screen Sizes are different

• Reference client display “minimum” display

- 800 x 480 pixels (square)

- 13.33 cm x 8.00 cm

- 90 cm from driver

• App can adapt to larger screen sizes (optional)

Controls in Vehicle are different

• Touch-screen head units and rotary shift-knob units

• Variety of steering wheel controls and on-dash buttons

• No dedicated device hardware keys

Head Unit needs to know what is being provided

• Audio metadata to identify and mix audio

Ensures App Works in MirrorLink Environment


MirrorLink® ApplicationsDrive Requirements – Minimizing Driver Distraction

Guiding Principals

• Nothing that demands the driver’s attention

• Quickly comprehensible and accessible

Restricted Content

• No video, incidental animations or flashing

• No automatic scrolling text

Visual Accessibility

• Color contrast – brightness & color differences

• Text legibility

Control Accessibility

• No two-handed operations

• Should not use the keyboard

• Control sizing and spacing

Pace of Interaction

• Input retention and responsiveness

• Notification dismissal

Region-Based Certification

Default Certification

• Subset of EU requirements

Regional Certification

• North America (AAM)

• European Union (EU)

• APAC (JAMA)

• China

Global Certification

• Superset of NA, EU and APAC guidelines


Application Design

Principles

• Developers are given an

empty canvas for the UI to fill.

• Maintain brand identity.

• Templates are possible, but

not required.

No Limitations

• Apps can be of any kind:

Navigation, entertainment,

social, messaging, …

MirrorLink® ApplicationsExample MirrorLink Application Designs


RockScout powered by MirrorLink

• CCC Drive-Certified Media Player

• Enables streaming of audio & native media

streams without undergoing formal certification.

• Leverages Android’s Media Browser Service

Supported Publisher

MirrorLink® ApplicationsRockScout by MirrorLink®


MirrorLink® TechnologyApplication Certification

1. User installs App from

any App Store

2. Phone downloads

matching App Cert

from CCC database

3. Phone validates

Certificate

4. Phone regularly checks

Cert Revocation Status

Developer Mode exists

ID

CCC

CCC Cert Database

App

Advertisements

App

Self

MirrorLink Phone

MirrorLink Head-Unit

App Store

App

licatio

n C

ert

ific

ate

s


• MirrorLink 1.0

• Provided basic technology enablers for MirrorLink use case.

• Launched end of 2011

• MirrorLink 1.1

• Provided basic foundation for 3rd party application developer

• Launched 2014

• MirrorLink 1.2

• Expanded the technology portfolio to enable wireless MirrorLink

(WFD) and improved wired MirrorLink (HSML).

• Launched 2016

• MirrorLink 1.3

• Focus again on applications.

MirrorLink® RoadmapWhere is MirrorLink right now?


Co-operation agreement with ETSI

(European Telecommunications Standards Institute)

• ETSI will formally explore adopting MirrorLink as an ETSI Technical

Specification.

• Will be part of ITS Technical Committee, using PAS process

Why a formal Standard – Why ETSI?

• A standard will make it easier to work with government bodies and

regulators.

• ETSI is known very well to many of our members

• ETSI has the right processes to allow adoption of an industry

specification, implemented by millions of devices.

MirrorLink® RoadmapWhere is MirrorLink heading?


Digital Car KeyBuilding Digital Key Solution forAutomotive


CCC announcement from June 2016

• Smartphone as Key has been on the development horizon for many

automakers and handset vendors.

• The proprietary approaches currently being developed and deployed lack

wide adoption made possible by a standardized approach.

Initial Contribution on Use Cases

Presentation of Work Items at Conferences

Reach-out to other Organizations

White Paper published in Feb/March

Technical Specification work has started

Digital KeyMain Activities


Car Owner

Cars

Backend

Digital Key

Smart Phone/

Accessory

Car User

Digital KeyMain Roles and Associations


Proximity

• User interacts with the car at specific location

• No user action is required on SmartPhone.

• Car unlocks doors and signals this with lights/sounds

• Protect against unauthorized access by range detection

Digital Key Use CasesUnlock Door – Interact with the Car


Proximity

• SmartPhone App may automatically launch, when in

communication range

• User interacts with SmartPhone App

• Car unlocks doors and signals this with lights/sounds

• Protect against unauthorized access by range detection

Digital Key Use CasesUnlock Door – Interact with a Smartphone App


• User taps SmartPhone at Car (NFC Tab)

• SmartPhone needs to “touch” the car at specific location

• Car unlocks the doors and signals this with lights/sound

Digital Key Use CasesUnlock Door – Touch Vehicle with Smartphone


Locking use case are similar to Unlocking use cases.

• User leaves Proximity of the Vehicle

• User interact with an App on the Smart Device

• User touches Vehicle with Smart Device at specific

location (NFC touch)

• Car unlocks doors and signals this with lights or/and

sound

• Car also informs SmartPhone about the status of the

Lock operation.

Digital Key Use CasesLock Door


• User taps SmartPhone at specific location inside car &

presses START button.

• No other explicit action on SmartPhone

• To protect against unauthorized access, engine start shall

only work when SmartPhone is clearly detected inside the car

Digital Key Use CasesStart the Engine


Similar to Unlock use cases, with an additional step for to

ensure User Authentication on the Smart Device.

Before using Digital Key on the smart device some

additional user authentication mechanism may be required.

This may be in the form of entering simple passcodes up to

biometric authentication mechanisms such as fingerprint or

iris scans

Digital Key Use CasesAdditional Authentication


Digital Key Use CasesKey Provisioning


Digital Key Use CasesKey Revocation


Similar to Key Provision / Revocation Use Cases

Provision Digital Keys to the smart devices of the customer

for the duration of the rental.

This mechanism works agnostic of the brand of the car or

the smart device, so that the rental agency is the single

contact point for the customer.

Important for Car sharing and rental car agencies

Digital Key Use CasesKey Management for Car Sharing Agencies & Fleets


Similar to Key Revocation Use Case

All digital Keys shall be revoked from all Smart Devices,

which had a digital key provisioned.

Digital Key Use CasesSelling the Vehicle


Key Revoca-

tion

Lock Car

Start Engine

Digital Key requires all main use cases being supported.

Unlock Car

Key Provision

Digital Key Use CasesDigital Key Life Cycle


Users are accustomed to sharing or lending their keys to

family or friends as well as to repair shops or valets.

The Digital Key user experience should enable and support

similar usages seamlessly.

• Proximity Sharing: A user in proximity to the Digital Key

owner can be granted temporary access via proximity

connectivity connections.

• Remote Sharing: A user far in range from the Digital Key

owner can be granted temporary access via long range

communication connections.

Digital Key Use CasesKey Sharing


A Digital Key can have properties or rights and restrictions associated with the key.

Example 1: Usage of the key for valet parking. • Restrict the validity time

• Restrict maximum speed when the car is accessed with Digital Key

Example 2: Delivery to Trunk• Allow opening the trunk of the car and not the car itself,

Example 3: Pre-set Comfort Functions• Key stores vehicle related personal settings or preferences of

the user for a more customized user experience.

• Mirror settings or seat positioning, head unit settings, climate control settings, driving mode settings, …

Digital Key Use CasesKey Properties


Remote Control/Vehicle Status

• Remotely access the Vehicle functions & status

• Not in proximity

Service Key Data

• Store vehicle relevant information

• Use within dealership, error diagnostic

Digital Key Use CasesOther…


Digital Key Technical ArchitectureHigh-level Technical Architecture


Thank you!Contact: [email protected]

mailto:[email protected]

dr. jörg brakensiek - logtel-events.com€¦ · dr. jörg brakensiek ... android api specified...

Documents