The Mobile Conduit: Delivery of Advanced Automotive Services through the Phone Jacek Serafiński Seán Murphy Zylia, Poland UCD, Ireland sean.murphy@iname.com jacek@zylia.pl http://zylia.pl Automotive Lunix Summit, Edinburgh 24.10.2013
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 Web Sockets HMI SDL WiFi or SDL Library SDL Javascript Bluetooth Proxy (iOS, Library Android) OBU Mobile
SDL working parts OBU Mobile Proxy running as OS process iOS/Android libs C++ implementation to be included in SDL maintains communications with compatible applications phone and sends to browser understands SDL quite robust primitives and can Browser based component maintain communications Websockets interface to proxy with OBU 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 App Logic Display and SDL (callbacks on GCal car controls button press, update UI) Car Mobile
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
Recommend
More recommend
