the mobile conduit: delivery of advanced automotive services … · zylia profile r&d...
TRANSCRIPT
Jacek Serafiński Seán Murphy
Zylia, Poland UCD, Ireland
[email protected] [email protected]
http://zylia.pl
Automotive Lunix Summit,
Edinburgh 24.10.2013
The Mobile Conduit: Delivery of Advanced
Automotive Services through the Phone
Zylia profile
R&D consulting company with strong practical focus
Prototype development our primary activity
Expertise
Embedded systems
Speech recognition systems
Audio processing and coding
Mobile-car integration
Work on mix of public- and private-funded projects
Interested in leveraging expertise in embedded systems in Connected Car context
Outline
Connected Car vision, concept, issues
The role of mobile in the Connected Car
Mobile-car integration technologies
Carmesh Implementation work
Platform-specific experiences
Demo applications
Conclusions
Market forecast for
Connected Car
Automotive sector sees the connected car market as a big opportunity to offer new services
Automotive applications market should reach US$ 1.2bn by 2017 (Juniper research)
GSMA forecasts that:
More than 20% of vehicles sold worldwide in 2015 to include embedded connectivity solutions;
More than 50% of vehicles sold worldwide in 2015 to be connected (either by embedded, tethered or smartphone integration);
Every new car to be connected in multiple ways by 2025.
What is the Connected Car?
Two main aspects to the Connected Car:
Integration with existing services (social networks,
calendar, entertainment)
Tailored automotive experience
Right data, right time
Advanced Uis – mix of speech, in car controls, etc.
New data making new services possible
Driving behaviour analysis
Eco-driving
UBI – Usage-based Insurance
Dashboard apps (Torque, Waze)
But it’s much more messy of course…
Challenges realizing Connected Car
The expected lifetime of a car is 10 years thus the deployment of new services to older cars might not be possible
Diversity in capabilities of different cars
There are problems to keep the car connected while moving at high speed and/or in congested areas
Privacy issues regarding usage of vehicular data
Driver distraction issues for new services need to be resolved
Application developers don’t know how to design for the automotive context
New user interfaces
Present the right data at the right time
Increasing influence of mobile
Power of mobile increasing at phenomenal rate
Increasing wireless interfaces’ capacity
OBU will not be able to compete with the mobile in terms of power,
connectivity or release cycles
Mobile already knows much about you
Home, work, apps, locations, etc.
Why not leverage Internet on the mobile?
Why not replace OBU with a mobile?
Heterogeneous mobile world makes neat integration hard
(size, computation power, device connectors)
Security issues - some car data and functionality needs to
be locked from mobile developers (e.g. remote engine
start-up, etc.)
Safety regulations, strict QA processes
Auto manufacturers want to monetize automotive
applications
want to have some control over the ecosystem
OBU and Mobile –
harmonious marriage
Natural solution leverages strength of different systems
OBU provides better integration with Car and driving experience
Mobile provides compute power and network connectivity
As in every marriage there are some tensions…
Tensions
Some obvious touchpoints
Speech
Navigation
Control of the application store/service delivery platform
Need holistic view in which functionality split is clear
System design should allow some flexibility
Standard communication protocols for orchestration required
Car manufacturers will not be tied to single mobile platform
Mobile-car integration
Solutions are not yet mature…
Mobile-car integration
There are different approaches towards mobile-car
integration
Basic integration – contacts, call support, no data connection
Single in-house mobile app (e.g. Mercedes, Lexus)
Mirroring solutions (e.g. MirrorLink, iOS 7)
Application level solutions (Ford Applink, OnStar,
SmartDeviceLink)
Application level solutions for
mobile-car integration
Applications run on the phone and connect wirelessly to the car
Multiple applications connected to the car can run independently from each other
Car provides UI components for mobile app
Mobile app is able to control the output components (display, audio)
Callbacks trigger mobile applications on input from car
Applications can access car data
Open SDK for application developers for different mobile platforms
Why were we interested in SDL?
Started looking at it early this year
Was the most open phone-car interaction solution
Ford are championing it and doing quite good
developer outreach
Although Mirrorlink has more industry support, developer
outreach less mature
We like the vision of brains in phone and car
provides UI components
very compatible with SDL
Carmesh Implementation
Working with new platforms is challenging…
Experiences with SDL
Experiences with Tizen IVI
We are working on three demonstration
applications using SDL in Tizen IVI
Google Calendar integration
Facebook integration
OBDII data collection via RPi
Overview of SDL
Phone-car interaction protocol
Evolution of Ford’s Applink
Enables individual mobile applications to interact with car
Being pushed (somewhat) within GENIVI consortium
On Tizen IVI v3.0 roadmap
SDL ‘richer’ view of mobile-car interaction than mirroring
iOS, MirrorLink
There is a quite well defined protocol right now
although it is somewhat missing an architecture
SDL - the working parts
Mobile
SDL
Library (iOS,
Android)
OBU
SDL
Proxy SDL Javascript
Library
Web Sockets
HMI
WiFi or
Bluetooth
SDL working parts
Mobile
iOS/Android libs
to be included in SDL
compatible applications
understands SDL
primitives and can
maintain communications
with OBU
OBU
Proxy running as OS process
C++ implementation
maintains communications with phone and sends to browser
quite robust
Browser based component
Websockets interface to proxy
Javascript library for registering for notifications, message composition etc
mostly designed around callbacks
Getting it going - OBU
cmake build process
Did not compile out of the box on either Tizen or
Ubuntu
Had some issues around Bluetooth and websockets SHA
calculation
Build generates binary which runs proxy and
launches HMI
chromium by default
HMI offers main automotive UI and emulates
automotive buttons
Getting it going - Android
System comprises of library and application
Straightforward to build and deploy for Android
Small issue with default settings for WiFi mode being
incorrect
No discovery mechanism for WiFi
Limitations of SDL (current)
Control over in car display is very limited
Logic required on OBU side to know how to render
message
No real graphics support
Little navi integration
not possible to send POI to in car navi
some TurnByTurn updates available, though
Features supported by protocol not yet implemented
vehicle data, application types/templates, file transfer
Tizen IVI
Application development and deployment process
We are using Tizen SDK 2.2 to build Web Application
HTML5-based UI components
Downloading Tizen IVI snapshot image from the repository
New revisions uploaded on monthly basis
Sign the application and upload to running Tizen IVI image in VM Player
Install and run applications
wrt-installer –i your_app.wgt
wrt-launcher –l (to get the ID of the installed application)
wrt-client –l your_app_ID
Demonstration applications
Technologies used in demo apps
Android 4.3
SmartDeviceLink (from 24.04.2013 -
http://git.projects.genivi.org/)
Tizen IVI 3.0-M2-Jul
VMWare Player 5.0.2 build-1031769
WiFi for phone-car communication
Manual configuration
Google Calendar with SDL
Basic application to provide GCal integration in car
Can see next upcoming appointments and navigate
to them
assuming location data in GCal event
Use in car controls to control application
GCal app architecture
GCal
App Logic (callbacks on
button press,
update UI)
Display and
car controls
Car Mobile
SDL
Facebook application
Fetch locations from Facebook account
Show these locations relevant to current position
Provide locations of friend’s check-ins, places tagge in,
etc.
FB-based user management (including authentication)
Architecture similar to the previous application
Technologies used
Android Embedded browser
REST API
Facebook Graph API
OBDII data collection with RPi
Connection to ODBII interface
Mobile application connects to the RPi and stores the
data and sends them to the OBU
OBDII to USB serial interface
PyOBD library
Raspberry Pi powered by car
RPi as an access point
Conclusions
Connected Car will change how we use a car
Routing, eco-driving, looking for gas station, etc.
Mobile is the key part of the Connected Car
Mobile becomes context-aware
There is no single view of relationship between car and mobile
Development tools and platforms are still basic
Little understanding of how to develop for automotive context
GENIVI is developing good technologies to make Connected Car happen
Future activities
Leveraging open in-car systems such as SDL
Tizen IVI prototypes and applications
Back-end for vehicular cloud-based services
Vehicle-specific speech recognition systems
Novel vehicular applications
Over-the-air vehicle software updates
In-vehicle (surround) audio coding
Looking at EU-funded collaborations in the area
Obligatory cat…
OK, Let’s be serious…
http://carmesh.eu
http://blog.carmesh.eu/
@carmesh_fp7
THANKS!